Subject: [mobile-ip] Special-case tunnel forwarding

From: Marc Hasson <[email-masked]>
Date: Mon, 13 Jan 2003 02:33:44 -0800 (PST)

All,

I have concerns with the new clause, starting with the word "except",
that was added to the sentence below in section 10.4.2 for the pre-20
draft.  I saw this issue go by without any discussion about Jari's
updates sometime in December but it wasn't until a recent IPsec thread
and seeing it in the pre-20 draft that its implications really struck
me.  My apologies for so many late words to comment on such a short new
clause:

In 10.4.2:

   However, packets addressed to the mobile node's link-local address
   MUST NOT be tunneled to the mobile node except when they carry MLD or
   stateful address configuration protocols.

The above sentence is not precise to me with regards to MLD where every
packet is addresed to a multicast address of link scope, not a
link-local address (only MLD source addresses will be link-local).
Also, there is a new forwarding decision requirement placed on HA
forwarding code by the above, at least for the address configuration
protocols (DHCPv6?), that seems to be of questionable value.

Specific issues/concerns detail:

a) I'm assuming its true that "MLD" in the above is referring to the
   interception and forwarding of MLD packets that originated from
   outside the HA?  These would be Queries from multicast routers and
   Reports/Dones from hosts on the home network.

   If my assumption is correct then note that all those packets are
   addressed to some multicast address (all-nodes, all-routers, or
   specific) and thus are *not* addressed to the MN's link-local
   address as implied above.  These packets are addressed to a
   link-local scope multicast address.  As an aside I note that this
   conflicts with the next to last paragraph in 10.4.2 where link-local
   scope multicasts are *not* to be sent to the MN, clearly some MLDs
   must be.

b) The excerpt requires IPv6 forwarding code to process packet headers
   beyond the base header and IPv6 extensions in order to make a
   "forwarding" decision for a packet that is already known not to be
   locally destined (as well as which tunnel it should be sent out).
   This seems counter to the IPv6 packet processing described in RFC
   2460.  Worse, it also requires "wiring in" knowledge of application
   protocols such as DHCPv6 UDP server port as well as the ICMPv6 MLD
   codes (and eventual additional MLDv2 codes and formats) into forwarding
   logic.

   What if non-mobility protocols change or we think of additional
   protocols to be tunneled that might not be so easy to parse/select?
   What if some implementation finds it convenient/useful to tunnel
   other link-local addressed protocols, are they no longer conformant
   to this standard?

c) Fragmentation potential.  MLDv1 packets are very short while eventual
   MLDv2 packets are potentially large but constrained (in the current
   draft) to a link MTU, so we should be OK there.  But the DHCPv6
   draft spec says a server "SHOULD limit" its responses to avoid
   fragmentation.  I note thats not a MUST so a robust HA tunnel
   forwarding implementation must now be potentially prepared to
   reassemble all MN-destined link-local fragments and *then* make its
   tunnel forwarding decision (on the upper layer protocol info) in
   order to be sure it only forwards the proper DHCPv6 packets based on
   the excerpt.

d) What happens to multicast packets issued by the HA itself due to HA-local
   applications joining groups (MLD) or issuing multicast data
   packets?  Are these tunneled, as opposed to routing header'ed, to
   the MN?  Though these come from the HA itself I'd like to see just
   the one tunnel mechanism used for multicasts to the MN, think of
   these multicasts as coming off the home network even if put there by
   the HA itself.  But I don't feel strongly about which way these
   HA-originated multicasts are encapsulated to the MN.  Less
   variations is better for implementation and conformance testing, I
   think.

e) Security obscurity.  If either DHCPv6 or MLD[v2] decided to use
   encrypting IPsec or otherwise obscure the payload then this upper
   layer checking in the forwarding code isn't going to work.  The risk
   of header obscurity increases if we broaden our HA special-case
   forwarding logic to make allowances for additional protocols.

f) Reverse tunneled packets.  I know this is a note on HA packet interception
   but should some of the same checks (MLD, DHCPv6) be done on inbound
   so that only these types of packets are allowed in from the MN?  Or
   do we not care and just forward anything legal the MN has given to
   us, from a valid home/link source address associated with the IPsec
   SA used for the MN->HA tunnel?  I prefer the later.

g) Denial of forwarding action for multicast packets.  The first excerpted
   sentence in 10.4.2 is followed by:

                  ...                         Instead, such a packet
   MUST be discarded, and the home agent SHOULD return an ICMP
   Destination Unreachable, Code 3, message to the packet's Source
   Address (unless this Source Address is a multicast address). 

   I assume that there will be either some MLDs or plain multicast data
   packets that will not be tunneled to the MN, presumably due to the
   MN not being subscribed.  Such packets clearly should *not* receive
   an ICMP response since their *Destination* Address was a multicast.
   I believe the intent of the above was just for the original unicast
   link-local addresses and may be a tad confusing with the throwing in
   of MLD in the first excerpt.  The MLD reference should perhaps be
   split out from that excerpt and moved elsewhere (lower in 10.4.2,
   with other multicast discussion).

2 suggestions for resolution of my link-local issues/concerns:

Tunnel *all* MN link-local address destined packets to the MN, not just
DHCPv6.  Though the code can be written to address most of the concerns
above to support the current text (protocol specific processing,
reassembly, etc.) it seems like it could be fragile over time and adds
a complexity for a gain of DHCPv6 support that I think can be achieved
by other simpler or more standard means.  Since we're opening up
link-locals for DHCPv6 perhaps we should generalize this for other
link-locals as well, since its clear the MN has some ability to figure
out where to send link-locals.  Perhaps the default is always just to
tunnel link-locals back to the home link unless explicitly overriden by
roaming incoming link-locals (which would get a unique interface
associated) or MN applications which specified non-default
sin6_scope_ids for their link-local destinations.

However, I can appreciate that even though IPv6 APIs have a facility to
associate an interface with an incoming/outgoing link-local it still
may be too onerous for MNs to deal generally with link-locals.  Clearly
any sophisticated/distributed application could not make use of them
(as many of us heard far too often on the IPNG mailing list concerning
site-locals) but I would have hoped that any MN system/configuration
applications could simply use these link-locals for their
point-to-point nature.

But if we really need to not go too general with link-locals being
forwarded, even though making the MN seem "at home" is what mobility is
trying to achieve, I offer a second suggestion.  Has mandating either a
DHCPv6 relay or server physically reside on an HA whose MNs require
such DHCPv6 support been discussed?  This would leave us with tunneling
link-local scope/address DHCPv6 packets through the MN<->HA IPsec
tunnel but prevent any other MN link-local traffic with the home
network so MNs don't have to deal generally with the ambiguity of
link-local addresses from the home network, even though those clearly
arrive via a tunnel.  The subject excerpt at the beginning of this
note would go back to its -19 version, as far as link-local packet
interception.  Forcing a DHCPv6 relay to reside on an HA for those
administraters who wish to support DHCPv6 for MIPv6 home addresses
doesn't seem unreasonable to me.

   -- Marc --

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 06:08:13 +0100 (CET)

>    stateful address configuration protocols.

I was less than happy with that wording as well.

I actually don't think there is any *forwarding* of MLD messages
at the HA.

In any case, the MN doesn't do any forwarding of MLD messages - it just
sends and receives then (using link-local addresses) on the conceptual tunnel
interface it has for the tunnel to the HA.

The HA is a router by definition (it forwards packets that are not explicitly 
addressed to itself). As such it can either run a multicast routing protocol
or be an MLD proxy.
In the first case it sends and receives MLD messages on the conceptual tunnel
interface to its MNs.
In the second case it operates as described in draft-ietf-magma-igmp-proxy.
In neither case does it *forward* MLD messages. ("relay" is
not the same as "forward" - the latter implies a standard IP operation
of decrementing hopcount etc)

BTW: I haven't thought carefully about whether the first case (HA being
a multicast router) works unless the home link is a virtual link.
But I don't think we need to go into those details in this spec.

> DHCPv6.  Though the code can be written to address most of the concerns

I don't think that is a good idea. To do this cleanly all the ND packets
(RAs, NS/NA, etc) would be tunneled to the MN.
Plus it violates the notion that the tunnel is a different link than the
home link.

  Erik