Validation of IPv6 Neighbor Discovery Options
draft-gont-6man-nd-opt-validation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Fernando Gont , Ron Bonica , Will (Shucheng) LIU | ||
| Last updated | 2014-08-08 | ||
| Replaced by | draft-ietf-6man-nd-opt-validation | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gont-6man-nd-opt-validation-00
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Updates: 4861 (if approved) R. Bonica
Intended status: Standards Track Juniper Networks
Expires: February 12, 2015 W. Liu
Huawei Technologies
August 11, 2014
Validation of IPv6 Neighbor Discovery Options
draft-gont-6man-nd-opt-validation-00
Abstract
This memo specifies validation rules for IPv6 Neighbor Discovery (ND)
Options. In order to avoid pathological outcomes, IPv6
implementations validate incoming ND options using these rules.
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 February 12, 2015.
Copyright Notice
Copyright (c) 2014 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
Gont, et al. Expires February 12, 2015 [Page 1]
Internet-Draft Validation of ND options August 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Source Link-Layer Address (SLLA) Option . . . . . . . . . 3
4. The Target Link-Layer Address (TLLA) Option . . . . . . . . . 4
5. The Prefix Information Option . . . . . . . . . . . . . . . . 5
6. The Redirected Header Option . . . . . . . . . . . . . . . . 6
7. The MTU Option . . . . . . . . . . . . . . . . . . . . . . . 7
8. The Route Information Option . . . . . . . . . . . . . . . . 8
9. The Recursive DNS Server (RDNSS) Option . . . . . . . . . . . 9
10. The DNS Search List (DNSSL) Option . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
14. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
IPv6 [RFC2460] nodes use Neighbor Discovery (ND) [RFC4861] to
discover their neighbors and to learn their neighbors' link-layer
addresses. IPv6 hosts also use ND to find neighboring routers that
can forward packets on their behalf. Finally, IPv6 nodes use ND to
verify neighbor reachability, and to detect link-layer address
changes.
ND defines the following ICMPv6 [RFC4443] messages:
o Router Solicitation (RS)
o Router Advertisement (RA)
o Neighbor Solicitation (NS)
o Neighbor Advertisement (NA)
o Redirect
ND messages can include options that convey additional information.
Currently, the following ND options are specified:
o Source link-layer address(SLLA) [RFC4861]
o Target link-layer address (TLLA) [RFC4861]
Gont, et al. Expires February 12, 2015 [Page 2]
Internet-Draft Validation of ND options August 2014
o Prefix information [RFC4861]
o Redirected header [RFC4861]
o MTU [RFC4861]
o Route Information [RFC4191]
o Recursive DNS Server (RDNSS) [RFC6106]
o DNS Search List (DNSSL) [RFC6106]
This memo specifies validation rules for the ND options mentioned
above. In order to avoid pathological outcomes, IPv6 implementations
validate incoming ND options using these rules.
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].
3. The Source Link-Layer Address (SLLA) Option
NS, RS, and RA messages MAY contain an SLLA Option. If any other ND
message contains an SLLA Option, the SLLA Option MUST be ignored.
However, the rest of the ND message MAY be processed.
Figure 1 illustrates the SLLA Option:
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 | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Source Link-Layer Address Option
The Type field is set to 1.
The Length field specifies the length of the option (including the
Type and Length fields) in units of 8 octets. The Length field MUST
be valid for the underlying link layer. For example, for IEEE 802
addresses the Length field MUST be 1 [RFC2464]. If an incoming ND
message does not pass this validation check, the entire ND message
MUST be discarded.
Gont, et al. Expires February 12, 2015 [Page 3]
Internet-Draft Validation of ND options August 2014
The Link-Layer Address field specifies the link-layer address of the
packet's originator. It MUST NOT be any of the following:
o a broadcast address
o a multicast address
o an address belonging to the receiving node
If an incoming ND message does not pass this validation check, the
SLLA Option MUST be ignored. However, the rest of the ND message MAY
be processed.
An ND message that carries the SLLA Option MUST have a source address
other than the unspecified address (0:0:0:0:0:0:0:0). If an incoming
ND message does not pass this validation check, the SLLA Option MUST
be ignored. However, the rest of the ND message MAY be processed.
4. The Target Link-Layer Address (TLLA) Option
NA and Redirect messages MAY contain a TLLA Option. If any other ND
message contains an TLLA Option, the TLLA Option MUST be ignored.
However, the rest of the ND message MAY be processed.
Figure 2 illustrates the Target link-layer address:
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 | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Target link-layer address option format
The Type field is set to 2.
The Length field specifies the length of the option (including the
Type and Length fields) in units of 8 octets. The Length field MUST
be valid for the underlying link layer. For example, for IEEE 802
addresses the Length field MUST be 1 [RFC2464]. If an incoming ND
message does not pass this validation check, the entire ND message
MUST be discarded.
An ND message that carries the TLLA option also includes a Target
Address. The TLLA Option Link-Layer Address maps to the Target
Address. The TLLA Option Link-Layer Address MUST NOT be any of the
following:
Gont, et al. Expires February 12, 2015 [Page 4]
Internet-Draft Validation of ND options August 2014
o a broadcast address
o a multicast address
o an address belonging to the receiving node
If an incoming ND message does not pass this validation check, the
TLLA Option MUST be ignored. However, the rest of the ND message MAY
be processed.
5. The Prefix Information Option
The RA message MAY contain a Prefix Information Option. If any other
ND message contains an Prefix Information Option, the Prefix
Information Option MUST be ignored. However, the rest of the ND
message MAY be processed.
Figure 3 illustrates the Prefix Information Option:
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 | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Prefix Information option format
The Type field is set to 3.
The Length field MUST BE set to 4. If an incoming ND message does
not pass this validation check, the entire ND message MUST be
discarded.
Gont, et al. Expires February 12, 2015 [Page 5]
Internet-Draft Validation of ND options August 2014
The Prefix Length is an 8-bit unsigned integer that specifies the
prefix length (i.e., the number of leading bits in the Prefix field
that are significant). Its value MUST be greater than or equal to
32. If an incoming ND message does not pass this validation check,
the Prefix Information Option MUST be ignored. However, the rest of
the ND message MAY be processed.
The Valid Lifetime field is a 32-bit unsigned integer that specifies
the amount of time (in seconds) this prefix can be used for on-link
determination (with a value of 0xffffffff representing 'infinity').
Host SHOULD set the effective Valid Lifetime as follows:
EffectiveVL = max(Valid Lifetime, MIN_VALID_LIFETIME)
Where EffectiveVL is the effective 'Valid Lifetime', and
MIN_VALID_LIFETIME is set to 1800 (seconds).
The value of 1800 seconds for MIN_VALID_LIFETIME has been selected to
coincide with the lower limit enforced on the Router Lifetime
(MIN_ROUTER_LIFETIME).
The Preferred Lifetime is a 32-bit unsigned integer that specifies
the length of time (in seconds) that addresses generated from this
prefix via stateless address auto-configuration (SLAAC) should remain
'preferred' (with a value of 0xffffffff representing 'infinity').
As stated in [RFC4861] the Preferred Lifetime MUST BE less than or
equal to the Valid Lifetime. If an incoming ND message does not pass
this validation check, the Prefix Information Option MUST be ignored.
However, the rest of the ND message MAY be processed.
The Prefix field MUST NOT contain a link-local or multicast prefix.
If an incoming ND message does not pass this validation check, the
Prefix Information Option MUST be ignored. However, the rest of the
ND message MAY be processed.
6. The Redirected Header Option
The Redirect message MAY contain a Redirect Header Option. If any
other ND message contains an Redirect Header Option, the Redirect
Header Option MUST be ignored. However, the rest of the ND message
MAY be processed.
Figure 4 illustrates the Redirected Header option:
Gont, et al. Expires February 12, 2015 [Page 6]
Internet-Draft Validation of ND options August 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Redirected Header Option format
The Type field is 4.
The Length field specifies the option size (including the Type and
Length fields) in units of 8 octets. Its value MUST be greater than
or equal to 6. If an incoming ND message does not pass this
validation check, the entire ND message MUST be discarded.
The value 6 was chosen to accommodate mandatory fields (8 octets)
plus the base IPv6 header (40 octets).
7. The MTU Option
The RA message MAY contain an MTU Option. If any other ND message
contains an MTU Option, the MTU Option MUST be ignored. However, the
rest of the ND message MAY be processed.
Figure 5 illustrates the MTU option:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MTU Option Format
The Type field identifies the kind of option and is set to 5.
The Length field MUST BE set to 1 by the sender. If an incoming ND
message does not pass this validation check, the entire ND message
MUST be discarded.
Gont, et al. Expires February 12, 2015 [Page 7]
Internet-Draft Validation of ND options August 2014
The MTU field is a 32-bit unsigned integer that specifies the MTU
value that should be used for this link. [RFC2460] specifies that
the minimum IPv6 MTU is 1280 octets. Therefore, the MTU MUST be
greater than or equal to 1280. If an incoming ND message does not
pass this validation check, the MTU Option MUST be ignored. However,
the rest of the ND message MAY be processed.
Additionally, the advertised MTU MUST NOT exceed the maximum MTU
specified for the link-type (e.g., [RFC2464] for Ethernet networks).
If an incoming ND message does not pass this validation check, the
MTU Option MUST be ignored. However, the rest of the ND message MAY
be processed.
8. The Route Information Option
The RA message MAY contain a Route Information Option. If any other
ND message contains an Route Information Option, the Route
Information Option MUST be ignored. However, the rest of the ND
message MAY be processed.
Figure 6 illustrates Router Information option:
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 | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Route Information Option Format
The Type field is 24.
The Length field contains the length of the option (including the
Type and Length fields) in units of 8 octets. Its value MUST be at
least 1 and at most 3. If an incoming ND message does not pass this
validation check, the entire ND message MUST be discarded.
The Prefix Length field indicates the number of significant bits in
the Prefix field that are significant. Its value MUST be less than
or equal to 128. If an incoming ND message does not pass this
validation check, the entire ND message MUST be discarded.
Gont, et al. Expires February 12, 2015 [Page 8]
Internet-Draft Validation of ND options August 2014
The Length field and the Prefix Length field are closely related, as
the Length field constrains the possible values of the Prefix Length
field. If the Prefix Length is equal to 0, the Length MUST be equal
to 1. If the Prefix Length is greater than 0 and less than 65, the
Length MUST be equal to 2. If the Prefix Length is greater than 65
and less than 129, the Length MUST be equal to 3. If an incoming ND
message does not pass thes validation checks, the entire ND message
MUST be discarded.
The Prefix field MUST NOT contain a link-local unicast prefix
(fe80::/10) or a link-local multicast prefix (e.g., ff02::0/64). If
an incoming ND message does not pass this validation check, the Route
Information Option MUST be ignored. However, the rest of the ND
message MAY be processed.
9. The Recursive DNS Server (RDNSS) Option
The RA message MAY contain a Recursive DNS Server (RDNSS) Option. If
any other ND message contains an RDNSS Option, the RDNSS Option MUST
be ignored. However, the rest of the ND message MAY be processed.
Figure 7 illustrates the RDNSS options:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Addresses of IPv6 Recursive DNS Servers :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Recursive DNS Server Option Format
The Type field is 25.
The Length field specifies the length of the option (including the
Type and Length fields) in units of 8 octets. Its value MUST be
greater than or equal to 3. Also, its value MUST NOT be divisible by
2. If an incoming ND message does not pass these validation checks,
the entire ND message MUST be discarded.
The Lifetime field specifies the maximum time in seconds that a node
may use the IPv6 addresses included in the option for name
resolution, with a value of 0 indicating that they can no longer be
Gont, et al. Expires February 12, 2015 [Page 9]
Internet-Draft Validation of ND options August 2014
used. If the Lifetime field is not equal to 0, it MUST be at least
1800 (MinRtrAdvInterval) and at most 3600 (2*MaxRtrAdvInterval). If
an incoming ND message does not pass this validation check, the RDNSS
Option MUST be ignored. However, the rest of the ND message MAY be
processed.
The RDNSS address list MUST NOT contain multicast addresses or the
unspecified address. If an incoming ND message does not pass this
validation check, the RDNSS Option MUST be ignored. However, the
rest of the ND message MAY be processed.
10. The DNS Search List (DNSSL) Option
The RA message MAY contain a DNS Search List (DNSSL) Option. If any
other ND message contains an DNSSL Option, the DNSSL Option MUST be
ignored. However, the rest of the ND message MAY be processed.
Figure 8 illustrates the DNSSL option:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Domain Names of DNS Search List :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DNS Search List Option Format
The Type field is 31.
The Length field specifies the length of the option (including the
Type and Length fields) in units of 8 octets. Its value MUST be
greater than or equal to 2. If an incoming ND message does not pass
these validation checks, the entire ND message MUST be discarded.
The Lifetime field specifies the maximum time, in seconds (relative
to the time the packet is sent), over which this DNSSL domain name
may be used for name resolution, with a value of 0 indicating that it
can no longer be used. If the Lifetime field is not equal to 0, it
MUST be at least 1800 (MinRtrAdvInterval) and at most 3600
(2*MaxRtrAdvInterval). If an incoming ND message does not pass this
validation check, the DNSSL Option MUST be ignored. However, the
rest of the ND message MAY be processed.
Gont, et al. Expires February 12, 2015 [Page 10]
Internet-Draft Validation of ND options August 2014
The domain suffixes included in this option MUST be encoded with the
simple encoding specified in Section 3.1 of [RFC1035]. Therefore, if
any of the labels of a domain does not have the first two bits set to
zero, the corresponding DNSSL option MUST be ignored.
11. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
12. Security Considerations
This document specifies sanity checks to be performed on Neighbor
Discovery options. By enforcing the checks specified in this
document, a number of pathological behaviors (including some leading
to Denial of Service scenarios) are eliminated.
13. Acknowledgements
TBD.
14. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Gont, et al. Expires February 12, 2015 [Page 11]
Internet-Draft Validation of ND options August 2014
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Phone: 571 250 5819
Email: rbonica@juniper.net
Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Gont, et al. Expires February 12, 2015 [Page 12]