Subject: [MEXT] Use of MR-HA tunnel for DHCPv6 signalling (in the context of DHCPv6PD for NEMO)

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 11 Apr 2010 19:23:57 +0200

Hi all,

	Reviewing draft-ietf-mext-nemo-pd, some people have commented that the
tunnel between the MR and the HA cannot be used for DHCPv6 signalling
between a DHCPv6 client @ the MR and a DHCPv6 server/relay @ the HA. The
point is that for messages sent to the MR from the HA, the HA is
operating as a CN and then it has to use RH2 to route the packet towards
the MR, instead of the MR-HA tunnel.

	My doubt is the following, Section 10.4.4 of RFC3775 (RFC3775bis does
not change this) says the following:

"10.4.4.  Stateful Address Autoconfiguration

   This section describes how home agents support the use of stateful
   address autoconfiguration mechanisms such as DHCPv6 [29] from the
   mobile nodes.  If this support is not provided, then the M and O bits
   must remain cleared on the Mobile Prefix Advertisement Messages.  Any
   mobile node which sends DHCPv6 messages to the home agent without
   this support will not receive a response.

   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."

Therefore, IMHO it seems that using DHCPv6PD signalling between the MR
and the HA would be perfectly possible, as stated in
draft-ietf-mext-nemo-pd-04. Am I missing something?

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 13 Apr 2010 18:08:44 -0700

Hello again Carlos,

Commenting on the issue below:

Carlos Jesús Bernardos Cano wrote:
> 
> Hi all,
> 
> 	Reviewing draft-ietf-mext-nemo-pd, some people have commented
> that the tunnel between the MR and the HA cannot be used for DHCPv6
> signalling between a DHCPv6 client @ the MR and a DHCPv6 server/relay @
> the HA. The point is that for messages sent to the MR from the HA, the
> HA is operating as a CN and then it has to use RH2 to route the packet
> towards the MR, instead of the MR-HA tunnel.
> 
> 	My doubt is the following, Section 10.4.4 of RFC3775 (RFC3775bis
> does not change this) says the following:
> 
> and the HA would be perfectly possible, as stated in draft-ietf-mext-
> nemo-pd-04. Am I missing something?

The use of RH2 between the HA and the MR does seem to be problematic to me in this situation (and I have raised the issue on the list in the generic context of MIPv6/RFC3775bis) -- let me try to explain why:

If the MR is configured as a DHCP client, it will source the DHCP request from a link-local address. If it does so, the server will have to reply to the link-local destination address. It does not seem possible to deliver such a packet to the MN with a RH2 because of RFC3775...

The last MUST in the paragraph of Section 6.4 "Type 2 Routing Header" quoted below does seem to prevent the HA from sending locally generated packets to the MN's link-local address:

   The new routing header uses a different type than defined for
   "regular" IPv6 source routing, enabling firewalls to apply different
   rules to source routed packets than to Mobile IPv6.  This routing
   header type (type 2) is restricted to carry only one IPv6 address.
   All IPv6 nodes which process this routing header MUST verify that the
   address contained within is the node's own home address in order to
   prevent packets from being forwarded outside the node.  The IP
   address contained in the routing header, since it is the mobile
   node's home address, MUST be a unicast routable address.
   Furthermore, if the scope of the home address is smaller than the
   scope of the care-of address, the mobile node MUST discard the packet

So we have an issue here. I am happy to be told I misunderstood the spec and everything works provided there is an understandable explanation attached to the statement =)

--julien