Subject: RE: [Mipshop] Question on HMIPv6 tunneling

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 28 Jul 2005 16:19:00 +0200

Hi Mikko, hi Theo,

Concerning i)
I think Mikko is almost right, only that the source address of the inner
header is MN's Home Address (HoA) instead of the Home Agent (HA) address
(maybe you meant the same?). Section 6.1 of
draft-ietf-mipshop-hmipv6-04.txt says

"Following a successful registration with the MAP, a bi-directional
   tunnel between the mobile node and the MAP is established. All
   packets sent by the mobile node are tunnelled to the MAP. The outer
   header contains the mobile node's LCoA in the source address field
   and the MAP's address in the destination address field. The inner
   header contains the mobile node's RCoA in the source address field
   and the peer's address in the destination address field. " 

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Dest: MAP    Source: LCoA    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Dest: HA     Source: RCoA    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Dest: CN     Source: HoA     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, the third IP header is not explicitly mentioned in the I-D, but
it is needed to hide a MAP/RCoA change from higher-layers and for
preventing any HMIP-related changes to the HA. For the sake of clarity
an example showing all headers may be helpful in the draft.

Concerning ii)
I didn't find any evidence in the draft that the MAP decapsulates the
intercepted packets before tunneling to LCoA.
Section 6.1 says

"Similarly, all packets addressed to the mobile node's RCoA are
intercepted by
   the MAP and tunnelled to the mobile node's LCoA. "

It certainly would be more efficient to remove the header (one IP header
less on wireless link), since it is not needed for routing anymore. But
there may be issues with that, e.g. if the payload packets between HA
and MN (i.e., MN's RCoA) are protected by Ipsec ESP. Nevertheless, it
may be helpful to clarify this issue in future versions of the draft.

Regards,

Kilian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mikko Hautala
> Sent: Donnerstag, 28. Juli 2005 10:33
> To: [email-masked]
> Subject: [Mipshop] Question on HMIPv6 tunneling
> 
> Hi,
> 
> I'm a student at the Helsinki University of Technology, 
> working with my 
> Master's Thesis.
> I have a dilemma on how HMIPv6 is working, and I thought this mailing 
> list could be a right place to ask
> for advice.
> 
> 
> My question is simple (although it has two parts):
> 
> On the draft it is said that a bi-directional tunnel is 
> formed beetween 
> the MN and MAP and all packets sent
> by the MN are tunneled to the MAP (section 6.1 of the HMIPv6 draft).
> 
> i) Does this mean, that when MN is communicating to CN 
> through HA using 
> reverse tunneling
> (one option in 6.1.1 of the HMIPv6 draft), there are actually 
> three IPv6 
> headers needed when
> MN sends packets to CN ?
> 
> Like:
> 
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  Dest: MAP    Source: LCoA    |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  Dest: HA     Source: RCoA    |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  Dest: CN     Source: HA      |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  Layer 4-> headers            |
>  .				 .
>  
> 
> ii) What about when MAP intercepts packets tunneled from HA to RCoA, 
> that already contain
> two IPv6 headers - does MAP first decapsulate the packet before 
> encapsulating and tunneling
> it to the MN's LCoA ? (in my opinion this isn't directly 
> stated in the 
> section 6.2 HMIPv6 draft)
> 
> 
> 
> 
> 
> 
> Regards,
> Mikko Hautala
> Helsinki University of Technology
> [email-masked]
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 

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

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 28 Jul 2005 18:20:31 +0100

Hi Kilian,

Following the rationale of the section specified, and trying to comply 
with generic tunneling and IP-IP encapsulation semantics, I am trying to 
understand on what basis the protocol stack is going to create two 
(instead of the usual one) headers on top of the original packet 
destined to the CN. Which tunneling standard creates such type of tunnel?

 i.e. the MN creating one header

and then creating the expected return path of the bi-dir tunnel, i.e.

>   and the peer's address in the destination address field. " 

that is very true. I did not find one either. I just went by the 
encapsulation semantics of existing standards. I could not see how else 
one could do it without inventing a new tunneling standard (which for me 
would be unnecessary unless somebody could show the opposite)..

>may be helpful to clarify this issue in future versions of the draft.
For Ipsec I was under the impression that each tunnel was taking care 
security on the entire encapsulation content, to keep matters 
clean..maybe the hooks to that need to be clarified on that section of 
the draft either way..

Regs
theo