One document matched: draft-bhandari-netext-pmipv6-dhcp-options-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2132 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY RFC5844 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5844.xml">
<!ENTITY RFC4649 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml">
<!ENTITY RFC3046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml">
<!ENTITY RFC6225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6255.xml">
<!ENTITY RFC2939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3118 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY DHCPv6-IANA-Registry SYSTEM "http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml">
<!ENTITY DHCPv4-IANA-Registry SYSTEM "http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml#options">
<!ENTITY I-D.draft-ietf-netext-access-network-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netext-access-network-option-08.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-bhandari-netext-pmipv6-dhcp-options-00"
ipr="trust200902">
<front>
<title abbrev="DHCPv4 host configuration via PMIPv6">DHCPv4 Configuration
Options in PMIPv6</title>
<author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Sarjapura Marathalli Outer Ring
Road</street>
<city>Bangalore</city>
<region>KARNATAKA</region>
<code>560 087</code>
<country>India</country>
</postal>
<phone>+91 80 4426 0474</phone>
<email>shwethab@cisco.com</email>
</address>
</author>
<author fullname="Sanjay Kumar" initials="S." surname="Kumar">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Sarjapura Marathalli Outer Ring
Road</street>
<city>Bangalore</city>
<region>KARNATAKA</region>
<code>560 087</code>
<country>India</country>
</postal>
<phone>+91 80 4426 0274</phone>
<email>sakumar3@cisco.com</email>
</address>
</author>
<date day="8" month="July" year="2012" />
<abstract>
<t>This document specifies methods to learn DHCP host configuration
options by DHCPv4 server co-located at Mobile Access Gateway(MAG) as
directed by Local Mobility Anchor(LMA) via Proxy Mobile IPv6(PMIPv6)
signalling.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Proxy Mobile IPv6 protocol is extended to support IPv4 to enable IPv4
home address mobility support to the mobile node as detailed in <xref
target="RFC5844"></xref>. Dynamic Host Configuration Protocol v4
(DHCPv4) based address configuration support for a mobile node in a
Proxy Mobile IPv6 domain is detailed in Section 3.4 of <xref
target="RFC5844"></xref> where the Mobile Access Gateway(MAG) can
support co-location of DHCPv4 Server or DHCPv4 Relay agent as directed
by Local Mobility Anchor(LMA) in IPv4 DHCP Support Mode Option.</t>
<t>When DHCPv4 Relay agent is co-located with MAG, DHCPv4 Server in the
proxy mobile IPv6 domain can be configured to influence and respond to
the mobile node with all the DHCPv4 configuration options. However when
DHCPv4 Server is co-located with MAG in a Proxy Mobile IPv6 domain it
has to be statically configured with all the DHCPv4 option values (e.g.,
DNS Server, SIP Server, etc. that have no corresponding Mobility Header
options defined) that correspond to IPv4 Home Address assignment for all
its DHCPv4 clients. Due to static configuration required at the MAG this
works well when the number of MAGs are few and when the same
configuration options are to be applied to all the mobile nodes attached
to the MAG. Currently there is no well defined scheme to influence
DHCPv4 Server co-located at MAG with the DHCPv4 options values to be
offered to the DHCPv4 clients (Mobile Nodes) dynamically via PMIPv6
signalling.</t>
<t>This document specifies mechanism for DHCPv4 server co-located at the
MAG to learn DHCPv4 options that can be offered to the mobile nodes that
it serves via PMIPv6 signalling.</t>
</section>
<section title="Motivation">
<t>Proxy mobile IPv6 <xref target="RFC5213"></xref> can be used for
supporting network-based mobility management in various types of network
deployments. IPv4 address assigment extension to PMIPv6 is added by
<xref target="RFC5844"></xref> that adds new Mobility Header options to
influence IPv4 address assignment. Specifically <xref
target="RFC5844"></xref> adds support to influence:</t>
<t><list style="numbers">
<t>IPv4 address configuration offered to the client - Mobility
Header Option Type 37 that can be used to fill 'yiaddr' field of
DHCPv4 message as specifed in <xref target="RFC2131"></xref> and
Subnet Mask Option as specified in <xref
target="RFC2132"></xref></t>
<t>IPv4 Default-Router Address Option - Mobility Header Option Type
38 that can be used to fill DHCPv4 Router Option as specifed in
<xref target="RFC2132"></xref></t>
</list> In addition to the above an IPv4 device requires more
configuration to communicate with other nodes in the network. For
example if LMA is influencing the IPv4 address configuration it may also
have to influence configuration corresponding to the address such as DNS
server's IP address, Domain name for the mobile node etc. It demands
operational overhead to statically configure DHCPv4 server co-located at
each MAG with all this configuration options.</t>
</section>
<section title="Terminology">
<t>All the DHCP related terms used in this document to be interpreted as
defined in the Dynamic Host Configuration Protocol v4 (DHCPv4) <xref
target="RFC2131"></xref> specification.</t>
<t>All the mobility related terms used in this document are to be
interpreted as defined in the Proxy Mobile IPv6 specifications <xref
target="RFC5213"></xref> and <xref target="RFC5844"></xref>.</t>
</section>
<section title="Mechanisms to learn DHCPv4 options by DHCPv4 Server co-located at MAG">
<t>DHCPv4 options can be learnt by a DHCPv4 Server co-located at the MAG
using any of the following mechanisms:</t>
<t><list style="numbers">
<t>LMA signaling MAG in Protocol Binding Acknowlegment(PBA) to
trigger DHCPINFORM request message to obtain configuration options
as specified in <xref target="RFC2131"></xref>. </t>
<t>MAG to voluntarily send DHCPINFORM message when it discovers the
LMA, to dynamically learn DHCPv4 configuration options. These
options will be applied to all or group of mobile nodes that will
attach to the MAG and are anchored at the specific LMA, when the
mobile nodes trigger DHCPv4 discover.</t>
<t>New Mobility Header option, to encapsulate DHCPv4 option within
it, that is included in PBA message from LMA to MAG - DHCPv4 server
co-located at MAG can process this DHCPv4 option after decapsulation
and include the learnt DHCPv4 options in the DHCPv4 response
messages towards the client.</t>
</list>The following sections will describe each of the above
approaches.</t>
<section title="LMA signalling MAG to send DHCPINFOR">
<t>In this approach LMA can influence the DHCPv4 Server co-located at
the MAG to trigger DHCPINFORM on a per MN basis to influence DHCPv4
options sent to the MN. <xref target="approach1overview"></xref>
provides high level message exchange between MN, DHCP server at MAG,
MAG and LMA.</t>
<t><figure anchor="approach1overview"
title="Overview of per MN DHCPINFORM exchange between DHCP Server co-located at MAG and LMA">
<preamble></preamble>
<artwork><![CDATA[ MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement
| | | (IPv4 HoA, Support Mode set
| | | to indicate server mode and
| | | availability of additional
| | | DHCPv4 options)
| |========| 4. Tunnel/Route Setup
| |------->| 5. DHCPINFORM
| |<-------| 6. DHCPACK (All the options
| | | applicable to the MN)
|<------| | 7. DHCPOFFER (IPv4 HoA, Options)
|------>| | 8. DHCPREQUEST (IPv4 HoA, Options)
|<------| | 9. DHCPACK
| | |
]]></artwork>
<postamble></postamble>
</figure></t>
<t>To acheive this IPv4 DHCP Support Mode Option defined in Section
3.3.4 of <xref target="RFC5844"></xref> will be extended to carry
additional flag that can be interpreted by MAG to trigger
DHCPINFORM.</t>
<t><figure title="IPv4 DHCP Support Mode Option">
<artwork><![CDATA[ 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(39) | Length(2) | Reserved (R) |M|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type, Length and DHCP Support Mode (S) are as defined in Section 3.3.4
of RFC5844.
Addition 1-bit from the Reserved flags is used to define the following
flag:
DHCP More configs available (M)
A 1-bit field that when set indicates more DHCP
options are available.
This flag when set to (1) indicates to MAG that DHCPINFORM
message has to be triggered to learn more DHCPv4 options.
This flag MUST be set to (0) when the DHCP Support Mode
indicates DHCP Relay.
]]></artwork>
</figure></t>
<t>The DHCPINFORM message triggered by MAG MUST have'ciaddr' field set
to IPv4 home address of the MN learnt in PBA and 'giaddr' field set to
MAGs IPv4 address reachable to LMA. The response DHCPACK is received
by MAG to learn and cache the DHCP options that will then be sent to
the MN in DHCP reply messages.</t>
<t>This approach provides per MN configuration granularity to LMA.
This results in overhead of DHCPINFORM-DHCPACK message exchange for
every MN that need to be influenced with DHCP options available. </t>
</section>
<section title="MAG voluntarily sending DHCPINFORM">
<t>When MAG discovers LMA in a Proxy Mobile IPv6 domain, it can
voluntarily trigger one ore more DHCPINFORM message with 'ciaddr'
field set to IPv4 address of each of its interface in that Proxy
Mobile IPv6 domain. LMA MAY respond with DHCPACK message with the
options applicable to all the MNs that will attach to the MAG
indicated by 'ciaddr'. LMA will respond with DHCPACK only if it is
configured to support MAG to act as DHCP server and has additional
options available. Otherwise LMA will silently discard the received
DHCPINFORM.</t>
<t>MAG will cache the DHCP options received in response to the
DHCPINFORM. DHCPv4 server co-located at MAG will send these cached
options towards the MN when it receives DHCP request messages. <xref
target="approach2overview"></xref> provides message exchange overview
for this approach.</t>
<figure anchor="approach2overview"
title="Overview of DHCPINFORM exchange between MAG and LMA">
<preamble></preamble>
<artwork><![CDATA[ MN MAG(DHCP-S) LMA
| |------->| 1. DHCPINFORM
| |<-------| 2. DHCPACK
| | | (Learn and cache options
. . . for future use)
. . .
|------>| | 3. DHCPDISCOVER
| |------->| 4. Proxy Binding Update
| |<-------| 5. Proxy Binding Acknowledgement
| | | (IPv4 HoA, Support Mode set
| | | to indicate server mode)
| |========| 4. Tunnel/Route Setup
|<------| | 7. DHCPOFFER (IPv4 HoA,
| | | other options learnt in Step 2)
|------>| | 8. DHCPREQUEST (IPv4 HoA)
|<------| | 9. DHCPACK
| | |
]]></artwork>
<postamble></postamble>
</figure>
<t>Periodicity of MAG sending such DHCPINFORM messages to refresh the
cached data will be driven by configuration at MAG. </t>
<t>This approach is optimal when LMA wants to provide the same DHCP
host configuration options for a large set of MNs attaching to MAG.
</t>
</section>
<section title=" Mobile Header Option to encapsulate DHCPv4 Option">
<t>A new option, the DHCP Encapsulation option, is defined for use in
the Proxy Binding Acknowledgement message sent by the local mobility
anchor(LMA) to the mobile access gateway (MAG). This option will
encapsulate the complete DHCPv4 option including code, length and
value. This option MAY be included only when IPv4 DHCP Support Mode
option indicates DHCPv4 Server support at MAG. It MUST NOT be included
when MAG acts as a DHCPv4 Relay. Zero or more instances of this option
can be included in PBA message to send different DHCP Options. DHCPv4
server co-located at MAG can decapsulate the DHCP Option within this
option and send it in DHCP response messages to MNs, adhering to DHCP
protocol specification.</t>
<t><figure title="DHCP Encapsulation Option">
<artwork><![CDATA[ 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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ DHCP Option +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD>
Length
8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields.
Reserved
This field is unused for now. The value MUST be initialized to
0 by the sender and MUST be ignored by the receiver.
DHCP Option
A variable length field containing the DHCP option including code,
length and value.
]]></artwork>
</figure></t>
<t>This approach is useful when the number of DHCP options that are to
be influenced by LMA is small in comparison to the overhead of
exchanging DHCPINFORM message described in Section 4.1 to retrive
these options. For e.g. if only DNS Server address option has to be
influenced then it can be encapsulated in this option instead of
forcing a DHCPINFORM to retrieve it or defining a new Mobility Header
Option equivalent to each of the DHCP Option to be influenced.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines a new Mobility Header options, the DHCP
Encapsulation Option described in Section 4.3. The Type value for this
option should be assigned from the same numbering space as allocated for
the other mobility options, as defined in <xref
target="RFC3775"></xref>.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> All the security considerations from <xref target="RFC5844"></xref>
apply to this specification. </t>
<t>In addition security consideration for exchanging DHCP messages
between MAG and LMA (DHCPINFORM) message as outlined in <xref
target="RFC2131"></xref> also apply. Link-layer confidentiality and
integrity protection may be employed to reduce the risk of disclosure
and tampering of DHCP messages between LMA, MAG and MN.</t>
<t>This document defines new mobility option for supporting dhcp
configuration options encapsulation. These options are to be carried in
Proxy Binding Acknowledgement messages. The required security mechanisms
specified in the base Proxy Mobile IPv6 protocol for protecting these
signaling messages are sufficient when carrying these mobility options.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC2131;
&RFC2132;
&RFC5213;
&RFC5844;
&RFC3775;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:59:10 |