Subject: [mobile-ip] Suggested text for issues 205 & 206

From: Marc Hasson <[email-masked]>
Date: Wed, 15 Jan 2003 12:11:56 -0800 (PST)

All,

Here's some suggested text changes to the main document to deal with
the DHCPv6 and MLD/multicast forwarding issues.  I have not put any
efforts into thinking of the ha-ipsec document changes required, I
won't have time to do so in the very near-term.

I regard the text below as "starter" text for these issues, there are
some open questions here in my mind as to what the requirement level
should be for either multicast or DHCPv6 support for either home agents
or mobile nodes.  My understanding is that neither DHCPv6 nor multicast
routing for IPv6 are yet to proposed standard.  If I'm wrong, please
speak up.  Even if I'm wrong its still a valid working group question
whether such support should be mandatory before a home agent can be
deployed.  I have chosen SHOULD in my text below with a parenthesized
MUST as a question.  Some minor tweaking is needed if MUST is chosen by
the working group.

I've not added any text to the mobile node descriptions.  We don't have
any protocol support to inform the mobile node as to whether multicast
routing or DHCPv6 support is provided by a given home agent.  My feeling
is that mobile nodes should be free to attempt to issue MLD Reports
or DHCPv6 probes but the lack of any response (MLD Query, multicasts,
or DHCPv6 responses) is the indication of no support.  Since I'm not
aware of anything that depends on these functions this may be just
fine.  Alternately, multicast forwarding and DHCPv6 support can be made
mandatory on home agents.  I believe that was the current reading of
the working group but that was before we decided that the home agent
now has to "host" more multicast and DHCP functionality too.

The basic approach, as mentioned on the mailing list, is to require
either/both a DHCPv6 relay agent or multicast routing/forwarding functions
for the corresponding support of either DHCP or multicast packets.
As discussed, link-local destination or link-scope multicast addresses
will not be simply forwarded to a MN by the HA from the home network.
Such packets must be issued/controlled by functions on the home agent
by other than just simple-minded forwarding decisions in the IPv6 stack.

  -- Marc --

Text changes:

Section 10.4.2
--------------

Change:

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. 

Back to:

However, packets addressed to the mobile node's link-local address MUST NOT
be tunneled to the mobile node.

Section 10.4.2
----------------

Change/Delete (will reappear in a later section in another form):

The home agent MUST 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. This involves running
MLD[27] inside the tunnel using link-local addresses. 

To:

Interception and tunneling of the following multicast addressed packets
on the home network are only done if the home agent supports mobile
node multicasts as in the next (10.4.2+?) section.

Section 10.4.2
----------------

Following this text:

(after delivering to other local multicast recipients). Multicast packets
addressed to a multicast address with scope larger than link-local but
smaller than global (e.g., site-local and organization-local[3]), to which
the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node by
default. This behavior MUST be configurable to allow it to be enabled. Note
that this default behavior might change at some point in the future as the
definition of these scopes become more completely defined in IPv6.

Add within the same paragraph (just for clarity/completeness):

Multicast packets addressed with a global scope to which the mobile node
is subscribed MUST be tunneled to the mobile node.

New section 10.4.2+ (following current 10.4.2)
----------------------------------------------

10.4.2+ Mobile Node Multicast Membership Support

The support described in this section SHOULD (MUST?) be implemented and
is a prerequisite for the multicast data packet forwarding described in
the previous section.  If this support is not provided any mobile
node MLD Reports are silently ignored.

In order to tunnel forward multicast data packets from the home network to
all the proper mobile nodes the home agent MUST 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 standard MLD [27]
Report messages issued by the mobile node but sent through the reverse
tunnel to the home agent.  The mobile node issues such Reports in the
standard MLD manner: whenever the mobile node decides to join a multicast
group or in response to an MLD Query from the home agent.  The mobile
node will also issue MLD Done messages 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 standard MLD periodic transmissions will ensure
the home agent has an accurate record of the groups the mobile node is
interested in despite packet losses of the mobile node's MLD Reports or
MLD Dones.

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 one depends upon these addresses being unique or even responds
directly to them.  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 of the previous 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.

New section 10.4 section
------------------------

10.4.x Home Agent DHCPv6 support

The support described in this section SHOULD (MUST?) be implemented in
order to allow mobile nodes to use standard DHCPv6 mechanisms.  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 DHCPv6 queries for servers without this support will not receive
a response.

DHCPv6 packets are sent with link-local source addresses either to
a link-scope multicast address or a link-local address.  Mobile node
clients 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.

Section 6.8 (if DHCPv6 support is not a MUST)
---------------------------------------------

Insert the following before the M & O bits description:

The M & O bits must be reset if the Home Agent DHCPv6 support is not
provided.  If such support is provided then they are set in concert with
the home network's administrative settings.

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 16:08:23 +0100

Marc,

Thanks for the suggested text. Some mostly
editorial nits below...

> MUST as a question.  Some minor tweaking is needed if MUST is chosen by

I think a SHOULD is fine. On multicast, MLDv1 (rfc2710) is a proposed
standard, but is soon to be obsoleted by MLDv2 (draft-vida-mld-v2-06.txt)
currently under AD evaluation. Some of the text below was done based
on the soon obsolete 2710 MLD specification. Might as well assume MLDv2.

DHCPv6 is sitting in the RFC editor queue.

...

> Section 10.4.2

Ok.

> Section 10.4.2

Ok.

> Section 10.4.2

In order for this not to be construed as an absolute 'MUST'
perhaps we should emphasize that it is conditioned on the MN
having had success in subscribing. This depends on the HA
supporting MLD, itself a SHOULD. So:

s/is subscribed/has successfully subscribed/

> New section 10.4.2+ (following current 10.4.2)

SHOULD seems ok, yes.

> node MLD Reports are silently ignored.

s/Reports/version 1 or 2 Listener Reports/

> to.  These multicast group membership messages are standard MLD [27]

s/MLD[27]/MLD [draft-vida-mld-v2-06.txt] Listener/

> group or in response to an MLD Query from the home agent.  The mobile

s/to join/to enable reception of packets for/

> receiving multicasts for a particular group.

change "MLD Done messages when it is no longer interested in
receiving multicasts"

to: "Report messages to disable reception of
multicast packets"

> interested in despite packet losses of the mobile node's MLD Reports or

change: "groups the mobile node is interested in"
to:  "groups in which the mobile node is interested"

and change: "MLD Reports or MLD Dones."
to: "MLD Report Messages."

> directly to them.  

change: "no one..to them."
to: "no functionality depends on these addresses being unique, nor do
they elicit direct responses."

> All MLD messages are sent to multicast destinations.

s/of the previous/in section 10.4.2/

> router function would be necessary on the home agent but it may be

s/but/, but/

> coupled with kernel multicast forwarding.  This may be the subject of

SHOULD seems fine, yes.

> Section 6.8 (if DHCPv6 support is not a MUST)

ok

-gabriel