Subject: [MEXT] Use of RH2 from the HA to the MN

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 5 Apr 2010 11:04:58 -0700

<no chair hat>

Jean-Michel has pointed out to me the following provision in RFC 3775 and 3775bis that I overlooked and which I suspect is largely ignored: 

10.4.2.  Processing Intercepted Packets

   For any packet sent to a mobile node from the mobile node's home
   agent (in which the home agent is the original sender of the packet),
   the home agent is operating as a correspondent node of the mobile
   node for this packet and the procedures described in Section 9.3.2
   apply.  The home agent then uses a routing header to route the packet
   to the mobile node by way of the primary care-of address in the home
   agent's Binding Cache.

[ Editorially, it is a bit weird that text describing handling of packets locally generated at the HA is found in a section entitled "Processing Intercepted Packets." I understand it is there to exclude such packets from being subject to the rest of the provisions on intercepted packets, but I don't think it is the best place... ]

I want to make the following observation here: Excluding packets locally generated at the HA, a Mobile Node that does not engage in route optimization with its correspondent will never have to receive and process RH2. Thus, one can see Route Optimization and RH2 as somehow optional components of Mobile IPv6. However, due to this provision, it is mandatory for a  Mobile Node to be able to receive and process RH2 even though it's never going to do route optimization. 

IMHO, this is a marginal optimization of the tunneling overhead for a corner case (HA generating locally packets to the MN) that comes at the cost of increased and unnecessary complexity because it mandates RH2 support for every MN while it could have been limited to MN supporting route optimization. 

I would thus like us to remove this provision and use IP-in-IP tunneling for all packets (locally generated, forwarded, and intercepted) sent to the MN Home Address.

What do people think?

--julien

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 05 Apr 2010 12:08:02 -0700

Hello Julien,

In the situation described, the home agent is
hosting some application that isn't directly
making use of the home agent feature.  Perhaps
someone logged into that host is trying "ping"
or browsing a web page on the mobile node.

I'm willing to agree that the optimization
isn't important, but maybe the separation of
functionality is important.  So, for instance,
a Mobile IPv6-compliant node, corresponding
with many mobile nodes, should be able to
use RH2 with all of them, given the existence
of binding cache entries for them.  If the
correspondent node also just happens to be
a home agent for one of them, does it somehow
stop wanting to use RH2 even if the application
has no knowledge that the underlying host is
also acting as the mobile node's home agent?

Regards,
Charlie P.

On 4/5/2010 11:04 AM, Laganier, Julien wrote:
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Kowsalya Subramanian <[email-masked]>
Date: Tue, 6 Apr 2010 18:40:13 +0530

Whether a mobile node wants RO or not, the moment a node sends a BU,
wouldn't it be prepared to process packets with RH2? Wouldn't the HA use RH2
even when sending BA? As per my understanding, RH2 is not an optional
component of MIPv6.

Kowsalya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laganier, Julien
Sent: Monday, April 05, 2010 11:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: [MEXT] Use of RH2 from the HA to the MN

<no chair hat>

Jean-Michel has pointed out to me the following provision in RFC 3775 and
3775bis that I overlooked and which I suspect is largely ignored: 

[ Editorially, it is a bit weird that text describing handling of packets
locally generated at the HA is found in a section entitled "Processing
Intercepted Packets." I understand it is there to exclude such packets from
being subject to the rest of the provisions on intercepted packets, but I
don't think it is the best place... ]

I want to make the following observation here: Excluding packets locally
generated at the HA, a Mobile Node that does not engage in route
optimization with its correspondent will never have to receive and process
RH2. Thus, one can see Route Optimization and RH2 as somehow optional
components of Mobile IPv6. However, due to this provision, it is mandatory
for a  Mobile Node to be able to receive and process RH2 even though it's
never going to do route optimization. 

IMHO, this is a marginal optimization of the tunneling overhead for a corner
case (HA generating locally packets to the MN) that comes at the cost of
increased and unnecessary complexity because it mandates RH2 support for
every MN while it could have been limited to MN supporting route
optimization. 

I would thus like us to remove this provision and use IP-in-IP tunneling for
all packets (locally generated, forwarded, and intercepted) sent to the MN
Home Address.

What do people think?

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 06 Apr 2010 15:52:16 +0200

Hi,

Kowsalya Subramanian <[email-masked]> writes:

> wouldn't it be prepared to process packets with RH2?

Yes, it MUST be prepared to receive such packets, as defined in RFC
3775:

8.5.  IPv6 Mobile Nodes
   ...
   o  The node MUST be able to process type 2 routing header as defined
      in Section 6.4 and Section 11.3.3.

So:

  - MN: ability to receive and process RH2
  - RO supporting MN: additional ability to send RH2

> Wouldn't the HA use RH2 even when sending BA?

RFC 3775, RFC 3776 and RFC 4877 expect that to happen and require
support for at least the following layout:

      IPv6 header (source = home agent,
                   destination = care-of address)
      Routing header (type 2)
         home address
      ESP header in transport mode
      Mobility header
         Binding Acknowledgement

The tunnel version is described in RFC 4877 with the following comment:

   The support for the above tunneled packet format is optional on the
   mobile node and the home agent.

> As per my understanding, RH2 is not an optional component of MIPv6.

+1, i.e. it is not an optional component of MIPv6.

But to go in Julien's direction, this degenerated tunnel solution was
IMHO some kind of premature optimization in the protocol.

Additionally, considering IPsec protection of BA is required, this
explicit information (RH2 carrying the HoA) is not required, as the
IPsec SPI already implicitly provide a link to the HoA on the receiver.

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 13 Apr 2010 17:06:32 -0700

Hi Julien,

Is your proposal that 3775bis prohibits using RH/HoA options for data packets (other than MH) between MN and HA ?
I am fine with it. 

My memory is vague, but I saw one ESP tunneled packet having RH between HA and MN a long time ago. 
The packet is somehow valid according to RFC3775, but it's really redundant.

regards,
ryuji

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 15 Apr 2010 09:47:28 -0700

Hi Ryuji,

Ryuji Wakikawa wrote:
> 
> Hi Julien,
> 
> Is your proposal that 3775bis prohibits using RH/HoA options for data
> packets (other than MH) between MN and HA ?

Hmm. I wouldn't say prohibit, I'd follow the "be conservative in what you send and liberal in what you accept" motto. Mandate the HA and MN to use IPIP tunnel for sending data packets and still accept RH2/HoA options on receiving side.
 
> The packet is somehow valid according to RFC3775, but it's really

It would be valid with what I'm proposing. It's not only redundant but harmful since it makes the implementation complex in light of the following text in Section 10.4.4. (Stateful Address Autoconfiguration) of RFC3775 that Carlos pointed out while discussing DHCP PD for NEMO:

   If DHCPv6 is used, packets are sent with link-local source
   addresses either to a link-scope multicast address or a
   link-local address. Mobile nodes desiring to locate a DHCPv6
   service may reverse tunnel standard DHCPv6 packets to the home
   agent. Since these link-scope packets cannot be forwarded onto
   the home network, it is necessary for the home agent to either
   implement a DHCPv6 relay agent or a DHCPv6 server function
   itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope
   messages from the mobile node must be noted so that DHCPv6
   responses may be sent back to the appropriate mobile node.
   DHCPv6 messages sent to the mobile node with a link-local
   destination must be tunneled within the same tunnel header
   used for other packet flows.

Since RFC 3775 currently has a provision on using RH2 for traffic locally generated at the HA, the text above reads like an RH2-exemption is afforded to DHCP.

How is that supposed to be implemented? Is the Mobile IPv6 forwarding code supposed to look at UDP port numbers to find out what's DHCP and IPIP tunnel it, and what's not DHCP and RH2-route-it?

--julien

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 19:07:32 +0200

Hi Julien, 

I am in favor of mandating the use of IPIP tunnelling for data packets while
recommending against the use of RH2/HoA options but not explcitly
prohibiting it.

-Raj

On 4/15/10 11:47 AM, "ext Laganier, Julien" <[email-masked]> wrote:

> Hmm. I wouldn't say prohibit, I'd follow the "be conservative in what you send
> and liberal in what you accept" motto. Mandate the HA and MN to use IPIP
> tunnel for sending data packets and still accept RH2/HoA options on receiving
> side.
> 
>> I am fine with it.
>> 
> It would be valid with what I'm proposing. It's not only redundant but harmful
> since it makes the implementation complex in light of the following text in
> Section 10.4.4. (Stateful Address Autoconfiguration) of RFC3775 that Carlos
> pointed out while discussing DHCP PD for NEMO:
> 
> Since RFC 3775 currently has a provision on using RH2 for traffic locally
> generated at the HA, the text above reads like an RH2-exemption is afforded to
> DHCP.
> 
> How is that supposed to be implemented? Is the Mobile IPv6 forwarding code
> supposed to look at UDP port numbers to find out what's DHCP and IPIP tunnel
> it, and what's not DHCP and RH2-route-it?
> 
> --julien

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 28 Apr 2010 23:48:07 -0500

Was there a conclusion on this? I went through the email thread, but
couldn't find anything.

IMO, its not clear to me why RH2 should be prohibited on the mobile node, if
it is not supporting route optimization. RH2 is supposed to be used by any
node that has a binding for the mobile node when it sends packets to the
mobile node. This includes the home agent.

So, I disagree with this change.

Vijay

On 4/5/10 11:04 AM, "Laganier, Julien" <[email-masked]> wrote:

> generated at the HA, a Mobile Node that does not engage in route optimization
> with its correspondent will never have to receive and process RH2. Thus, one
> can see Route Optimization and RH2 as somehow optional components of Mobile
> IPv6. However, due to this provision, it is mandatory for a  Mobile Node to be
> able to receive and process RH2 even though it's never going to do route
> optimization.
> 
> increased and unnecessary complexity because it mandates RH2 support for every
> MN while it could have been limited to MN supporting route optimization.
>