Softwire WG T. Mrugalski, Ed.
Internet-Draft ISC
Intended status: Standards Track M. Boucadair
Expires: May 3, 2012 France Telecom
O. Troan
Cisco
X. Deng
Orange-France Telecom
C. Bao
Tsinghua University
October 31, 2011
DHCPv6 Options for Mapping of Address and Port
draft-mdt-softwire-map-dhcp-option-01
Abstract
Generic mechanism for mapping between an IPv4 prefix, address or
parts of thereof, and transport layer between ports and an IPv6
prefix or address is specified in
[I-D.mdt-softwire-mapping-address-and-port]. This is a companion
document that specifies provisioning mechanism of MAP rules. It
defines DHCPv6 options which are meant to be used between Customer
Edge (CE) devices and DHCPv6 server to obtain necessary parameters to
configure MAP rules. Since specification of MAP architecture is
still expected to evolve, DHCPv6 options may have to evolve too to
fit the revised MAP specification.
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 May 3, 2012.
Copyright Notice
Mrugalski, et al. Expires May 3, 2012 [Page 1]
Internet-Draft MAP DHCPv6 Options October 2011
Copyright (c) 2011 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Provisioning mechanism . . . . . . . . . . . . . . . . . . . . 3
4. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 4
4.1. MAP Options Cardinality . . . . . . . . . . . . . . . . . 5
4.2. MAP Flags Option . . . . . . . . . . . . . . . . . . . . . 5
4.3. MAP Rule Option . . . . . . . . . . . . . . . . . . . . . 6
4.4. Port Parameters Option . . . . . . . . . . . . . . . . . . 8
4.5. MAP Options Example . . . . . . . . . . . . . . . . . . . 9
5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 9
6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Mrugalski, et al. Expires May 3, 2012 [Page 2]
Internet-Draft MAP DHCPv6 Options October 2011
1. Introduction
Mapping of Address and Port (MAP) defined in
[I-D.mdt-softwire-mapping-address-and-port] is a mechanism for
providing IPv4 connectivity service to end users over a service
provider's IPv6 network. It defines both MAP Border Relay (BR)
router that is located at the edge of a MAP domain and MAP Customer
Edge (CE) that typically deployed at customers' location. In a
residential broadband deployment, CE is sometimes referred to as a
Residential Gateway (RG) or Customer Premises Equipment (CPE). A MAP
CE may also be referred to simply as a "CE" within the context of
MAP.
A typical MAP CE adopting MAP rules will serve a residential site
with one WAN side interface, one or more LAN side interfaces. To
operate properly, it requires one or more MAP rules and additional
informations. In larger networks it is infeasible to configure such
parameters manually. Therefore provisioning mechanism is required.
Such mechanism is defined in this document. It leverages existing
DHCPv6 [RFC3315] protocol to deliver necessary parameters to CE.
This document defines several DHCPv6 options that allow delivery of
required information to configure CE. Configuration of the BR is
outside of scope of this document. Definitions of used parameters
are provided in [I-D.mdt-softwire-mapping-address-and-port].
Since specification of MAP architecture is still expected to evolve,
DHCPv6 options may have to evolve too to fit the revised MAP
specification.
Described proposal is not a dynamic port allocation mechanism.
2. Conventions
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].
3. Provisioning mechanism
A typical MAP CE usually acts as a DHCPv6 client and requests options
that are being provided by a DHCPv6 server located somewhere in ISP
network. It would adopt three kinds of parameters independently:
Mrugalski, et al. Expires May 3, 2012 [Page 3]
Internet-Draft MAP DHCPv6 Options October 2011
o MAP mapping rules are defined in Section 4 of
[I-D.mdt-softwire-mapping-address-and-port]. There are several
mapping rule types defined. Depending on rule type, number of
exact parameters may be different. Rule parameters may contain
Rule IPv6 prefix (including prefix length), Rule IPv4 prefix
(including prefix length), EA-bits length (in bits) and additional
values that define Rule Port Parameters. One MAP CE can receive
one or more MAP mapping rules from the DHCPv6 server. One of
those rules must be the default MAP mapping rule for the initiated
CE of its own, followed by other mapping rules within the MAP
domain if necessary. (Discussion: We chose to remove the text
that states that first rule is the default one. DHCPv6 spec
explicitly states that option order is arbitrary and must not
affect the way options are processed. There's also practical
aspect - some implementations keep options in hash tables, so
enforcing any specific order is not feasible. Therefore we need
to add rule type field.
o Transport mode indicates encapsulation or translation mode for MAP
approach. It should be conducted on interface-by-interface basis.
o Discussion: Qiong Sun also proposed to add deployment mode here.
Jacni Qin recommends against it. Deployment mode is to notify
whether CE is in Hub and spoke mode or mesh. In Hub and spoke
mode, only the first default MAP mapping rule is needed in the
following MAP procedure. While in mesh mode, all MAP mapping
rules are included to achieve CE-CE traffic optimization. Tomek:
I believe that hub and spoke or mesh affects number of rules, so
server will provision one (hub and spoke) or many (mesh) rules.
CE does not need to explicitly be information about this. It can
derive this information in a simple manner: if (number of rules>1)
then mode=mesh else mode=hub_and_spoke.
4. DHCPv6 Options Format
DHCPv6 protocol is used for CE provisioning. Several new options are
defined for conveying MAP-specific parameters. Their format and
usage is defined in the following sections.
Discussion: As the exact parameters required to configure MAP rules
and MAP in general are expected to change, this section is expected
to be updated or even rewritten completely.
Discussion: Proposed layout assumes that several simple options are
used. Such approach simplifies implementation as it is much easier
for implementors to reuse existing code handling such options. This
design choice comes at a cost, however. Clients must perform checks
if provided set of options is complete. Alternatively, it would be
possible to define one complex option that contains all mandatory
Mrugalski, et al. Expires May 3, 2012 [Page 4]
Internet-Draft MAP DHCPv6 Options October 2011
parameters.
Discussion: It should be noted that initial concept of 4rd
provisioning was presented in DHC working group meeting. It used one
complex option to convey all required parameters. Strong suggestion
from DHC WG was to use several simpler options. Options (possibly
nested) are preferred over conditional option formatting. See DHCP
option guidelines document [I-D.ietf-dhc-option-guidelines]).
4.1. MAP Options Cardinality
MAP rule is defined in [I-D.mdt-softwire-mapping-address-and-port],
Section 4.
Discussion: If you want additional parameter added to the
OPTION_MAP_RULE option, please update
[I-D.mdt-softwire-mapping-address-and-port] first.
In each REPLY message, server that supports MAP configuration MUST
include exactly one OPTION_MAP_FLAGS option.
MAP_FLAGS option MUST include one or more OPTION_MAP_RULE options.
For proper operation, additional parameters obtained via other
options are necessary. In particular, L parameter is equal to a
length of a prefix delegated to CE, conveyed in OPTION_IA_PD and
IAPREFIX, as defined in [RFC3633]. As there is already defined
mechanism to provision this value, it is not mentioned in MAP
options. Nevertheless, it is required for proper MAP rule
configuration.
4.2. MAP Flags Option
. This option specifies MAP flags. Currently the only defined flag
is T - transport mode. Other flags that affect all mapping rules or
the whole MAP domain may be specified here at a later date.
Each MAP_FLAGS option MUST contain one or more MAP Rule Options.
Mrugalski, et al. Expires May 3, 2012 [Page 5]
Internet-Draft MAP DHCPv6 Options October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MAP_FLAGS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |T|
+-+-+-+-+-+-+-+-+
Figure 1: MAP Flags Option
o option-code: OPTION_MAP_FLAGS (TBD1)
o option-length: 1
o reserved: This 7-bits long reserved field is not used and MUST be
set to 0 by server. Its value MUST be ignored by clients.
o T: 1 bit field that specifies transport mode: translation (0) or
encapsulation (1).
4.3. MAP Rule Option
This option represents a single MAP Rule. Depending on deployment
mode, each CE may require one or more MAP Rules to operate properly.
Server includes one or more MAP Rule Options in MAP Flags option.
Server MAY send more than one MAP Rule Option, if it is configured to
do so. Clients MUST NOT send MAP Rule Option.
Mrugalski, et al. Expires May 3, 2012 [Page 6]
Internet-Draft MAP DHCPv6 Options October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-id | prefix4-len | prefix6-len | ea-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| rule-ipv6-prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. rule sub-options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MAP Rule Option
o option-code: OPTION_MAP_RULE (TBD2)
o option-length: TBD octets + size of sub-options
o rule-id: 8-bits long indentifier that uniquely identifies this
rule.
o rule-ipv6-prefix: a 128-bits field that specifies an IPv6 prefix
that appears in a MAP rule.
o rule-ipv4-prefix: a 32-bits long field that specifies an IPv4
prefix that appears in a MAP rule.
o prefix4-len: length of the IPv6 prefix, specified in the rule-
ipv6-prefix field, expressed in bits.
o prefix6-len: length of the IPv6 prefix, specified in the rule-
ipv6-prefix field, expressed in bits.
o ea-len: 8-bits long field that specifies Embedded-Address (EA)
length, expressed in bits.
o rule sub-options: a variable field that may contains zero or more
options that specify additional parameters for this rule. Those
options follow standard DHCPv6 option format, as defined in
[RFC3315], Section 22.1. Currently there is only one option
defined that may appear in rule sub-options field. This option is
OPTION_MAP_PORTPARAMS, defined in section Section 4.4. Other
options may be defined at a later date.
Each rule is identified with a rule-id. Rule-id MUST be unique
within each CE. Rule ID also defines rule type. Rule-id 0 denotes
default rule. Each CE configuration providioned by DHCPv6 server
Mrugalski, et al. Expires May 3, 2012 [Page 7]
Internet-Draft MAP DHCPv6 Options October 2011
MUST provide exactly one default rule (with rule-id set to 0).
Additional rules MAY be provided as required, but they MUST NOT use
rule-id value of 0. Rules with rule-id smaller than 128 are Basic
Mapping Rules. Rules with rule-id equal or greater than 128 are
Forwarding Mapping Rules.
Note that the default mapping rule is a simplified version of Basic
Mapping Rule. While it reuses the same DHCPv6 option format, Default
Mapping Rule uses only Rule IPv6 prefix, Rule IPv6 Prefix Length and
IPv4 address that denotes BR IPv4 address. All other parameters are
ignored for Default Mapping Rule.
Discussion: Remi Despres pointed out that not all of prefix4len +
prefix6-len + ea-len + excluded ports + off are needed. Only 4 of
these are independent, so one of them will be removed.
4.4. Port Parameters Option
Port Parameters Option specifies Rule Port Paramters. It MAY appear
as sub-option in OPTION_MAP_RULE option. It MUST NOT appear directly
in a message.
See [I-D.mdt-softwire-mapping-address-and-port], Section 4.1 for
detailed description of Port mapping algorithm.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MAP_PORTPARAMS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| excluded-ports |A| rsv | off |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MAP Port Parameters Option
o option-code: OPTION_MAP_PORTPARAMS (TBD3)
o option-length: 3
o excluded-ports: defines upper bound for range of excluded ports.
The lower range is 0. For example, for value 2047, excluded range
is 0-2047 ports. Value of 0 (range 0-0) means that no ports are
excluded.
o A: Specifies if the offset is for a (0) or m (1).
o rsvd: This 4-bits long field is currently not used and MUST be set
to 0 by server. Its value MUST be ingored by clients.
o off: specifies offset bits. Currently defined values are 4 and 6.
Map Port Parameters Option is optional. If it is not present, the
Mrugalski, et al. Expires May 3, 2012 [Page 8]
Internet-Draft MAP DHCPv6 Options October 2011
following default values are to be assumed:
1. Excluded ports: 0-1023 (excluded-ports field value is 1023)
2. A: offset is for a (A field value is 0)
3. Offset bits: 6 (off field value is 6)
If administrator wants to provision only one or two of those
parameters, remaining fields SHOULD be set to their default value.
4.5. MAP Options Example
DHCPv6 server provisioning a single MAP Rule to a CE (DHCPv6 client)
will convey the following MAP options in its messages:
<MAP_FLAGS>
<MAP_RULE1 rule-id="0"/>
<MAP_RULE2 rule-id="1"/>
<MAP_RULE3 rule-id="2"/>
<MAP_PORTPARAMS>
...
<MAP_RULEN/>
</MAP_FLAGS>
Figure 4: MAP Options Example
TODO: Make this a more detailed. This is more of a placeholder, than
a real example.
5. DHCPv6 Server Behavior
RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and
server negotiate configuration values using the ORO. As a
convenience to the reader, we mention here that a server will not
reply with a MAP Rule Option if the client has not explicitly
enumerated it on its Option Request Option.
Server conformant to this specification MUST allow configuration of
one or more MAP Rule Options.
Server MUST transmist all configured instances of the Mapping Rule
Options with all sub-options, if client requested it using
OPTION_MAP_RULE in its Option Request Option (ORO). Server MUST
transmit MAP Flags Option if client requested OPTION_MAP_FLAGS in its
ORO.
Rules assignment is a stateless process from the server's
perspective. Server does not need to maintain a state of rules
provisioned to clients, track lifetimes, expire outdated rules etc.
Mrugalski, et al. Expires May 3, 2012 [Page 9]
Internet-Draft MAP DHCPv6 Options October 2011
Server SHOULDs assign the same set of rules to all CEs in one MAP
Domain, unless there are several classes of CEs defined, e.g. regular
and premium users. In such case, each class of CEs is expected to
get the same set of rules. Server is not expected to track MAP rules
on a per CE basis. Exact assignment of specific rules to a specific
CEs is outside of scope of this document.
6. DHCPv6 Client Behavior
Although other use cases are allowed, in typical use case CE will act
as DHCPv6 client and will request MAP configuration to be assigned by
the DHCPv6 server located in the ISP network. A client that supports
MAP CE functionality and conforms to this specfication MUST include
OPTION_MAP_RULE and OPTION_MAP_FLAGS in its ORO.
For proper operation, MAP CE client MUST also request IPv6 address
(OPTION_IA_NA, defined in [RFC3315]) and prefix delegation
(OPTION_IA_PD, defined in [RFC3633]). MAP CE client SHOULD NOT
initiate DHCPv4 configuration as all parameters are delivered over
DHCPv6.
Client SHOULD request OPTION_MAP_RULE and OPTION_MAP_FLAGS options in
SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.
If client receives more than one OPTION_MAP_RULE option, it MUST use
all received instances. It MUST NOT use only the first one, while
discarding remaining ones.
Note that system implementing MAP CE functionality may have multiple
network interfaces, and these interfaces may be configured
differently; some may be connected to networks that call for MAP, and
some may be connected to networks that are using normal dual stack or
other means. The MAP CE system should approach this specification on
an interface-by-interface basis. For example, if the CE system is
attached to multiple networks that provide the MAP Mapping Rule
Option, then the CE system MUST configure a MAP connection (i.e. a
translation or encapsulation) for each interface separately as each
MAP provides IPv4 connectivity for each distinct interface. Means to
bind a MAP configuration to a given interface in a multiple
interfaces device are out of scope of this document.
7. IANA Considerations
IANA is kindly requested to allocate DHCPv6 option code referencing
this document, delineating OPTION_MAP_RULE and OPTION_MAP_FLAGS.
Mrugalski, et al. Expires May 3, 2012 [Page 10]
Internet-Draft MAP DHCPv6 Options October 2011
8. Security Considerations
Implementation of this document does not present any new security
issues, but as with all DHCPv6-derived configuration state, it is
completely possible that the configuration is being delivered by a
third party (Man In The Middle). As such, there is no basis to trust
that the access over the MAP can be trusted, and it should not
therefore bypass any security mechanisms such as IP firewalls.
Readers concerned with security of MAP provisioning over DHCPv6 are
encouraged to familiarize with [I-D.ietf-dhc-secure-dhcpv6].
Section XX of [I-D.mdt-softwire-mapping-address-and-port] discusses
security issues of the MAP mechanism.
Section 23 of [RFC3315] discusses DHCPv6-related security issues.
Section 6 of [I-D.murakami-softwire-4rd] discusses 4rd related
security issues that are partially applicable to MAP mechanism.
9. IANA Considerations
IANA is requested to allocate DHCPv6 option code TBD1 to the
OPTION_MAP_FLAGS,TBD2 to OPTION_MAP_RULE and TBD3 to
OPTION_MAP_PORTPARAMS. All three values should be added to the
DHCPv6 option code space defined in Section 24.3 of [RFC3315].
10. Contributors
The members of the MAP design team are:
1. Congxiao Bao
2. Mohamed Boucadair
3. Gang Chen
4. Maoke Chen
5. Wojciech Dec
6. Xiaohong Deng
7. Remi Despres
8. Jouni Korhonen
9. Xing Li
10. Satoru Matsushima
11. Tomasz Mrugalski
12. Jacni Qin
13. Qiong Sun
14. Tina Tsou
Mrugalski, et al. Expires May 3, 2012 [Page 11]
Internet-Draft MAP DHCPv6 Options October 2011
15. Ole Troan
16. Dan Wing
17. Leaf Yeh
18. Jan Zorz
11. Acknowledgements
Authors would like to thank Xiaohong Deng, Congxiao Bao, Jacni Qin,
Qiong Sun for their comments and suggestions.
12. References
12.1. Normative References
[I-D.mdt-softwire-mapping-address-and-port]
Troan, O., "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-01 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
12.2. Informative References
[I-D.boucadair-dhcpv6-shared-address-option]
Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
and G. Bajko, "Dynamic Host Configuration Protocol
(DHCPv6) Options for Shared IP Addresses Solutions",
draft-boucadair-dhcpv6-shared-address-option-01 (work in
progress), December 2009.
[I-D.ietf-dhc-option-guidelines]
Hankins, D., "Guidelines for Creating New DHCP Options",
draft-ietf-dhc-option-guidelines-07 (work in progress),
October 2011.
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
Mrugalski, et al. Expires May 3, 2012 [Page 12]
Internet-Draft MAP DHCPv6 Options October 2011
draft-ietf-dhc-secure-dhcpv6-03 (work in progress),
June 2011.
[I-D.mrugalski-dhc-dhcpv6-4rd]
Mrugalski, T., "DHCPv6 Options for IPv4 Residual
Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work
in progress), July 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Tomasz Mrugalski (editor)
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@gmail.com
Ole Troan
Cisco Systems, Inc.
Telemarksvingen 20
Oslo N-0655
Norway
Email: ot@cisco.com
Mrugalski, et al. Expires May 3, 2012 [Page 13]
Internet-Draft MAP DHCPv6 Options October 2011
Xiaohong Deng
Orange-France Telecom
Haidian district
Beijing 100190
China
Email: xiaohong.deng@orange.com
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Mrugalski, et al. Expires May 3, 2012 [Page 14]