Subject: [mobile-ip] Additional text on the DHCP & MLD issue

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 16:49:09 +0200

First: I'm almost done with draft 20 -- I handled some additional issues
from my Inbox yesterday after editing everything that we agreed last week.
The drafts on the web are up to date and the issue list shows no open
issues. But I haven't submitted the drafts yet because I needed some
additional things for the DHCP and MLD issue, and because I wanted
to check some other things. Also, we need to answer Ville's question
on the list (unless we deal with it later).

Then: We're not quite there yet with the last week's text for DHCP and
MLD issue (205 & 206). I think we still need to be clear on the
following issues.

- What the mandatory to support requirements are. Text suggested by
   Gabriel and myself below.

   8.4 IPv6 Home Agents

    o  Every home agent SHOULD support the multicast group membership
       control protocols as described in Section 10.4.3.  If this support
       is provided, the home agent MUST be capable of using it to
       determine which multicast data packets to forward via the tunnel
       to the mobile node.

    o  Home agents MAY support stateful address autoconfiguration for
       mobile nodes as described in Section 10.4.4.

   8.5 IPv6 Mobile Nodes

    o  The node MAY support the multicast address listener part of a
       multicast group membership protocol as described in Section
       11.3.4.  If this support is provided, the mobile node MUST be able
       to receive tunneled multicast packets from the home agent.

    o  The node MAY support stateful address autoconfiguration mechanisms
       such as DHCPv6 [28] on the interface represented by the tunnel to
       the home agent.

- What the normative references are. This can be solved equivalently
   with the above, i.e. mldv1 is the only normative reference.

- We need the mobile nodes to know whether the home agent supports
   MLD or not. Again text from Gabriel:

     A mobile node MUST NOT tunnel multicast group membership control packets
     until (1) the mobile node has a binding in place at the home agent, and
     (2) the latter sends at least one such multicast group membership
     control packet via the tunnel. Once this condition is true, the mobile
     node SHOULD assume it does not change as long as the binding does not
     expire.

- Text to describe how these protocols are secured when tunneled to
   the home agent. The following text clarifies the requirements
   for this:

     For traffic tunneled via the home agent, additional IPsec ESP
     encapsulation MAY be supported and used. If multicast group membership
     control protocols or stateful address autoconfiguration protocols are
     supported, payload data protection MUST be supported.

   The details for turning the protection on depend on the particular
   addresses used. Fortunately, since the SPD entries are already
   expected to be interface-specific this appears easier than otherwise.
   In effect, we don't necessarily need one of the addresses in the
   packet to be the home address. See

     http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html#anchor13

   which contains this text:

    If multicast group membership control protocols such as MLDv1 [8] or
    MLDv2 [11] need to be protected, these packets may use a link-local
    address rather than the home address of the mobile node.  In this
    case the source and destination can be left as a wildcard and the SPD
    entries will work solely based on the used interface and the
    protocol, which is ICMPv6 for both MLDv1 and MLDv2.

    Similar problems are encountered when stateful address
    autoconfiguration protocols such as DHCPv6 [9] are used.  The same
    approach is applicable for DHCPv6 as well.  DHCPv6 uses the UDP

- Finally, I have edited home agent sections for DHCP and MLD according
   to the above. The new text is shown below:

10.4.3 Multicast Membership Control

    This section is a prerequisite for the multicast data packet
    forwarding described in the previous section.  If this support is not
    provided, multicast group membership control messages are silently
    ignored.

    In order to tunnel forward multicast data packets from the home
    network to all the proper mobile nodes the home agent SHOULD be
    capable of receiving tunneled multicast group membership control
    information from the mobile node in order to determine which groups
    the mobile node has subscribed to.  These multicast group membership
    messages are Listener Report messages specified MLD [17] or in other
    protocols such as [35].

    The messages are issued by the mobile node but sent through the
    reverse tunnel to the home agent.  These messages are issued whenever
    the mobile node decides to enable reception of packets for a
    multicast group or in response to an MLD Query from the home agent.
    The mobile node will also issue Report messages to disable reception
    of multicast packets when it is no longer interested in receiving
    multicasts for a particular group.

    To obtain the mobile node's current multicast group membership the
    home agent must periodically transmit MLD Query messages through the
    tunnel to the mobile node.  These MLD periodic transmissions will
    ensure the home agent has an accurate record of the groups in which
    the mobile node is interested despite packet losses of the mobile
    node's MLD group membership messages.

    All MLD packets are sent directly between the mobile node and the
    home agent.  Since these packets all contain a link-local source
    address, are destined to a link-scope multicast address, and have a
    hop limit of 1 there is no direct forwarding of such packets between
    the home network and the mobile node.  The MLD packets between the
    mobile node and the home agent are encapsulated within the same
    tunnel header used for other packet flows between the mobile node and
    home agent.

    Note that at this time, even though a link-local source is used on
    MLD packets, no functionality depends on these addresses being
    unique, nor do they elicit direct responses.  All MLD messages are
    sent to multicast destinations.  To avoid ambiguity on the home agent
    due to mobile nodes which may choose identical link-local source
    addresses for their MLD function it is necessary for the home agent
    to identify which mobile node was actually the issuer of a particular
    MLD message.  This may be accomplished by noting which tunnel such an
    MLD arrived by, which IPsec SA was used, or by other distinguishing
    means.

    This specification puts no requirement on how the functions in this
    section and the multicast forwarding in Section 10.4.2 are to be
    achieved.  At the time of this writing it was thought that a full
    IPv6 multicast router function would be necessary on the home agent,
    but it may be possible to achieve the same effects through a "proxy
    MLD" application coupled with kernel multicast forwarding.  This may
    be the subject of future specifications.

10.4.4 Stateful Address Autoconfiguration

    This section describes how home agents support the use of stateful
    address autoconfiguration mechanisms such as DHCPv6 [28] from the
    mobile nodes.  If this support is not provided, then the M and O bits
    must remain reset on the Mobile Prefix Advertisement Messages.  Any
    mobile node which issues autoconfiguration queries for servers
    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 can not 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.

Jari

---

From: Marc Hasson <[email-masked]>
Date: Mon, 20 Jan 2003 12:35:21 -0800 (PST)

Jari,

Everything looks ok to me, both in this note and what I checked at the

 >     multicasts for a particular group.

I would change "Report" in the above to be our generic "MLD group
membership" term since in MLDv1 it may be a "Done" message thats used
to disable reception, not a Report.

   -- Marc --