Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
RFC 4477
| Document | Type | RFC - Informational (May 2006) | |
|---|---|---|---|
| Authors | Christian Strauf , Stig Venaas , Tim Chown | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Margaret Cullen | |
| Send notices to | (None) |
RFC 4477
Network Working Group A. Petrescu
Internet-Draft CEA, LIST
Intended status: Informational D. Liu
Expires: March 21, 2016 September 18, 2015
Problem Statement for the use of IP in some ITS scenarios
draft-petrescu-its-problem-00.txt
Abstract
abstract
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 21, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Petrescu & Liu Expires March 21, 2016 [Page 1]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Discovery sub-Problem . . . . . . . . . . . . . . . . . . . . 4
5. Prefix Exchange sub-Problem . . . . . . . . . . . . . . . . . 4
6. Problem of Prefix Exchange with the First-hop
Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 5
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
intro
2. Terminology
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 RFC 2119 [RFC2119].
term
3. The Problem
The problem is how to establish IP communication paths between the
computers embarked in two or more neighboring vehicles.
Several use-cases in Intelligent Transportation Systems may involve
the TCP/IP suite of protocols and benefit from Internet-style
interactions. Some applications require low-latency data exchanges
between vehicles: Cooperative Adaptive Cruise Control, Platooning.
For these applications, connecting the vehicles through long-range
cellular networks brings too high latency. It is necessary to
connect vehicles directly, by using shorter-range communication
technologies.
A vehicle embarks several IP devices, forming a stable embedded
network. Typically Ethernet cables are run through a car, together
Petrescu & Liu Expires March 21, 2016 [Page 2]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
with the CAN networks. More and more computers in an automobile
perform sensing and control tasks. Typically one embedded Router is
in charge of wireless communications outside the car, potentially via
multiple technologies.
The problem is how to establish IP communication paths between the
computers embarked in two or more neighboring vehicles. An
instantiation of this problem is with the C-ACC use-case: a vehicle
sends its coordinates to the vehicle behind it; this latter vehicle
subsequently acts on braking, under certain circumstances.
Vehicle 1 Vehicle 2
e.g.
o)) LTE D2D ((o
| 802.11p |
| LiFi |
| |
+------+ +----+ +----+ +----------+
|GPS PC| | eR1| | eR2| |Braking PC|
+------+ +----+ +----+ +----------+
| | | |
| | | |
| Ethernet | | Ethernet |
--------------------- ---------------------
2001:db8:1::/40 2001:db8:2::/40
The illustration above depicts two vehicles in close range. Their
respective embedded Routers can exchange data by using a short-range
link-layer wireless technology such as LTE D2D, IEEE 802.11p, and
others.
The egress interfaces of eR1, eR2 and eRn form a single IP subnet.
There is only one IP hop between eR1 and eR2.
Within each vehicle there is at least one subnet, and there are
potentially several distinct IP subnets in each vehicle. In case
there is one subnet in each vehicle, the IP hop count between one IP
device in one vehicle and the IP device in another vehicle is maximum
3: 1 IP hop in each vehicle and 1 IP hop between the vehicles.
As an application example: the "GPS PC" in one vehicle sends IP
datagrams containing its coordinates to the Braking PC in the other
vehicle, controling braking. The IP datagrams are sent through the
respective embedded Routers.
Petrescu & Liu Expires March 21, 2016 [Page 3]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
In order for GPS PC to reach Braking PC it is necessary that the two
embedded Routers have forwarding information about their respective
subnets: eR1 must learn that prefix 2001:db8:2::/40 is reachable
through eR2, and vice-versa. It is thus necessary that they exchange
routing information. Otherwise, the GPS PC and Braking PC can not
reach one another.
The problem is divided in a discovery sub-problem (how eRs discover
each other) and a prefix exchange sub-problem (how eRs exchange
routing information).
4. Discovery sub-Problem
Various information needs to be discovered to set up the IP
communication between the vehicles. The information that needs to be
discovered by the eR includes both link layer, MAC layer and IP layer
information.
For link layer information, the wireless link layer parameters need
to be obtained. For example, power of emmission information which
can be used to determine the distance of the vehicles.
For MAC layer information, the MAC address information of the eR need
to be discovered.
For IP layer information, in the above figure, eR1 needs to discover
the IP address and IP prefix of eR2 and eR2 also needs to discover
the IP address and IP prefix of eR1. The multicast related
information may also need to be discovered.
Service related information sometimes is also needed. For example,
the eR on the vehicle need to indicate that it wants to discover
other eR on other vehicles that can provides V2V communications.
5. Prefix Exchange sub-Problem
As mentioned earlier, there is a problem in establishing single-hop
forwarding between two neighboring vehicles.
There are two modes of operating a V2V topology:
o peer-to-peer operation: one vehicle connects with another vehicle
and exchanges information in a equipotential basis.
o client-server operation: one vehicle connects to another vehicle
which is considered to master several other vehicles. The former
may request an allocation of prefixes, and may use the latter as a
Petrescu & Liu Expires March 21, 2016 [Page 4]
Internet-DraftProblem Statement for IP in C-ACC and PlatooSeptember 2015
's configuration is not important,
unless DNS load balancing is required.
In other cases, inconsistencies may be an issue; for example, where
lists of values are returned, an algorithm is needed for list merger
(e.g., "alternate, DHCPv6 first"). Or there may be incompatible
configuration values where, for example, DHCPv6 supplies domain names
(such the SMTP or POP servers) whereas DHCPv4 provides only IPv4
addresses.
In the case of separate servers, there are some options, like DNS
search path, that aren't used in a specific IP protocol context.
The multiple server approach will have some simplifications. The
DHCPv4 and DHCPv6 servers may provide the same value for a particular
parameter, in which case there is no conflict. In some cases, the
value may be different, but the effect should be the same (such as an
Chown, et al. Informational [Page 7]
RFC 4477 DHCP: Dual-Stack Issues May 2006
NTP server). The crux of the issue is to identify where differences
may occur and where these differences will have an impact on node
behaviour.
One possible solution is to have per-host preferences, or an ordered
list of preferences, for example, "use manually configured", "prefer
DHCPv4", or "prefer DHCPv6", assuming the host can act based upon
which protocol is used. It is then up to the site administrator to
ensure that values returned from either DHCP are consistent (a
principle that extends if other methods are used, such as NIS or
Service Location Protocol (SLP)).
4.2. Single DHCPv6 Server
There is an argument for not having to configure and operate both
DHCP and DHCPv6 servers in a dual-stack site environment. The use of
both servers may also lead to some redundancy in the information
served. Thus, one solution may be to modify DHCPv6 to be able to
return IPv4 information. This solution is hinted at in the DHCPv6
[4] specification: "If there is sufficient interest and demand,
integration can be specified in a document that extends DHCPv6 to
carry IPv4 addresses and configuration information." This solution
may allow DHCP for IPv4 to be completely replaced by DHCPv6 with
additional IPv4 information options, for dual-stack nodes.
A general argument is that which DHCP protocol is used (whether it's
over IPv4 or IPv6) shouldn't affect what kind of addresses you can
get configured with it, and that simplicity and predictability come
from using a single server over a single transport. IPv4-capable
hosts will likely remain for at least 10 years, probably much longer;
do we want dual-stack hosts (which will become the norm) to do both
DHCPv4 and DHCPv6 forever while dual-stack? If you need both servers
to configure interfaces with addresses, and get other configurations,
then you rely on two separate protocols to work (servers and relays,
etc.) in order for the host to behave correctly.
This approach may require the listing of a mix of IPv4 and IPv6
addresses for an option. This could then be considered when new IPv6
options are introduced. There could be just two options needed, one
new option for the address delegation, and one for doing
encapsulation.
Also, there are a number of paradigms in DHCPv6 that we miss in
DHCPv4. An example is movement away from using MAC addresses for
per-host address assignment and instead using DHCP Unique Identifier
(DUIDs) or Identity Association Identifiers (IAIDs). As stated in
Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients
for the selection of configuration parameters and in the association
Chown, et al. Informational [Page 8]
RFC 4477 DHCP: Dual-Stack Issues May 2006
of IAs with clients. DHCPv6 clients use DUIDs to identify a server
in messages where a server needs to be identified. However, in this
particular example, the new DHCPv6 functionality has recently been
retrofitted to IPv4 via a specification for DUIDs for DHCPv4 [6].
However, there are a number of potential problems with this approach:
o IPv4-only nodes would not have any DHCP service available to them;
such an approach is only possible in a fully dual-stack
environment.
o The client node may then be IPv6-only and receive IPv4
configuration settings that it does not want or be able to handle
meaningfully.
o The DHCPv4 servers need to be configured anyway to support IPv4-
only hosts, so there is still duplication of information.
o What happens if there are DHCPv6 servers that don't return IPv4
information? Does this mean the client can't run IPv4 (since it
won't do DHCPv4)?
o If IPv4 information is served from a DHCPv6 server as well as an
IPv4 DHCP server, IPv4 address space will need to be allocated to
both servers, fragmenting the potentially precious IPv4 global
address resource for the site.
4.3. Optimising for Failure with Lists of Addresses
There is a generic issue with any option that includes a list of
addresses of servers (such as DNS server addresses). The list is
offered to cater for resilience, such as whether the listed server
itself fails or connectivity to the server fails. If the client does
not know the cause of failure, its optimal strategy is to try a
different server, via a different protocol. The problem today is
that the IPv4 list is returned via DHCPv4, and the IPv6 list via
DHCPv6; the client really has no way to "try a different server",
since that information is lost by the protocol, even though it may be
known by the server.
Just putting merging heuristics in the client cannot provide the best
behaviour, since information is lost. By comparison, if IPv4-mapped
addresses were included in the DHCPv6 option along with IPv6
addresses, the DHCP server can give an intelligent order that takes
into account which addresses are of the same DNS/whatever server.
IPv6-only clients have to know to discard the IPv4-mapped addresses
in this solution, and it's much easier to solve this in the combined-
DHCP-server case than in the two-server case.
Chown, et al. Informational [Page 9]
RFC 4477 DHCP: Dual-Stack Issues May 2006
One can argue that this is only an optimisation, and in many cases
the list has only two elements, so the "next" choice is forced.
However, this particular issue highlights the subtleties of merging
responses from separate servers.
4.4. Administrative and Other Areas
There are also administrative issues or best practice that could be
promoted. For example, it may be recommended that sites do not split
their DNS name space for IPv6-specific testbeds.
It may be worth considering whether separate manual configuration
files should be kept for IPv4 and IPv6 settings, such as separate
/etc/resolv.conf files for DNS settings on UNIX systems. However,
this seems a complex solution. The problem should be better solved
by other, more generalised methods.
It may be important at times to be able to distinguish DHCP client
and server identities. DHCPv6 introduces the idea of a DHCP Unique
Identifier (DUID). The DUID concept has also been retrofitted to
DHCPv4 [6], and thus it may form the basis of part of the solution
space for the problem at hand.
Some differences in DHCP and DHCPv6 may not be reconciled, but may
not need to be, such as different ways to assign addresses by DUID in
DHCPv6, or the lack of a comparable option in both DHCP versions.
5. Summary
There are a number of issues in the operation of DHCP and DHCPv6
servers for nodes in dual-stack environments that should be
clarified. While some differences in the protocols may not be
reconciled, there may not be a need to do so. However, with DHCPv6
deployment growing, there is an operational requirement to determine
best practice for DHCP server provision in dual-stack environments,
which may or may not imply additional protocol requirements. The
principal choice is whether separate DHCP and DHCPv6 services should
be maintained by a site, or whether DHCPv6 should be extended to
carry IPv4 configuration settings for dual-stack nodes.
It can certainly be argued that until a site is completely dual-
stack, an IPv4 DHCP service will always be required (for example,
while there are still legacy printers, IP webcams, or other devices
that still configure via DHCPv4), and a single IPv6 transport DHCP
server offering configuration information for both protocols will
then not be sufficient. In that case, IPv4 DHCP is required, and
thus there
Chown, et al. Informational [Page 10]
RFC 4477 DHCP: Dual-Stack Issues May 2006
is a good rationale for focusing effort on how to combine the
information received from separate IPv4 DHCP and (stateless) DHCPv6
servers.
In theory, it should be relatively straightforward to write a
configuration manager that would accept a single configuration
specification from the service manager and distribute the correct
(and consistent) configurations to the DHCPv4 and DHCPv6 servers
(whether on the same host or not). In this case, maintaining
coordinated configurations in two servers is an interface issue, not
a protocol issue. The question then is whether the client has all
the information it needs to make reasonable choices. We are aware of
one implementation of separate DHCPv4 and DHCPv6 clients that is
using a preference option for assisting client-side merging of the
received information.
Another issue for discussion is whether a combined DHCP service only
available over IPv6 transport is a desirable longer-term goal for
networks containing only dual-stack or IPv6-only nodes (or IPv4-only
nodes where DHCPv4 is not needed). The transition to the long-term
position may easily take more than 10 years.
Upon reflection on the above observations, the dhc WG reached a
strong consensus to adopt the two-server approach (separate DHCP and
DHCPv6 servers), rather than have a combined single server returning
IPv4 information over IPv6. The two servers may be co-located on a
single node and may have consistent configuration information
generated from a single asset database.
It should be noted that deployment experience of DHCPv6 is still in
its infancy; thus, a full understanding of the issues may only
develop over time, but we feel we have reached the best consensus
given the current status. Future work is now required to determine
best practice for merging information from multiple servers,
including merger of lists of addresses where options carry such
information.
As a footnote, we note that this work has overlap with multihoming
and multi-interface configuration issues. It is also interwoven with
the Detecting Network Attachment area, for example, where a node may
move from an IPv4-only network to a dual-stack network, or vice
versa. Both aspects may be best abstracted for discussion and
progression in the respective IETF multi6, shim6, and dna WGs, in
parallel with the two-server progression in the dhc WG.
Chown, et al. Informational [Page 11]
RFC 4477 DHCP: Dual-Stack Issues May 2006
6. Security Considerations
There are no security considerations in this problem statement per
se, as it does not propose a new protocol.
7. Acknowledgements
The authors thank the following people for input to this document:
Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz,
Changming Liu, Margaret Wasserman, Dave Thaler, Mark Hollinger, and
Greg Daley. The document may not necessarily fully reflect the views
of each of these individuals.
The authors would also like to thank colleagues on the 6NET project
for contributions to this document.
8. Informative References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
[6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006.
Chown, et al. Informational [Page 12]
RFC 4477 DHCP: Dual-Stack Issues May 2006
Authors' Addresses
Tim Chown
University of Southampton
School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Stig Venaas
UNINETT
Trondheim NO 7465
Norway
EMail: venaas@uninett.no
Christian Strauf
Clausthal University of Technology
Erzstr. 51
Clausthal-Zellerfeld D-38678
Germany
EMail: strauf@rz.tu-clausthal.de
Chown, et al. Informational [Page 13]
RFC 4477 DHCP: Dual-Stack Issues May 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chown, et al. Informational [Page 14]