Subject: Re: [Mip6] Dynamic HoA assignment

From: Heejin Jang <[email-masked]>
Date: Wed, 11 Apr 2007 07:59:21 +0000 (GMT)

Hi, Raj & folks. 
 
I think that HoA assignment through DHCP is necessary.

In Proxy MIP, MN has plain IP stack  without any advanced functions such as MIP client, 
and  there is no way to deliver HoA to MN in the last hop except DHCP. 
Since, in PMIP, HoA assignment during IKEv2 or BU/BA exchanges is possible between PMA (MAG) & HA, 
not between MN & HA. Though HoA is bootstrapped through either IKEv2 or BU/BA exchanges, 
it should be delivered from the network to the MN after all and DHCP could be a delivery mechanism for it.

- Regards, 
Heejin.

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 7:07 AM
To: Mobile IPv6 Mailing List
Subject: [Mip6] Dynamic HoA assignment

Hello,

Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well in addition to the HA address and prefix via DHCP.

I think the MN should obtain the minimal information required to bootstrap.
It is better to have the HA assign the MN an HoA. To do this we would require capability similar to MIP4 wherein the BU can be sent with an unspecified HoA. This is currently not possible as per RFC3775.

Should we consider allowing the MN sending a BU with the unspecified HoA and obtain an HoA (assigned by the HA) in the BAck?

I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such capability.
Also do we need to consider standardizing the bootstrapping mechanism for the auth protocol (RFC 4285)?

-Basavaraj

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Apr 2007 07:52:47 -0700

> it should be delivered from the network to the MN after all and DHCP could be a delivery mechanism for it.

The base PMIPv6 protocol assumes that the home prefix is sent
to the mobile node using a router advertisement and then the
mobile node auto-configures a home address from this prefix.

IKEv2 based HoA assignment is obviously not applicable to
PMIPv6 since there is no IKEv2 being run between the mobile
node and the LMA.

Vijay

> ------------------------------------------------------------------------
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 11 Apr 2007 15:44:29 -0500

Hi Heejin,

I think we don't need to worry about how the HoA is delivered to the MN in
the case of PMIP. That is for the PMIP I-D to specify.
In PMIP the MN which obtains an address does not even realize it is an HoA.

The scope of the current discussion is limited to bootstrapping for MIP6.
IKEv2 is one way of delivering the HoA. This is the preferred approach (IMO)
when the MN and HA establish an IPsec SA for securing the MIP6 signaling.

When the MN does not estabish an IPsec SA and secures the BU/BAck using the
auth protocol (RFC4285), we need the HA to assign the MN the HoA. I think
this is the most practical way.

Lets take a scenario in which the MN gets the HA address via some
out-of-band means, so basically not via DHCP. The MN can then obtain the HoA
from the HA via the MIP6 signaling messages. My point is that if the MN is
going to run MIP6, then it should get the HoA as well via MIP6 messages
(which is either via IKEv2 or the BAck). DHCP is adding yet another means of
doing so which is not essential. The fewer the choices, the better it is
from a protocol design perspective.

-Raj

On 4/11/07 2:59 AM, "ext Heejin Jang" <[email-masked]> wrote:

> Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA as well
> in addition to the HA address and prefix via DHCP.
> 
> It is better to have the HA assign the MN an HoA. To do this we would require
> capability similar to MIP4 wherein the BU can be sent with an unspecified HoA.
> This is currently not possible as per RFC3775.
> 
> Should we consider allowing the MN sending a BU with the unspecified HoA and
> obtain an HoA (assigned by the HA) in the BAck?
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 Apr 2007 12:11:21 +0300

> mobile node auto-configures a home address from this prefix.

Isn't an IPv6 host in charge of whether it uses address autoconfiguration or
DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does not want
to dictate any particular behaviour on the hosts.

Alper

> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the HoA
> as well in addition to the HA address and prefix via DHCP.
> >
> > It is better to have the HA assign the MN an HoA. To do this we would
> require capability similar to MIP4 wherein the BU can be sent with an
> unspecified HoA. This is currently not possible as per RFC3775.
> >
> > Should we consider allowing the MN sending a BU with the unspecified HoA
> and obtain an HoA (assigned by the HA) in the BAck?
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Apr 2007 12:06:49 -0700

> to dictate any particular behaviour on the hosts.

2461bis says

    Router Advertisements (and per-prefix flags) allow routers to inform
    hosts how to perform Address Autoconfiguration.  For example, routers
    can specify whether hosts should use DHCPv6 and/or
    autonomous (stateless) address configuration.

Stateful address configuration is not mandatory to support.
RFC 4294 says

    Stateful Address Autoconfiguration MAY be supported.

But I do agree DHCPv6 could be used between the mobile node
and the MAG (Mobile Access Gateway).

However, the address configuration for PMIPv6 depends to a
large extent on what kind of link layer is used between the
mobile node and the MAG. If the link layer is PPP, for e.g.,
IPv6CP is used. If the link layer is an IPsec tunnel then
IKEv2 configuration payloads are used. The PMIPv6 protocol
does consider this and has some text addressing this.

Anyway, this discussion needs to happen on the NETLMM
mailing list.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 Apr 2007 00:47:33 +0300

> IKEv2 configuration payloads are used. 

So, your original statement does not sound accurate anymore.

> The PMIPv6 protocol

> Anyway, this discussion needs to happen on the NETLMM

I agree, this requires some clarification.

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Apr 2007 14:54:38 -0700

> So, your original statement does not sound accurate anymore.

?? I said the default mechanism is to use router advertisement
for conveying the home prefix to the mobile node. That is what
is assumed in the Proxy MIPv6 base spec. That is still valid.
You would be using router advertisements and stateless address
auto-configuration as much as possible. When you have "special"
link layers, then the link specific mechanisms are used.

> I agree, this requires some clarification.

Take a look at the current text in draft-ietf-netlmm-pmip6-00
to see if it is sufficient.

Vijay

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 13 Apr 2007 01:22:52 -0400

IPv6CP is used to negotiate the IID only which helps in producing the
link local address. RS/RA or DHCPv6 is used to configure the global
scope address.

-Kuntal

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, April 12, 2007 2:07 PM
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mip6] Dynamic HoA assignment
> 
> Alper Yegin wrote:
> > DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does
not
> want

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 13 Apr 2007 11:38:38 -0500

Looks like we are diverging on this thread here.

Lets try and see if we can come to a conclusion on this topic:

- IKEv2 is the preferred approach to obtaining the HoA when IPsec is used to
secure the MIP6 signaling messages. With this approach the MN will not need
to send a BU with the unspecified address. So we do not have any impact on
RFC3775 with this approach while still allowing for dynamic assignment of
the HoA. 
This approach applies to the intergrated scenario bootstrapping solution as
well. Hence an MN which obtains only the HA via DHCPv6 SHOULD obtain the HoA
via IKEv2 when IPsec is used.

- When the BU/BAck are secured as per RFC4285 and the MN needs to be
bootstrapped, the MN cannot send a BU to an HA without an HoA (as per
current RFC3775 which does not allow the sending of the unspecified
address).  If the MN is assigned the HoA, the scope of this address being at
some remote HA, via DHCPv6, do we need to specify the interaction between
the HA and DHCP server (via an intermediary such as AAA as has been
suggested in the integrated scenario bootstrapping I-D)? I am not sure if it
is sufficient to state that the method by which the HoA is inserted in the
DHCP server is out-of-scope good enough.

So given the current MIP6 requirement that the BU contain the HoA, there is
a need to assign the HoA, possibly via DHCPv6 when RFC4285 mode of operation
is assumed.

- Now if we change the RFC3775 requirement for requiring the HoA in the BU,
do we cause any harm? I mean other then the impact to the current
implementations which would be required to process such BU messages.

The intent is to allow the MN to send a BU with HoA=0:0 only in the case
when IPsec is not used between the MN and HA (i.e 4285 mode).

-Raj

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 13 Apr 2007 18:56:41 +0200

Hi,

2007/4/13, Basavaraj Patil <[email-masked]>:

[snip]

>From a security point of view, IMHO, there are 2 issues.

The first one, which is minor because easily solved, is that an
already authenticated MN may flood the HA in requesting plenty of HoA
without a heavy security process. The consequences may be (here the
draft is not clear) a surcharge of the HA, a flood of BCE (i.e. BC
Overflow), etc.
To solved this, the HA should allow only a strict number of HoA per MN-ID

The second issue is that, normally, security policy (i.e. filtering
rules) at the border of an  administrative domain (i.e. HA's domain
here) should be based on HoA. If the BU has HoA=0::0, the packet
should be rejected.

Best regards.

JMC.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 13 Apr 2007 12:02:25 -0500

Hi Raj,

I believe we should allow MN to send a BU with HoA=0:0 only in the case
when IPsec is not used between the MN and HA (i.e 4285 mode). The HA
when receives a request for HoA assignment it can use DHCP, AAA, or
static configuration of a set of addresses to allocate an IP address for
the MN.

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 11:39 AM
To: Chowdhury, Kuntal; Vijay Devarapalli; Alper Yegin
Cc: [email-masked]; [email-masked]
Subject: Re: [Mip6] Dynamic HoA assignment

- IKEv2 is the preferred approach to obtaining the HoA when IPsec is
used to secure the MIP6 signaling messages. With this approach the MN
will not need to send a BU with the unspecified address. So we do not
have any impact on RFC3775 with this approach while still allowing for
dynamic assignment of the HoA. 
This approach applies to the intergrated scenario bootstrapping solution
as well. Hence an MN which obtains only the HA via DHCPv6 SHOULD obtain
the HoA via IKEv2 when IPsec is used.

- When the BU/BAck are secured as per RFC4285 and the MN needs to be
bootstrapped, the MN cannot send a BU to an HA without an HoA (as per
current RFC3775 which does not allow the sending of the unspecified
address).  If the MN is assigned the HoA, the scope of this address
being at some remote HA, via DHCPv6, do we need to specify the
interaction between the HA and DHCP server (via an intermediary such as
AAA as has been suggested in the integrated scenario bootstrapping I-D)?
I am not sure if it is sufficient to state that the method by which the
HoA is inserted in the DHCP server is out-of-scope good enough.

So given the current MIP6 requirement that the BU contain the HoA, there
is a need to assign the HoA, possibly via DHCPv6 when RFC4285 mode of
operation is assumed.

- Now if we change the RFC3775 requirement for requiring the HoA in the
BU, do we cause any harm? I mean other then the impact to the current
implementations which would be required to process such BU messages.

-Raj

On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal"
<[email-masked]> wrote:

>>>> The base PMIPv6 protocol assumes that the home prefix is sent to 
>>>> the mobile node using a router advertisement and then the mobile 
>>>> node auto-configures a home address from this prefix.
>>> 
>> Stateful address configuration is not mandatory to support. RFC 4294 
>> says
>> 
>> But I do agree DHCPv6 could be used between the mobile node and the 
>> MAG (Mobile Access Gateway).
>> 
>> However, the address configuration for PMIPv6 depends to a large 
>> extent on what kind of link layer is used between the mobile node and

>> the MAG. If the link layer is PPP, for e.g., IPv6CP is used. If the 
>> link layer is an IPsec tunnel then IKEv2 configuration payloads are 
>> used. The PMIPv6 protocol does consider this and has some text 
>> addressing this.
>> 
>> Anyway, this discussion needs to happen on the NETLMM mailing list.
>> 
>> Vijay
>>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 13 Apr 2007 12:21:17 -0500

Hi Jean,

> To solved this, the HA should allow only a strict number of HoA per MN-ID

I guess this is not really a new issue.
Every BU with a request for an HoA would have to authenticate itself. And
then it is up to the HA to have some policy to deal with it.

> here) should be based on HoA. If the BU has HoA=0::0, the packet

I don't know if that is how the firewall rules would be.

-Raj

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 16 Apr 2007 12:13:59 +0200

Hi Raj,

> Hi Jean,

s/Jean/Jean-Michel ;)

> Every BU with a request for an HoA would have to authenticate itself.

I agree but the security is lighter than a IKEv2 process, so the
attack is easier.

> And

I agree of course. That's why I said this is a minor issue :)

Best regards.

JMC.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 23 Apr 2007 15:56:44 -0500

Hi All,

The following draft has been posted on netlmm, your comments and
feedback is much appreciated.

   The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows
   the mobile node's IPv4 and IPv6 traffic between the local mobility
   anchor and the mobile access gateway to be tunneled using IPv6, IPv4
   or IPv4-UDP encapsulation headers.  These encapsulation modes do not
   offer semantics for the tunnel end-points to expose a service
   identifier that can be used to identify traffic for a certain
   classification, such as for supporting mobile nodes that are using
   overlapping private IPv4 addressing.  The extensions defined in this
   document allow the mobile access gateway and the local mobility
   anchor to negotiate GRE encapsulation mode and along with the GRE
   symmetric key or asymmetric keys for marking the flows, so that
   differential processing can be applied by the tunnel peers over those
   flows.

http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-0
0.txt

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2007 18:03:07 +0200

> differential processing can be applied by the tunnel peers over those

Several reasons I believe GRE is not necessary for PMIPv6.

Does GRE work transporting IPv6?  I thought it only transports IPv4.
PMIPv6 assumes IPv6 applications first, in my understanding.

PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which is
Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits from
DS-MIPv6 whose method of transporting IPv6 over IPv4 is not yet
clarified, but was discussed until now to be IPv6 in UDPv4 (again not
GRE) or maybe IPv6-in-IPv4 with protocol number 41 rfc2893 (yet again
not GRE).

I think it is also obvious that PMIPv6 done in netlmm WG should
encapsulate only once at max, not twice nor more.  Ie a packet from LMA
to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6
in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE).

So in this context, can I ask why GRE?  It's not used by MIPv6, was
never suggested by DS-MIPv6, can't transport IPv6 and has several
implemented alternatives.  Why GRE?

Alex

> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 24 Apr 2007 11:23:21 -0500

Hi Alexandru,

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2007 11:03 AM
To: Khalil, Mohamed (RICH2:2S20)
Cc: [email-masked]
Subject: Re: [Mip6] GRE key

> document allow the mobile access gateway and the local mobility anchor

> to negotiate GRE encapsulation mode and along with the GRE symmetric 
> key or asymmetric keys for marking the flows, so that differential 
> processing can be applied by the tunnel peers over those  flows.

Mohamed>> should be use to transport IP6 too.

I think it is also obvious that PMIPv6 done in netlmm WG should
encapsulate only once at max, not twice nor more.  Ie a packet from LMA
to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or maybe IPv6
in IPv6, but not in a double encapsulation like IPv6-in-IPv4-in-GRE).
Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6 is
double encapsulation (DS-MIP6).
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 UDP header
                   IPv6 header (src=V4CoA, dst=HAADDR)
                      DST-OPT
                          HAO (IPv6 home address)
                      Mobility header
                          BU [IPv4 HAO]

mohamed>> GRE is used in this draft to mark/identify traffic for a
certain
   classification, such as for supporting mobile nodes that are using
   overlapping private IPv4 addressing.

Mohamed

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 24 Apr 2007 09:37:00 -0700

quick comments on this ....

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2007 9:03 AM
To: Mohamed Khalil
Cc: [email-masked]
Subject: Re: [Mip6] GRE key

[Sri] 2784 does not disallow the IPv6 transport. The note in the
Appendix section just states, at that time when the spec was
written, there were no known implementation supporting GRE over
IPv6. It needs to be understood that the GRE implementations were
out there first before the spec came out and so the comment was
in that context. Cisco has GRE support over IPv6 for years and
nothing in the spec prevents that.

[Sri] Probably the draft needs one revision to reflect the current
WG chair's decision to split the PMIP6 document. Probably, this 
draft should be discussed a bit later after the current PMIP6 work
is complete, may be 2 months down the road.

[Sri] There are many use cases. It should be discussed later, IMO.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2007 18:43:04 +0200

Mohamed Khalil wrote:
> Hi Alexandru,
> 
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Tuesday, April 24, 2007
> 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: [email-masked] Subject:
> Re: [Mip6] GRE key
> 
> 
> Mohamed Khalil wrote:
>> Hi All,
>> 
>>  anchor and the mobile access gateway to be tunneled using IPv6,
>> IPv4 or IPv4-UDP encapsulation headers.  These encapsulation modes
>> do not offer semantics for the tunnel end-points to expose a
>> service identifier that can be used to identify traffic for a
>> certain classification, such as for supporting mobile nodes that
>> are using overlapping private IPv4 addressing.  The extensions
>> defined in this document allow the mobile access gateway and the
>> local mobility anchor
> 
>> to negotiate GRE encapsulation mode and along with the GRE
>> differential processing can be applied by the tunnel peers over
>> those  flows.
> 

It's true that the RFC I'm referring to is relatively old, is there an
update on the GRE implementation as to show it can transport IPv6?
rfc2784 says:
> o IPv6 as Delivery and/or Payload Protocol
> 
> This specification describes the intersection of GRE currently 
> deployed by multiple vendors. IPv6 as delivery and/or payload 
> protocol is not included in the currently deployed versions of GRE.

Is there an update to this RFC or to this statement in this RFC?  Thanks.

>> PMIPv6 inherits from MIPv6 tunnelling, which is IPv6-in-IPv6 which
>> is Generic Packet Tunnelling rfc2473 (not GRE); and it maybe
>> inherits from DS-MIPv6 whose method of transporting IPv6 over IPv4
>> is not yet clarified, but was discussed until now to be IPv6 in
>> UDPv4 (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41
>> rfc2893 (yet again not GRE).
>> 
>> encapsulate only once at max, not twice nor more.  Ie a packet from
>> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 or
>> maybe IPv6 in IPv6, but not in a double encapsulation like
>> IPv6-in-IPv4-in-GRE).
>
> Mohamed>> I don't see the issue of double encapsulation, IP4-UDP-IP6
> is double encapsulation (DS-MIP6). IPv4 header (src=V4ADDR,
> dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA, dst=HAADDR) DST-OPT
>  HAO (IPv6 home address) Mobility header BU [IPv4 HAO]

That's simple encapsulation I believe, it's IPv6 packets in UDPv4 
packets.  One may interpret that as double encapsulation.

What I mean is that if the PMIP approach relies on some deployed code
that doesn't assume GRE then where would GRE necessity come from?  Could 
you answer this?

> certain classification, such as for supporting mobile nodes that are
> using overlapping private IPv4 addressing.

Yes, I read that in the abstract.  But I don't see any NAT throughout 
the document.

I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable to 
deal with the problem of overlapping private IPv4 addressing you cite in 
the draft.  Don't you think so?

Please don't get me wrong.  I think many forms of tunnelling are 
possible and that some decisions have already been made, and that GRE 
tunnelling is straight competitor to the ones I've listed.  A dynamic 
method to choose between the available methods is probably useful.  But 
I don't see why pushing solely GRE; again, where is GRE coming from into 
the PMIP picture?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2007 18:50:23 +0200

> nothing in the spec prevents that.

Let me clarify this... can a Cisco router transport IPv6 _over_ IPv4 
with GRE? (not IPv6 over IPv6 with GRE).

I agree the spec doesn't prevent it.  But it doesn't say what the 
Protocol Type is either (in the case of IPv6).  It refers to an invalid 
http address.  So how could one implement it?

> is complete, may be 2 months down the road.

I somehow agree with you.

> [Sri] There are many use cases. It should be discussed later, IMO.

Ok, sorry for disturbing, let's see later.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Apr 2007 12:01:18 -0500

Hi Alex,

Thanks for your comments. Please see comments inline.

Regards,
Ahmad

> Sent: Tuesday, April 24, 2007 11:43 AM
> >> The Proxy Mobile Ivy base specification defined in 
> [PMIP6-ID] allows
> > 
> >> IPv4 or IPv4-UDP encapsulation headers.  These 
> encapsulation modes do 
> >> not offer semantics for the tunnel end-points to expose a service 
> >> anchor
> symmetric 
> It's true that the RFC I'm referring to is relatively old, is 
> there an update on the GRE implementation as to show it can 
> transport IPv6?
> rfc2784 says:
> > deployed by multiple vendors. IPv6 as delivery and/or 
> payload protocol 
> > is not included in the currently deployed versions of GRE.
> 

[Ahmad]
Please see Sri comments earlier.

> >> Generic Packet Tunnelling rfc2473 (not GRE); and it maybe inherits 
> >> from DS-MIPv6 whose method of transporting IPv6 over IPv4 
> is not yet 
> >> clarified, but was discussed until now to be IPv6 in
> That's simple encapsulation I believe, it's IPv6 packets in 
> UDPv4 packets.  One may interpret that as double encapsulation.
> 
> What I mean is that if the PMIP approach relies on some 
> deployed code that doesn't assume GRE then where would GRE 
> necessity come from?  Could you answer this?

[Ahmad]
The draft proposes a mechanism to negotiate GRE keys and obviously to be
used whenever needed. i.e. GRE encapsulation is an optional feature.

> Yes, I read that in the abstract.  But I don't see any NAT 
> throughout the document.
> 
> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are 
> capable to deal with the problem of overlapping private IPv4 
> addressing you cite in the draft.  Don't you think so?
> 
> Please don't get me wrong.  I think many forms of tunnelling 
> are possible and that some decisions have already been made, 
> and that GRE tunnelling is straight competitor to the ones 
> I've listed.  A dynamic method to choose between the 
> available methods is probably useful.  But I don't see why 
> pushing solely GRE; again, where is GRE coming from into the 
> PMIP picture?

[Ahmad]
GRE is widely deployed and used and I believe it has a use case in Proxy
MIP in general. You are welcome to publish any other mechanisms that you
think valuable and has a use case.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2007 19:32:48 +0200

Ahmad Muhanna wrote:
> Regards, Ahmad
>>  11:43 AM To: Khalil, Mohamed (RICH2:2S20) Cc: [email-masked] 
>>> [mailto:[email-masked]] Sent: Tuesday, April 24, 
>>> 2007 11:03 AM To: Khalil, Mohamed (RICH2:2S20) Cc: [email-masked] 
>>>> The following draft has been posted on netlmm, your comments 
>>>> and feedback is much appreciated.
>>>> 
>>>> not offer semantics for the tunnel end-points to expose a 
>>>> certain classification, such as for supporting mobile nodes 
>>>> that are using overlapping private IPv4 addressing.  The 
>>>> extensions
>> defined in this
>>>> key or asymmetric keys for marking the flows, so that 
>> It's true that the RFC I'm referring to is relatively old, is there
>>  an update on the GRE implementation as to show it can transport 
>> IPv6? rfc2784 says:
> [Ahmad] Please see Sri comments earlier.

Ok, yes, seems to be implemented to transport IPv6 in GRE with protocol
number apparently 0x86dd.

>>>> Generic Packet Tunnelling rfc2473 (not GRE); and it maybe 
>>>> clarified, but was discussed until now to be IPv6 in UDPv4 
>>>> (again not GRE) or maybe IPv6-in-IPv4 with protocol number 41 
>>>> LMA to MAG should only be encapsulated once (IPv6 in UDP/IPv4 
>>>> or maybe IPv6 in IPv6, but not in a double encapsulation like 
>>>> IPv6-in-IPv4-in-GRE).
>>> Mohamed>> I don't see the issue of double encapsulation, 
>>> IP4-UDP-IP6 is double encapsulation (DS-MIP6). IPv4 header 
>>> (src=V4ADDR, dst=HA_V4ADDR) UDP header IPv6 header (src=V4CoA,
>> dst=HAADDR) DST-OPT
>> What I mean is that if the PMIP approach relies on some deployed 
>> code that doesn't assume GRE then where would GRE necessity come 
>> from?  Could you answer this?
> 
> [Ahmad] The draft proposes a mechanism to negotiate GRE keys and 
> obviously to be used whenever needed. i.e. GRE encapsulation is an 
> optional feature.

It's also true that one wouldn't negotiate any GRE key if there were no
GRE encapsulation with keys fields to use these GRE keys, no?

If I use IPv6-in-UDPv4 (as DS-MIPv6 suggests) then no need to negotiate
GRE keys, no?

GRE keys aren't used for anything else than GRE tunnels, am I right?

>>>> So in this context, can I ask why GRE?  It's not used by MIPv6,
>>>> was never suggested by DS-MIPv6, can't transport IPv6 and has 
>>>> several implemented alternatives.  Why GRE?
>>> mohamed>> GRE is used in this draft to mark/identify traffic for 
>>> a certain classification, such as for supporting mobile nodes
>> that are
>> I think all other forms of IPv6-in-IPv4 (and in UDPv4) are capable 
>> to deal with the problem of overlapping private IPv4 addressing you
>>  cite in the draft.  Don't you think so?
>> 
>> possible and that some decisions have already been made, and that 
>> GRE tunnelling is straight competitor to the ones I've listed.  A 
>> dynamic method to choose between the available methods is probably 
>> useful.  But I don't see why pushing solely GRE; again, where is 
>> GRE coming from into the PMIP picture?
> 
> [Ahmad] GRE is widely deployed and used and I believe it has a use 
> case in Proxy MIP in general.

But GRE has nothing to do with Mobile IPv6, do you agree.  It may have 
something to do with MIP4 (and probably PMIPv4) but nothing to do with 
MIP6 no?

I'm surprised you propose this... and I'm sure you'll talk me into this :-)

Alex