draft-ietf-dhc-mipadvert-opt-01.txt   draft-ietf-dhc-mipadvert-opt-02.txt 
DHC Working Group H. Levkowetz DHC Working Group H. Levkowetz
Internet-Draft ipUnplugged Internet-Draft ipUnplugged
Expires: March 31, 2004 Oct 2003 Expires: August 1, 2004 Feb 2004
DHCP Option for Mobile IP Mobility Agents DHCP Option for Mobile IP Mobility Agents
draft-ietf-dhc-mipadvert-opt <draft-ietf-dhc-mipadvert-opt-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 31, 2004. This Internet-Draft will expire on August 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines a new Dynamic Host Configuration Protocol This document defines a Dynamic Host Configuration Protocol (DHCP)
(DHCP) option with suboptions. One suboption is passed from the DHCP option with sub-options. One sub-option is passed from the DHCP
Server to the DHCP Client to announce the presence of one or more Server to the DHCP Client to announce the presence of one or more
Mobile IP Mobility Agents. For each announced Mobility Agent, Mobile IP Mobility Agents. For each announced Mobility Agent,
information is provided which is the same as that of the Mobile IP information is provided which is the same as that of the Mobile IP
Agent Advertisement extension to ICMP Router Advertisements. There is Agent Advertisement extension to ICMP Router Advertisements. There
also one suboption which may be used by a DHCP client to provide is also one sub-option which may be used by a DHCP client to provide
identity information to the DHCP server. identity information to the DHCP server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2 Mobile IP Terminology . . . . . . . . . . . . . . . . . 3
2.3 DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
3. Mobility Agent Information Option . . . . . . . . . . . . . . 3 3. Mobility Agent Information Option . . . . . . . . . . . . . . 3
3.1 Mobility Agent Information Option Definition . . . . . . 3 3.1 Mobility Agent Information Option Definition . . . . . . 3
3.2 Network Access Identifier Sub-Option . . . . . . . . . . 4 3.2 Network Access Identifier Sub-Option . . . . . . . . . . 5
3.3 Mobility Agent Announcement Sub-Option . . . . . . . . . 4 3.3 Mobility Agent Announcement (Dynamic) Sub-Option . . . . 6
3.4 Mobility Agent Announcement (Static) Sub-Option . . . . 8
4. Mobility Agent Option Usage . . . . . . . . . . . . . . . . . 7 4. Mobility Agent Option Usage . . . . . . . . . . . . . . . . . 9
4.1 DHCP Server - Mobility Agent Interaction . . . . . . . . 9
4.2 Mobile Node Considerations . . . . . . . . . . . . . . . 10
4.3 DHCP Server Considerations . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 9 A. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
1. Introduction 1. Introduction
There already exists a DHCP option to announce Mobile IP Home Agent There already exists a DHCP [RFC2131] option to announce Mobile IP v4
addresses, described in RFC 2132 [2]. There is, however, no option Home Agent addresses, this is described in [RFC2132]. There is,
available to announce Mobile IP Foreign Agents. however, no DHCP option available to announce Mobile IP v4 Foreign
Agents.
Announcement of available Mobile IP Mobility Agents by means of DHCP Announcement of available Mobile IP v4 Mobility Agents by means of
provides possibilities for selective and individual assignment of DHCP provides possibilities for selective and individual assignment
Mobility Agents to Mobile Nodes. This in turn makes load-sharing and of Mobility Agents to Mobile Nodes. This in turn makes load-sharing
selective service offerings easier. This draft describes a DHCP and selective service offerings easier. This draft describes a DHCP
option for announcing Mobility Agents to DHCP Clients. option for announcing IPv4 Mobility Agents to DHCP Clients.
2. Requirements terminology 2. Terminology
2.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [8]. document are to be interpreted as described in [RFC2119].
2.2 Mobile IP Terminology
The Mobile IP related terminology used in this document is described The Mobile IP related terminology used in this document is described
in RFC 3220 [5]. in [RFC3344].
2.3 DHCP Terminology
The DHCP related terminology used in this document is described in
[RFC2131].
3. Mobility Agent Information Option 3. Mobility Agent Information Option
3.1 Mobility Agent Information Option Definition 3.1 Mobility Agent Information Option Definition
This document defines a new DHCP Option called the Mobility Agent This document defines a new DHCP Option called the Mobility Agent
Option. It is a "container" option for specific agent- supplied Option. It is a "container" option for specific agent- supplied
sub-options. The format of the Mobility Agent option is: sub-options. The format of the Mobility Agent option is:
Code Len Mobility Agent Information Field Code Len Mobility Agent Information Field
skipping to change at page 4, line 14 skipping to change at page 5, line 14
SubOpt Len Sub-option Value SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+ +------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN | | 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+ +------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+ +------+------+------+------+------+------+--...-+------+
| 2 | N | t1 | t2 | t3 | t4 | | tN | | 2 | N | t1 | t2 | t3 | t4 | | tN |
+------+------+------+------+------+------+--...-+------+ +------+------+------+------+------+------+--...-+------+
The Mobility Agent Information field shall NOT be terminated with a ...
255 sub-option. The length N of the DHCP Mobility Agent Information
Option shall include all bytes of the sub-option code/length/value The length N of the DHCP Mobility Agent Information Option shall
tuples. Since at least one sub-option must be defined, the minimum include all bytes of the sub-option code/length/value tuples. Since
at least one sub-option must be included in the option, the minimum
Mobility Agent Information length is two (2). The length N of the Mobility Agent Information length is two (2). The length N of the
sub-options shall be the number of octets in only that sub-option's sub-options shall be the number of octets in only that sub-option's
value field. A sub-option length may be zero. The sub-options need value field. A sub-option length may not be zero; if the only
not appear in sub-option code order. purpose of a sub-option is to signal a boolean value, a flag byte
MUST be defined to carry that value. The sub-options need not appear
in any particular order. There is no 255 (End) sub-option defined
for this option, so the Mobility Agent Information field SHALL NOT be
terminated with a 255 sub-option.
3.2 Network Access Identifier Sub-Option 3.2 Network Access Identifier Sub-Option
The Network Access Identifier (NAI) defined in RFC 2486 [3] is The Network Access Identifier (NAI) defined in [RFC2486] is already
already used in Mobile IP as an alternative to the home address as an used in Mobile IP as an alternative to the home address as an
identifier of a mobile node [9]. identifier of a mobile node [RFC2794].
The Network Access Identifier sub-option of the Mobility Agent o The Network Access Identifier sub-option of the Mobility Agent
Information Option MAY be used by the DHCP client to provide Information Option MAY be used by the DHCP client to provide
identifying information to the DHCP server, as part of the identifying information to the DHCP server, as part of the
DHCPDISCOVER message. The server may then use this information in DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages. The server MAY
selecting mobility agent announcement parameters for the client. use this information in selecting mobility agent announcement
parameters for the client.
o If the client requests the server to provide the Mobility Agent
Option by including it in the Parameter Request List Option of a
DHCPDISCOVER, DHCPREQUEST or DHCPINFORM message, the client also
SHOULD include the Mobility Agent Option with the Network Access
Identifier sub-option in the DHCPDISCOVER message.
o The server MAY include the Network Access Identifier sub-option
from the client DHCPDISCOVER message in subsequent DHCPOFFER and
DHCPACK messages if the server used this sub-option in selecting
client parameters.
o The client MUST include the Network Access Identifier sub-option
in a DHCPREQUEST message if it included it in the DHCPDISCOVER
message.
The number of this sub-option is 1.
The format of the Network Access Identifier sub-option is as follows: The format of the Network Access Identifier sub-option is as follows:
SubOpt Len Sub-option Value SubOpt Len Sub-option Value
+------+-----+-----+-----+-----+-----+--...-+-----+ +------+-----+-----+-----+-----+-----+--...-+-----+
| 1 | N | Network Access Identifier | | 1 | N | Network Access Identifier |
+------+-----+-----+-----+-----+-----+--...-+-----+ +------+-----+-----+-----+-----+-----+--...-+-----+
3.3 Mobility Agent Announcement Sub-Option 3.3 Mobility Agent Announcement (Dynamic) Sub-Option
The Mobility Agent Announcement sub-option announces the address of The Mobility Agent Announcement (Dynamic) sub-option announces the
one or more mobility agents, together with all the information about address of one or more mobility agents, together with all the
the mobility agent which is normally found in a Mobile IP Agent information about the mobility agent which is normally found in a
Advertisement extension to ICMP Router Advertisements as described in Mobile IP Agent Advertisement extension to ICMP Router Advertisements
RFC 3220 [5]. as described in [RFC3344].
All fields are defined so as to correspond to fields of the same name All fields are defined so as to correspond to fields of the same name
in a Mobility Agent Advertisement Extension as described in RFC 3220 in a Mobility Agent Advertisement Extension as described in
[5], and if in the future additional bits are allocated from the [RFC3344], and if in the future additional bits are allocated from
'reserved' field for the Mobility Agent Advertisement Extension, they the 'reserved' field for the Mobility Agent Advertisement Extension,
should be equally valid in a DHCP Mobility Agent option. they should be equally valid in a DHCP Mobility Agent option.
However, if RFC 3344 is revised and additional fields are defined for
the Mobility Agent Advertisement Extension, a new sub-option SHOULD
be defined to carry such a new format Mobility Agent Announcement.
This option may contain announcements of one or more Mobility Agents, This option may contain announcements of one Mobility Agents. If it
in sequence. The length of each individual Mobility Agent is desired to announce more than one Mobility Agent, multiple
Announcement is determined from the Adv-Length field of the instances of this sub-option may occur within the Mobility Agent
announcement. Information Option.
The number of this sub-option is 2.
SubOpt Len Sub-option Value (Announcements) SubOpt Len Sub-option Value (Announcements)
+------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... +------+-----+-----+-----+--...-+-----+
| 2 | N | Announcement 1 | Announcement 2 | | 2 | N | Announcement |
+------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... +------+-----+-----+-----+--...-+-----+
The format of one Mobility Agent Announcement is as follows: The format of one Mobility Agent Announcement is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility Agent IP Address | | Mobility Agent IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Adv-Length | Sequence Number | | Type | Adv-Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T| reserved | | Registration Lifetime |R|B|H|F|M|G|r|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more care-of addresses | | zero or more care-of addresses |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option code
DHCP_MIP_OPTION (to be assigned by IANA)
Length
Length in bytes of this option, not including the Option code and
Length bytes.
Agent IP Address Agent IP Address
The address trough which the Mobile Node may reach the announced The address through which the Mobile Node may reach the announced
Mobility Agent in order to do a Mobile IP registration. Mobility Agent in order to do a Mobile IP registration.
Type Type
16. This is the same value as for the type field in a Mobility 16. This is the same value as for the type field in a Mobility
Agent Advertisement Extension as described in RFC 3220 [5]. If Agent Advertisement Extension as described in [RFC3344]. If other
other Mobility Agent Advertisement Extensions are defined in the Mobility Agent Advertisement Extensions are defined in the future,
future, this field will make it possible to differentiate between this field will make it possible to differentiate between them
them without using new DHCP option numbers. without using new DHCP option numbers.
Reserved-0
Sent as zero; required to be zero on reception for the option
described in this document.
Adv-Length Adv-Length
(6 + 4*N), where 6 accounts for the number of bytes in the (6 + 4*N), where 6 accounts for the number of bytes in the
Sequence Number, Registration Lifetime, flags, and reserved Sequence Number, Registration Lifetime, flags, and reserved
fields, and N is the number of care-of addresses advertised for fields, and N is the number of care-of addresses advertised for
the Mobility Agent. the Mobility Agent.
Sequence Number Sequence Number
The count of Mobility Agent DHCP announcements made since the DHCP The count of Mobility Agent DHCP announcements made since the DHCP
server was initialized (RFC 3220, Section 2.3.2 [5]). server was initialised or the Mobility Agent was re-booted,
starting at zero. This is a total count, not a per-client count.
If this count rolls over, it continues with the value 256
following the value 0xffff, to be able to distinguish a roll-over
from a Mobility Agent re-boot, (see Section 2.3.2 of [RFC3344]).
Note that this requires the DHCP server to have knowledge of part
of the state of the Mobility Agent; if the DHCP server does not
have this capability, the sub-option described in Section 3.4
should be used instead of the Mobility Agent Announcement
(Dynamic) sub-option.
Registration Lifetime Registration Lifetime
The longest lifetime (measured in seconds) that this agent is The longest lifetime (measured in seconds) that this agent is
willing to accept in any Registration Request. A value of 0xffff willing to accept in any Registration Request. A value of 0xffff
indicates infinity. indicates infinity.
R R
Registration required. Registration with this foreign agent (or Registration required. Registration with this foreign agent (or
another foreign agent listed in this DHCP option) is required even another foreign agent listed in this DHCP option) is required even
when using a co-located care-of address. when using a co-located care-of address.
B B
Busy. The foreign agent will not accept registrations from Busy. The foreign agent will not accept registrations from
additional mobile nodes. additional mobile nodes.
Note that this requires the DHCP server to have knowledge of part
of the state of the Mobility Agent; if the DHCP server does not
have this capability, the sub-option described in Section 3.4
should be used instead of the Mobility Agent Announcement
(Dynamic) sub-option.
H H
Home agent. This agent offers service as a home agent on the link Home agent. This agent offers service as a home agent with the IP
on which this mobility agent announcement is sent. address given in the announcement.
F F
Foreign agent. This agent offers service as a foreign agent on Foreign agent. This agent offers service as a foreign agent with
the link on which this mobility agent announcement is sent. the IP address given in the announcement.
M M
Minimal encapsulation. This agent implements receiving tunneled Minimal encapsulation. This agent implements receiving tunnelled
datagrams that use minimal encapsulation [7]. datagrams that use minimal encapsulation [RFC2004].
G G
GRE encapsulation. This agent implements receiving tunneled GRE encapsulation. This agent implements receiving tunnelled
datagrams that use GRE encapsulation [6]. datagrams that use GRE encapsulation [RFC1701].
r r
Sent as zero; ignored on reception. SHOULD NOT be allocated for Sent as zero; ignored on reception. SHOULD NOT be allocated for
any other uses. any other uses.
T T
Foreign agent supports reverse tunneling [11]. Foreign agent supports reverse tunnelling [RFC3024].
reserved reserved
Sent as zero; ignored on reception. Sent as zero; ignored on reception.
Care-of Address(es) Care-of Address(es)
The foreign agent care-of address(es) provided by this foreign The foreign agent care-of address(es) provided by this foreign
agent. An DHCP Mobility Agent Announcement MUST include at least agent. An DHCP Mobility Agent Announcement MUST include at least
one care-of address if the 'F' bit is set. The number of care-of one care-of address if the 'F' bit is set. The number of care-of
addresses present is determined by the Length field in the addresses present is determined by the Length field in the
Extension. Extension.
3.4 Mobility Agent Announcement (Static) Sub-Option
In the Mobility Agent Announcement (Dynamic) Sub-Option described
above, the 'B' bit and the 'Sequence Number' field is expected to
faithfully reflect the state of the Mobility Agent announced. This
requires continuous state information update between Mobility Agent
and DHCP Server, which will normally not be available to a
stand-alone DHCP Server.
The Mobility Agent Announcement (Static) Sub-Option is adapted to
this case. In format it is identical to the Mobility Agent
Announcement (Dynamic) Sub-Option, but it always has the 'B' bit and
the 'Sequence Number' field set to zero. Mobile Nodes which receive
this sub-option should be aware of this, and in particular should be
prepared to handle the case where a Mobility Agent is announced by
this DHCP Option and sub-option, but is found to be busy and not able
to handle new registrations when a registration attempt is made.
This sub-option may contain announcements of one Mobility Agent. If
it is desired to announce more than one Mobility Agent, multiple
instances of this sub-option may occur within the Mobility Agent
Information Option.
The number of this sub-option is 3.
SubOpt Len Sub-option Value (Announcements)
+------+-----+-----+-----+--...-+-----+
| 3 | N | Announcement |
+------+-----+-----+-----+--...-+-----+
For both the Static and the Dynamic Mobility Agent Announcement
sub-option the following applies:
o The Mobility Agent Announcement sub-options of the Mobility Agent
Information Option MAY be used by the DHCP server to provide
Mobility Agent information to the DHCP client, as part of a
DHCPOFFER or DHCPACK message. If a Network Access Identifier
sub-option was provided by the client, it SHOULD be used to choose
the particular Mobility Agent or Agents to announce if the server
has more than one Mobility Agent to offer.
o If the server provides the Mobility Agent Option with a Mobility
Agent Announcement sub-option in a DHCPOFFER message, it also MUST
include the same Mobility Agent Option and sub-options in a
subsequent corresponding DHCPACK message.
4. Mobility Agent Option Usage 4. Mobility Agent Option Usage
The requesting and sending of this option follows the rules for DHCP The requesting and sending of this option follows the rules for DHCP
options in RFC 2131 [1] options in [RFC2131].
4.1 DHCP Server - Mobility Agent Interaction
A stand-alone DHCP server providing the Mobility Agent Announcement
Sub-Option will normally not have any knowledge of the state of the
mobility agent which the sub-option refers to. This means that some
of the information in the announcement (such as the 'B' bit in
particular) cannot be dynamically updated. In this case, the
Mobility Agent Announcement (Static) Sub-Option SHOULD be used.
A DHCP server co-located with a Mobility Agent may have more
information about the dynamic state of the Mobility agent, and may
therefore be able to provide reliable state information in the
announcement. In this case, the Mobility Agent Announcement
(Dynamic) Sub-Option MAY be used. Mechanisms to provide state
information transfer between the Mobility Agent and the DHCP server
are not in the scope of this document.
4.2 Mobile Node Considerations
A Mobile IP v4 Mobile Node may request the Mobility Agent Information
option at it's discretion. This may be done before, concurrently
with, or after doing an ICMP Mobility Agent Solicitation according to
[RFC3344], or without doing such an ICMP solicitation at all. It is
however expected that a common usage would be for a mobile node which
connects to a new access node to acquire a DHCP address and solicit
for FAs in parallel. To differentiate between possible services, the
Mobility Agents could be announced solely through DHCP by use of the
Mobility Agent Information Option with one of the Mobility Agent
Announcement sub-options, not by responding to router solicitations;
this way the Mobility Agent and service level offered could be
dependent on the NAI provided by the MN in the Network Access
Identifier sub-option.
When a Mobility Agent is announced by means of an ICMP Mobility Agent
Advertisement according to [RFC3344], the listening Mobile Node is
able to directly acquire the link-layer address of the Mobility Agent
from the advertisement message. If however the Mobility Agent is
advertised through the DHCP Mobility Agent Information Option, the
link-layer address will not be part of the advertisement, and it is
necessary for the Mobile Node to issue an ARP request for the
link-layer address corresponding to the Mobility Agent's IP address.
Further, when a Mobility Agent is announced by means of an ICMP
Mobility Agent Advertisement, the advertisement may also contain
information about the available on-link routers. When the Mobility
Agent announcement is done through the DHCP Mobility Agent
Information Option, the information about available routers SHOULD
instead be provided through the DHCP Router Option.
4.3 DHCP Server Considerations
By providing a NAI to the DHCP server (through use of the Network
Access Identifier Sub-Option), the Mobile Node makes it possible for
the server to match the realm of the NAI to a realm which is known to
the server through static configuration or possibly through a AAA
infrastructure. The exact mechanism used is however out of scope for
this specification.
If the DHCP server does not have the capability to match the realm of
the NAI provided by the Mobile Node against known realms, or if it
finds no matching realm, it MUST fall back to the method of matching
client to configuration parameters described in [RFC2131] (See
especially Section 2.1 of RFC 2131). It is for instance completely
acceptable to select parameter values for the Mobility Agent
Information Option Sub-Options based on the hardware address or
client-identifier of the client.
An alternative to providing the NAI to the DHCP server for use in
selecting Mobility Agent parameters could be to use a mechanism such
as the one described in [RADIUS-SUBOPT] to provide Mobility Agent
information obtained through AAA authentication to the DHCP server
for subsequent delivery to a client using the Mobility Agent
Information Option.
5. Security Considerations 5. Security Considerations
DHCP provides an authentication mechanism, as described in RFC 3118 Mobile IP Agent Advertisements as described in [RFC3344] requires no
[4], which may be used if authentication is required before offering
the Mobility Agent option described here. On the other hand, Mobile
IP Agent Advertisements as described in RFC 3220 [5] requires no
authentication for Agent Advertisement and Agent Solicitation authentication for Agent Advertisement and Agent Solicitation
messages. messages.
DHCP provides an authentication mechanism, as described in [RFC3118],
which may be used if authentication is required before offering the
Mobility Agent option described here. Because it may be cumbersome
or practically impossible to distribute keys to foreign networks a
Mobile Node may visit, the ability to use the DHCP authentication
mechanism is not viewed as a major advantage of distributing Mobility
Agent Announcements through DHCP rather than through regular ICMP
Mobile IP Agent Advertisements.
By providing Agent Advertisements by means of DHCP as an alternative By providing Agent Advertisements by means of DHCP as an alternative
to extended ICMP Router Advertisement messages it is possible to do to extended ICMP Router Advertisement messages it is possible to do
so more selectively, and it does not offer any new threat to the so more selectively, and it does not offer any new threat to the
internet. internet.
6. IANA Considerations 6. IANA Considerations
This document defines one new DHCP v4 option value, and one new
sub-type numbering space to be managed by IANA.
Section 3.1 defines a new DHCP v4 option value, the Mobility Agent
Information Option. The type number for this option is [TBD,
assigned by IANA]. This option introduces a new sub-type numbering
space where the values 1, 2 and 3 has been assigned values in this
document. Approval of new Mobility Agent Information Option sub-type
numbers is subject to Expert Review, and a specification is required
[RFC2434].
The value for the DHCP_MIP_OPTION code must be assigned from the The value for the DHCP_MIP_OPTION code must be assigned from the
numbering space defined for public DHCP Options in RFC 2939 [10]. numbering space defined for public DHCP Options in [RFC2939].
7. Acknowledgements 7. Acknowledgements
Normative References Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2486, January 1999. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 3118, June 2001. RFC 2486, January 1999.
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
2002. Messages", RFC 3118, June 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Informative References Informative References
[6] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Calhoun, P. and C. Perkins, "Mobile IP Network Access [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000. Identifier Extension for IPv4", RFC 2794, March 2000.
[10] Droms, R., "Procedures and IANA Guidelines for Definition of [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
New DHCP Options and Message Types", BCP 43, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000. September 2000.
[11] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
3024, January 2001. revised", RFC 3024, January 2001.
[RADIUS-SUBOPT]
Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option
for the DHCP Relay Agent Information Option",
draft-ietf-dhc-agentopt-radius-03 (work in progress),
November 2003.
Author's Address Author's Address
Henrik Levkowetz Henrik Levkowetz
ipUnplugged AB ipUnplugged AB
Arenavagen 33 Arenavagen 33
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
Phone: +46 8 725 9513 Phone: +46 8 725 9513
EMail: henrik@levkowetz.com EMail: henrik@levkowetz.com
Appendix A. Open issues
(This section should be removed by the RFC editor before publication)
Discussion about this draft should be sent to dhcwg@ietf.org.
Open issues relating to this specification are tracked on the
following web site: http://www.mip4.org/issues/tracker/mip4/
The current working documents for this draft are available at this
web site: http://ietf.levkowetz.com/drafts/dhc/mipadvert/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 9, line 29 skipping to change at page 14, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/