Subject: [mobile-ip] Mipv6 issue #161: Mipv6 and DHCP

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Dec 2002 13:33:19 +0200

DHCP and care-of addresses: I think everyone is in
agreement that this is possible and there are no
problems related to this. The document specifically
allows this in Section 11.5.2.

Home addresses are more problematic. In order to use DHCP
for them, the following needs to take place:

1) The mobile node needs to know it has to run DHCP .Currently, we
    can only do this at home; the M and O bits are only available on
    a RA but not in MIPv6 messages.

2) The mobile node needs to be able to send a DHCP query. This
    appears to be possible with tunneling today, though we need
    to worry about details such link-local source addresses.

3) The mobile node and home agent need to be able to use the
    retrieved address as a home address. This is non-trivial in the
    sense that the home agent will need to know that the particular
    home address can be allowed for the given security credentials,
    and both nodes need to update their security associations to
    use the right addresses.

4) Finally, in order to use security for even getting an
    advertisement and making the DHCP request, we currently need a
    home address

The high-level conclusion from this is that we have some support
for DHCP (care-of addresses, retrieving additional parameters beyond
already known home address). But there is no full support for DHCP-based
home addresses, and there even seems to be some hard problems in this
area. On the other hand, it seems that we have some ideas on how to
make the specification architecturally more suited for DHCP addresses,
and pave way for a future specification that provides full DHCP
support. So, my proposal is to have a phased approach with some
changes in the current specification but leaving the full DHCP-for-
home-addresses specification to a future document.

Let's look at the details then:

1) In order to make it possible for the MN to know that they should
    be using DHCP for getting additional information (or addresses),
    the M and O options from the RA should be present in the MPA as
    well. Two new 1 bit fields and a 14 bit Reserved field is needed.

2) Specify how to use DHCP (for additional information, not addresses)
    through a tunnel.

3) Deal with the security problems and full DHCP support in a later
    specification. This will include making the HA aware that a particular
    address has been allocated to the mobile node, and dealing with the
    bootstrap problem (perhaps by using an autoconfigured address first).

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2002 15:45:46 +0200

>    bootstrap problem (perhaps by using an autoconfigured address first).

I have now some text proposals for this issue. The basic approach is
to carry the M/O options in MPAs, and set them based on the values
of the RAs seen on the link. In order to allow DHCP to run over the
tunnel, we specifically allow DHCP (and MLD) to be carried even if they
use link-local addresses. (Are people comfortable with this? I did
add a specific check for the addresses even for the link-local case
in Section 5.)

In Section 6.8, change the MPA format to the following:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Identifier           |M|O|        Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Options ...                                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       M              1-bit "Managed address configuration" flag.  When
                      set, hosts use the administered (stateful) protocol
                      for address autoconfiguration in addition to any
                      addresses autoconfigured using stateless address
                      autoconfiguration.  The use of this flag is
                      described in [2461, 2462].

       O              1-bit "Other stateful configuration" flag. When
                      set, hosts use the administered (stateful) protocol
                      for autoconfiguration of other (non-address)
                      information.  The use of this flag is described in
                      [2461, 2462].

       Reserved       This field is unused. It MUST be initialized to zero
                      by the sender and MUST be ignored by the receiver.

In Section 10.6.3, add the following requirements:

    - Set the Managed address configuration (M) flag if the
      corresponding flag has been set in any of the Router
      Advertisements from which the prefix information has been learned
      (including the ones sent by this home agent).

    - Set the Other stateful configuration (O) flag if the
      corresponding flag has been set in any of the Router
      Advertisements from which the prefix information has been learned
      (including the ones sent by this home agent).

In Section 11.4.3, change the following text:

    For an accepted Mobile Prefix Advertisement, the mobile node MUST
    process the Prefix Information Options as if they arrived in a
    Router Advertisement on the mobile node's home link [12].

=>

    For an accepted Mobile Prefix Advertisement, the mobile node MUST
    process Managed address configuration (M), Other stateful
    configuration (O), and the Prefix Information Options as if they
    arrived in a Router Advertisement on the mobile node's home link
    [12].

In Section 10.4.2, change the following text:

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

=>

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

Add the following text to Section 5.5 where tunnel spoofing issues
are discussed:

    The home agent identifies the mobile node through the source
    address of the inner packet.(Typically, this is the home address of
    the mobile node, but it can also be a link-local address, as
    discussed in Section 10.4.2. To recognize the latter type of
    addresses, the home agent requires that the Link-Local Address
    Compatibility (L) was set in the Binding Update.)