Subject: RE: [Mip6] GRE key

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 2 May 2007 12:30:15 -0400

> 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?

Alex,

If the LMA (or the HA) has overlapping IPv4 address pools, how does it
distinguish the incoming (tunneled) packets? Note that the LMA/HA needs
to make this distinction for making next hop decision. For private IPv4
addresses, that means identifying the VLAN tag or tunnel id or the
network interface on the egress side of the LMA/HA.

AFAIK, GRE keys are used for this purpose.

-Kuntal

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2007 11:43 AM
> To: Mohamed Khalil
> Cc: [email-masked]
> Subject: Re: [Mip6] GRE key
> 
> 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,
> >>
> >> 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.
> >
> > 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.
> >
> > Mohamed>> should be use to transport IP6 too.
> 
> 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).
> >>
> >> 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]
> 
> 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?
> 
> >> 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
> > 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
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> _______________________________________________
> 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: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 May 2007 00:08:27 +0200

Chowdhury, Kuntal wrote:
>> 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
> If the LMA (or the HA) has overlapping IPv4 address pools, how does 
> it distinguish the incoming (tunneled) packets?

By means of mappings between addresses in the outer and inner headers.
In no case by means of a new identifier (key) used as an address.

> Note that the LMA/HA needs to make this distinction for making next 
> hop decision. For private IPv4 addresses, that means identifying the
>  VLAN tag or tunnel id or the network interface on the egress side of
>  the LMA/HA.

Look, we don't even have a clear idea where _one_ NAT is placed in this
PMIPv6/v4 picture (the draft doesn't place _any_ NAT) and we speculate
about two overlapping private spaces.

Where are the two NATs placed?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 May 2007 11:28:19 +0200

Casati, Alessio (Alessio) wrote:
> Kuntal's view is correct from here too.

Where are the NATs?  I don't see them.

Alex

> 
> Alessio 
> 
> *-----Original Message-----
> *From: Chowdhury, Kuntal [mailto:[email-masked]] 
> *Sent: 02 May 2007 17:30
> *To: Alexandru Petrescu; Mohamed Khalil
> *Cc: [email-masked]
> *Subject: RE: [Mip6] GRE key
> *
> *> 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?
> *
> *Alex,
> *
> *If the LMA (or the HA) has overlapping IPv4 address pools, how 
> *does it distinguish the incoming (tunneled) packets? Note that 
> *the LMA/HA needs to make this distinction for making next hop 
> *decision. For private IPv4 addresses, that means identifying 
> *the VLAN tag or tunnel id or the network interface on the 
> *egress side of the LMA/HA.
> *
> *AFAIK, GRE keys are used for this purpose.
> *
> *-Kuntal
> *
> *
> *
> *> -----Original Message-----
> *> From: Alexandru Petrescu [mailto:[email-masked]]
> *> Sent: Tuesday, April 24, 2007 11:43 AM
> *> To: Mohamed Khalil
> *> Cc: [email-masked]
> *> Subject: Re: [Mip6] GRE key
> *> 
> *> 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,
> *> >>
> *> >> 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.
> *> >
> *> > 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.
> *> >
> *> > Mohamed>> should be use to transport IP6 too.
> *> 
> *> 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).
> *> >>
> *> >> 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]
> *> 
> *> 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?
> *> 
> *> >> 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 
> *> > 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
> *> 
> *> 
> *> 
> *______________________________________________________________________
> *> This email has been scanned by the MessageLabs Email Security System.
> *> For more information please visit http://www.messagelabs.com/email 
> *> 
> *______________________________________________________________________
> *> 
> *> _______________________________________________
> *> 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: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 3 May 2007 08:19:53 -0500

Hi Alex,
Please see comment inline.

> Where are the NATs?  I don't see them.

That is the key Alex, there is no NAT in the PMIP domain for this case.
I believe the figure in the draft is quite straight forward. If you need
further discussion on this we can do it offline, if you prefer.

> > *> 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?
> > *
> > *Alex,
> > *
> > *If the LMA (or the HA) has overlapping IPv4 address pools, 
> how *does 
> > it distinguish the incoming (tunneled) packets? Note that 
> *the LMA/HA 
> > needs to make this distinction for making next hop *decision. For 
> > private IPv4 addresses, that means identifying *the VLAN 
> tag or tunnel 
> > id or the network interface on the *egress side of the LMA/HA.
> > *
> > *> Sent: Tuesday, April 24, 2007 11:43 AM *> To: Mohamed 
> Khalil *> Cc: 
> > [email-masked] *> Subject: Re: [Mip6] GRE key *> *> 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
> > *> >
> > *> >
> > *> >> 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.
> > *> >
> *transports 
> > IPv4.
> > *> 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 *> > 
> > *> >> is Generic Packet Tunnelling rfc2473 (not GRE); and 
> it maybe *> 
> > >> inherits from DS-MIPv6 whose method of transporting IPv6 
> *over IPv4 
> > *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).
> > *> >
> > *> > 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 *> 
> *deployed 
> > code *> that doesn't assume GRE then where would GRE necessity come 
> > from?
> > *Could
> > *> you answer this?
> > *>
> > *> >> 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 *> > using overlapping private IPv4 addressing.
> > *>
> > *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 
> > *into *> the PMIP picture?
> > *>
> > *> Alex
> > *>
> > *>
> > *>
> > 
> *_____________________________________________________________________
> > _ *> This email has been scanned by the MessageLabs Email Security 
> > System.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 May 2007 16:08:24 +0200

Ahmad Muhanna wrote:
> Hi Alex, Please see comment inline.
> 
> That is the key Alex, there is no NAT in the PMIP domain for this
> case. I believe the figure in the draft is quite straight forward.

If there's no NAT then how did people end up designing their address
architecture so badly that address spaces overlap?

Alex

> If you need further discussion on this we can do it offline, if you
> prefer.
> 
>> Alex
>> 
>>> Alessio
>>> 
>>> *-----Original Message----- *From: Chowdhury, Kuntal
>>> [mailto:[email-masked]] *Sent: 02 May 2007 17:30 
>>> *To: Alexandru Petrescu; Mohamed Khalil *Cc: [email-masked] 
>>> *Subject: RE: [Mip6] GRE key * *> I think all other forms of
>>> IPv6-in-IPv4 (and in UDPv4)
>> are *capable
>>> cite *in *> the draft.  Don't you think so? * *Alex, * *If the
>>> LMA (or the HA) has overlapping IPv4 address pools,
>> how *does
>>> id or the network interface on the *egress side of the LMA/HA. * 
>>> *AFAIK, GRE keys are used for this purpose. * *-Kuntal * * * *>
>>> -----Original Message----- *> From: Alexandru Petrescu
>>> [mailto:[email-masked]] *> Sent: Tuesday, April 24,
>>> 2007 11:43 AM *> To: Mohamed
>> Khalil *> Cc:
>>>  wrote: *> > Hi Alexandru, *> > *> > -----Original Message-----
>>> From: Alexandru Petrescu *> > 
>>> [email-masked] Subject: *> > Re: [Mip6] GRE key *> > *> > *> >
>>> Mohamed Khalil wrote: *> >> 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]
>>>>> to negotiate GRE encapsulation mode and along with the GRE *>
>>>>> >>
>>> those  flows. *> > *> > 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. *> > *> > Mohamed>> should be use to transport IP6
>>> too. *> *> 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 *>
>>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> I think
>>> it is also obvious that PMIPv6 done in netlmm
>> WG should
>>> 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, *> >
>>> 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? *> *> >> 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 *> > 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
>>> cite *in *> the draft.  Don't you think so? *> *> Please don't
>>> get me wrong.  I think many forms of
>> tunnelling are *>
>>> *> 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 *> *> *>
>>> 
>>> _ *> This email has been scanned by the MessageLabs Email
>>> Security System. *> For more information please visit
>> http://www.messagelabs.com/email
>>> *>
>>> 
>>> _ *> *> _______________________________________________ *> Mip6
>>> mailing list *> [email-masked] *>
>>> https://www1.ietf.org/mailman/listinfo/mip6 * 
>>> *_______________________________________________ *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 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 3 May 2007 09:14:36 -0500

Hi Alex,

We are talking about the home address here for different VPNs, for
example, that the HA supports and it is possible for two MNs from two
different VPNs roam at the same time in the area of a single MAG with
the same home private IP address.

I hope this would help.

Regards,
Ahmad

> Sent: Thursday, May 03, 2007 9:08 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Alexandru Petrescu; Casati, Alessio (Alessio); 
> [email-masked]; Khalil, Mohamed (RICH2:2S20)
> If there's no NAT then how did people end up designing their 
> address architecture so badly that address spaces overlap?
> 
> Alex
> 
> >>> cite *in *> the draft.  Don't you think so? * *Alex, * 
> *If the LMA 
> >>> (or the HA) has overlapping IPv4 address pools,
> >> how *does
> >>> Mohamed Khalil wrote: *> >> Hi All, *> >> *> >> The 
> following draft 
> >>> has been posted on netlmm, your
> >> comments and
> >>> 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?
> >>>  *IPv6-in-IPv6 which *> >> is Generic Packet Tunnelling 
> rfc2473 (not 
> >>> GRE); and
> >> it maybe *>
> >>> *number 41 *> >> rfc2893 (yet again not GRE). *> >> *> >> 
> I think it 
> >>> is also obvious that PMIPv6 done in netlmm
> >> WG should
> *> *> What 
> >>> I mean is that if the PMIP approach relies on some
> >> *deployed
> >>> from? *Could *> you answer this? *> *> >> So in this 
> context, can I 
> >>> several *> >> implemented alternatives.  Why GRE? *> > *> >
> >>> cite *in *> the draft.  Don't you think so? *> *> Please 
> don't get 
> >>> me wrong.  I think many forms of
> >> tunnelling are *>
> Security 
> >>> System. *> For more information please visit
> >>> *_______________________________________________ *Mip6 
> mailing list 
> >>> [email-masked] *https://www1.ietf.org/mailman/listinfo/mip6
> >>> *
> >>> 
> >> 
> >> 
> _____________________________________________________________________
> >> _  This email has been scanned by the MessageLabs Email Security

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 May 2007 16:37:21 +0200

> the same home private IP address.

It helps clarifying some parts, in that it may so happen that two MNs 
have the same private IPv4 Home Address.  I will not go as far as saying 
that I find this problem little worth exploring.

[HEre's why:
  Private IPv4 Home Addresses aren't reachable from the Internet, hence
  no need to give them continuous access with Mobile IP.

  MIPv6 doesn't deal with IPv4 Home Addresses.

  DS-MIPv6 doesn't deal with HA behind NAT, hence doesn't deal with
  private IPv4 Home Addresses.]

Maybe, in this order:

-it is thought that GRE is needed for some SDO.  Then it should be
  stated first and foremost.
-it is thought that GRE has something to do with PMIPv6 (not with
  MIPv6).  Then the use of GRE tunnel instead of IPv6-in-IPv6 tunnel
  should be proposed to PMIPv6.
-it is thought that private IPv4 Addresses have something to do with
  DS-MIPv6.  Then the use of one IPv4 private home address should be
  suggested to DS-MIPv6.
-it is thought that overlapping IPv4 Home Addresses are a problem with
  mobility.  Then it should be proposed _after_ the above two steps were
  solved.

Thanks,

Alex

>>>> _

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 3 May 2007 11:10:35 -0400

> Sent: Wednesday, May 02, 2007 5:08 PM
> To: Chowdhury, Kuntal
> Cc: Alexandru Petrescu; Mohamed Khalil; [email-masked]
[KC>] That is the problem. In case of overlapping IP4 HoA pools, two
users on the same MAG may get same IPv4 HoA, the inner and outer headers
will have identical information for two separate users.

> Where are the two NATs placed?
[KC>] Let's assume that tunnels for both the users (with same IPv4 HoA)
pass thorough the same NAT (if there is a NAT). The real issue is, how
to distinguish the tunnels at the LMA/HA. The NAT in the middle of the
MAG/MN and the LMA/HA does not matter since UDP transport addresses the
NAT traversal problem.

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 3 May 2007 11:18:15 -0400

> To: Ahmad Muhanna
> Cc: [email-masked]; Alexandru Petrescu; Casati, Alessio (Alessio)
[KC>] There are pools of addresses in the HA/LMA for each domain it
supports. Some of these domains may be enterprises using private address
space. So, it is often the case that pools of addresses for two domains
on the same HA/LMA are private and overlapping. So, there is a valid use
case for GRE keys to be used to distinguish user traffic for these
domains in the LMA/HA.

The placement of NAT is irrelevant in this case. If there is a NAT in
between MAG/MN and LMA/HA, UDP transport takes care of the traversal.

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 3 May 2007 11:33:51 -0400

> Sent: Thursday, May 03, 2007 9:37 AM
> To: Ahmad Muhanna
[KC>] Nobody is talking about internet routing here. Private IPv4
addressing is widely used in enterprises and campus networks. These
networks are often hosted by operators. FYI....scenarios using private
IPv4 HoA usefully has VPN links back to the respective enterprise/campus
networks.

>   MIPv6 doesn't deal with IPv4 Home Addresses.
[KC>] DS-MIP6 does.

>   private IPv4 Home Addresses.]
[KC>] To support private IPv4 address pools, the HA won't have to be
necessarily behind a NAT from MN/MAGs PoV.

>   stated first and foremost.
[KC>] I do not think we have to bring SDOs into this discussion. 

>   should be proposed to PMIPv6.
[KC>] overlapping IPv4 address pool use case applies to both PMIP6 and
DS-MIP6.

>   DS-MIPv6.  Then the use of one IPv4 private home address should be
[KC>] Not sure that is necessary. 

> >>>>> *into *> the PMIP picture? *> *> Alex *> *> *>
*____________________________________________________________________
> >>>> http://www.messagelabs.com/email
*____________________________________________________________________
System.