Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7084.
|
|
|---|---|---|---|
| Authors | Hemant Singh , Wes Beebee , Chris Donley , Barbara Stark , Ole Trøan | ||
| Last updated | 2012-03-08 | ||
| Replaces | draft-ietf-v6ops-ipv6-cpe-router-bis | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Telechat review
(of
-09)
by Meral Shirazipour
Almost ready
GENART Last Call review
by Meral Shirazipour
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7084 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-v6ops-6204bis-07
Network Working Group H. Singh
Internet-Draft W. Beebee
Obsoletes: 6204 (if approved) Cisco Systems, Inc.
Intended status: Informational C. Donley
Expires: September 9, 2012 CableLabs
B. Stark
AT&T
O. Troan, Ed.
Cisco Systems, Inc.
March 8, 2012
Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-07
Abstract
This document specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it. The document also covers IP transition
technologies. Two transition technologies in RFC 5969's 6rd and RFC
6333's DS-Lite. are covered in the document. The document obsoletes
RFC 6204, if approved.
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 September 9, 2012.
Copyright Notice
Copyright (c) 2012 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
Singh, et al. Expires September 9, 2012 [Page 1]
Internet-Draft IPv6 CE Router Requirements March 2012
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4
3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5
3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7
4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7
4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11
4.4. Transition Technologies Support . . . . . . . . . . . . . 13
4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14
4.5. Security Considerations . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Singh, et al. Expires September 9, 2012 [Page 2]
Internet-Draft IPv6 CE Router Requirements March 2012
1. Introduction
This document defines basic IPv6 features for a residential or small-
office router, referred to as an IPv6 CE router. Typically, these
routers also support IPv4.
Mixed environments of dual-stack hosts and IPv6-only hosts (behind
the CE router) can be more complex if the IPv6-only devices are using
a translator to access IPv4 servers [RFC6144]. Support for such
mixed environments is not in scope of this document.
This document specifies how an IPv6 CE router automatically
provisions its WAN interface, acquires address space for provisioning
of its LAN interfaces, and fetches other configuration information
from the service provider network. Automatic provisioning of more
complex topology than a single router with multiple LAN interfaces is
out of scope for this document.
See [RFC4779] for a discussion of options available for deploying
IPv6 in service provider access networks.
The document also covers IP transition technologies. Two transition
technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
the document. At the time of writing this document these were the
only two transition technologies available in RFC form to be included
in this document.
1.1. Requirements Language
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].
2. Terminology
End-User Network one or more links attached to the IPv6 CE
router that connect IPv6 hosts.
IPv6 Customer Edge Router a node intended for home or small-office
use that forwards IPv6 packets not
explicitly addressed to itself. The IPv6
CE router connects the end-user network to
a service provider network.
Singh, et al. Expires September 9, 2012 [Page 3]
Internet-Draft IPv6 CE Router Requirements March 2012
IPv6 Host any device implementing an IPv6 stack
receiving IPv6 connectivity through the
IPv6 CE router.
LAN Interface an IPv6 CE router's attachment to a link in
the end-user network. Examples are
Ethernet (simple or bridged), 802.11
wireless, or other LAN technologies. An
IPv6 CE router may have one or more
network-layer LAN interfaces.
Service Provider an entity that provides access to the
Internet. In this document, a service
provider specifically offers Internet
access using IPv6, and may also offer IPv4
Internet access. The service provider can
provide such access over a variety of
different transport methods such as DSL,
cable, wireless, and others.
WAN Interface an IPv6 CE router's attachment to a link
used to provide connectivity to the service
provider network; example link technologies
include Ethernets (simple or bridged), PPP
links, Frame Relay, or ATM networks, as
well as Internet-layer (or higher-layer)
"tunnels", such as tunnels over IPv4 or
IPv6 itself.
3. Architecture
3.1. Current IPv4 End-User Network Architecture
An end-user network will likely support both IPv4 and IPv6. It is
not expected that an end-user will change their existing network
topology with the introduction of IPv6. There are some differences
in how IPv6 works and is provisioned; these differences have
implications for the network architecture. A typical IPv4 end-user
network consists of a "plug and play" router with NAT functionality
and a single link behind it, connected to the service provider
network.
A typical IPv4 NAT deployment by default blocks all incoming
connections. Opening of ports is typically allowed using a Universal
Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some
other firewall control protocol.
Singh, et al. Expires September 9, 2012 [Page 4]
Internet-Draft IPv6 CE Router Requirements March 2012
quot;This MIB Object contains the decibel level for each
analog signal (tone) that is locally generated
(versus in band supervisory tones) and sourced to
the a-b terminals (TE connection point). Each tone
in itself may consist of multiple frequencies as
defined by the MIB table pktcSigDevMultiFreqToneTable.
This MIB Object reflects the desired level at
the Telco (POTS) a-b (T/R) terminals including the
affect of any MTA receiver gain (loss). This is required
so that locally generated tones are consistent with
remotely generated in band tones at the a-b terminals,
consistent with user expectations.
This MIB Object must be set for each tone.
When tones are formed by combining multi-frequencies,
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 41]
PacketCable/IPCablecom NCS Signaling MIB August 2007
the level of each frequency shall be set so as to result
in the tone level specified in this object at the a-b
(T/R) terminals.
The wide range of levels for this Object is required
to provide signal generator levels across the wide
range of gains (loss) - but does not imply the entire
range is to be achievable given the range of gains (loss)
in the MTA."
DEFVAL { -120 }
::={ pktcSigDevMultiFreqToneEntry 8}
pktcSigDevToneFreqOnDuration OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This MIB Object represents the duration for which the
frequency reference corresponding to the tone type
is turned on."
::={ pktcSigDevMultiFreqToneEntry 9}
pktcSigDevToneFreqOffDuration OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This MIB Object represents the duration for which the
frequency reference corresponding to the tone type
is turned off."
::={ pktcSigDevMultiFreqToneEntry 10}
pktcSigDevToneFreqRepeatCount OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This MIB Object indicates the number of times
to repeat the cadence cycle represented by the
on/off durations (refer to the MIB Objects
pktcSigDevToneFreqOnDuration and
pktcSigDevToneFreqOffDuration).
Setting this object may result in a tone duration
longer or shorter than the overall signal duration
specified by the time out (TO) object for the
corresponding tone type. If the value of this MIB
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 42]
PacketCable/IPCablecom NCS Signaling MIB August 2007
Object indicates a longer duration than the
specified by the TO, the latter overrules the former
and the desired tone duration will be truncated according
to the TO.
However, if the repeat count results in a shorter
tone duration than the signal duration specified by
the TO, the tone duration defined by the repeat count
takes precedence over the TO and will end the signal
event. In this case, the TO represents a time not to
be exceeded for the signal. It is recommended to
ensure proper telephony signaling that the TO
duration setting should always be longer than the
desired repeat count time duration. A value of zero
means the tone sequence is to be played once but not
repeated."
::={ pktcSigDevMultiFreqToneEntry 11}
pktcSigDevCidDelayAfterLR OBJECT-TYPE
SYNTAX Unsigned32 (300..800)
UNITS "Milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the delay between the end of the
Line Reversal and the start of the FSK or DTMF signal.
This MIB object is used only when pktcSigDevCidMode is
set to a value of 'lrETS'. This timing has a range of
300 to 800 ms.
The following table defines the default values
for this MIB Object, depending on the signal type
(pktcSigDevCidMode) and MUST be followed:
Value of pktcSigDevCidMode Default value
duringringingETS any value (not used)
dtAsETS any value (not used)
rpAsETS any value (not used)
lrAsETS any value (not used)
lrETS 400
An attempt to set this object while the value of
pktcSigDevCidMode is not set to a value of 'lrETS' will
result in an 'inconsistentValue' error.
The value of this MIB Object MUST NOT persist across MTA
reboots."
DEFVAL { 400 }
::= {pktcSigDevObjects 34 }
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 43]
PacketCable/IPCablecom NCS Signaling MIB August 2007
pktcSigDevCidDtmfStartCode OBJECT-TYPE
SYNTAX DtmfCode
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies optional start codes used when
the MIB object pktcSigDevCidSigProtocol is set
to a value of 'dtmf(2)'.
Different countries define different caller id signaling
codes to support caller identification. When Dual tone
multi-frequency (DTMF) is used the Caller ID digits are
preceded by a 'start code' digit, followed by the digit
transmission sequence <S1>...<Sn> (where Sx represents
the digits 0-9) and terminated by the 'end code' digit.
For e.g.
<A><S1>...<Sn> <D><S1>...<Sn> <B><S1>...<Sn> <C>.
The start code for calling number delivery may be DTMF
'A' or 'D'. The start code for redirecting number may be
DTMF 'D'. The DTMF code 'B' may be sent by the network
as start code for the transfer of information values,
through which special events can be indicated to the
user. In some countries the '*' or '#' may be used
instead of 'A', 'B', 'C' or 'D'.
The value of this MIB Object MUST NOT persist across MTA
reboots."
REFERENCE
"ETSI-EN-300-659-1 specification"
DEFVAL {dtmfcodeA}
::= { pktcSigDevObjects 35 }
pktcSigDevCidDtmfEndCode OBJECT-TYPE
SYNTAX DtmfCode
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies optional end codes used when the
pktcSigDevCidSigProtocol is set to a value of
'dtmf(2)'.
Different countries define different caller id signaling
protocols to support caller identification. When Dual
tone multi-frequency (DTMF) is used the Caller ID digits
are preceded by a 'start code' digit, followed by the
digit transmission sequence <S1>...<Sn> (where Sx
represents the digits 0-9) and terminated by the 'end
code' digit.
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 44]
PacketCable/IPCablecom NCS Signaling MIB August 2007
For e.g.
<A><S1>...<Sn> <D><S1>...<Sn> <B><S1>...<Sn> <C>.
The DTMF code 'C&Another consequence of using private address space in the end-user
network is that it provides stable addressing; i.e., it never changes
even when you change service providers, and the addresses are always
there even when the WAN interface is down or the customer edge router
has not yet been provisioned.
Rewriting addresses on the edge of the network also allows for some
rudimentary multihoming, even though using NATs for multihoming does
not preserve connections during a fail-over event [RFC4864].
Many existing routers support dynamic routing, and advanced end-users
can build arbitrary, complex networks using manual configuration of
address prefixes combined with a dynamic routing protocol.
3.2. IPv6 End-User Network Architecture
The end-user network architecture for IPv6 should provide equivalent
or better capabilities and functionality than the current IPv4
architecture.
The end-user network is a stub network. Figure 1 illustrates the
model topology for the end-user network.
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+---+-------+-+-+ /
Network A | | Network B | End-User
---+-------------+----+- --+--+-------------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
Figure 1: An Example of a Typical End-User Network
This architecture describes the:
Singh, et al. Expires September 9, 2012 [Page 5]
Internet-Draft IPv6 CE Router Requirements March 2012
o Basic capabilities of an IPv6 CE router
o Provisioning of the WAN interface connecting to the service
provider
o Provisioning of the LAN interfaces
For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast
Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic
multicast routing protocol.
The IPv6 CE router may be manually configured in an arbitrary
topology with a dynamic routing protocol. Automatic provisioning and
configuration are described for a single IPv6 CE router only.
3.2.1. Local Communication
Link-local IPv6 addresses are used by hosts communicating on a single
link. Unique Local IPv6 Unicast Addresses (ULA's) [RFC4193] are used
by hosts communicating within the end-user network across multiple
links, but without requiring the application to use a globally
routable address. The IPv6 CE router defaults to acting as the
demarcation point between two networks by providing a ULA boundary, a
multicast zone boundary, and ingress and egress traffic filters.
At the time of this writing, several host implementations do not
handle the case where they have an IPv6 address configured and no
IPv6 connectivity, either because the address itself has a limited
topological reachability (e.g., ULA) or because the IPv6 CE router is
not connected to the IPv6 network on its WAN interface. To support
host implementations that do not handle multihoming in a multi-prefix
environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
as detailed in the requirements below, advertise itself as a default
router on the LAN interface(s) when it does not have IPv6
connectivity on the WAN interface or when it is not provisioned with
IPv6 addresses. For local IPv6 communication, the mechanisms
specified in [RFC4191] are used.
ULA addressing is useful where the IPv6 CE router has multiple LAN
interfaces with hosts that need to communicate with each other. If
the IPv6 CE router has only a single LAN interface (IPv6 link), then
link-local addressing can be used instead.
Coexistence with IPv4 requires any IPv6 CE router(s) on the LAN to
conform to these recommendations, especially requirements ULA-5 and
L-4 below.
Singh, et al. Expires September 9, 2012 [Page 6]
Internet-Draft IPv6 CE Router Requirements March 2012
4. Requirements
4.1. General Requirements
The IPv6 CE router is responsible for implementing IPv6 routing; that
is, the IPv6 CE router must look up the IPv6 destination address in
its routing table to decide to which interface it should send the
packet.
In this role, the IPv6 CE router is responsible for ensuring that
traffic using its ULA addressing does not go out the WAN interface,
and does not originate from the WAN interface.
G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node
Requirements [RFC6434] specification.
G-2: The IPv6 CE router MUST implement ICMPv6 according to
[RFC4443]. In particular, point-to-point links MUST be handled
as described in Section 3.1 of [RFC4443].
G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
its LAN interface(s) and its WAN interface until the router has
successfully completed the IPv6 address and the delegated
prefix acquisition process.
G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it
originates [RFC4861].
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
4.2. WAN-Side Configuration
The IPv6 CE router will need to support connectivity to one or more
access network architectures. This document describes an IPv6 CE
router that is not specific to any particular architecture or service
provider and that supports all commonly used architectures.
IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of
IPv6-supported link layer, and there is no need for a link-layer-
Singh, et al. Expires September 9, 2012 [Page 7]
Internet-Draft IPv6 CE Router Requirements March 2012
specific configuration protocol for IPv6 network-layer configuration
options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This
section makes the assumption that the same mechanism will work for
any link layer, be it Ethernet, the Data Over Cable Service Interface
Specification (DOCSIS), PPP, or others.
WAN-side requirements:
W-1: When the router is attached to the WAN interface link, it MUST
act as an IPv6 host for the purposes of stateless [RFC4862] or
stateful [RFC3315] interface address assignment.
W-2: The IPv6 CE router MUST generate a link-local address and
finish Duplicate Address Detection according to [RFC4862] prior
to sending any Router Solicitations on the interface. The
source address used in the subsequent Router Solicitation MUST
be the link-local address on the WAN interface.
W-3: Absent other routing information, the IPv6 CE router MUST use
Router Discovery as specified in [RFC4861] to discover a
default router(s) and install default route(s) in its routing
table with the discovered router's address as the next hop.
W-4: The router MUST act as a requesting router for the purposes of
DHCPv6 prefix delegation ([RFC3633]).
W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier
(DUID) for DHCPv6 messages. The DUID MUST NOT change between
network interface resets or IPv6 CE router reboots.
W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP
client as specified in [I-D.ietf-pcp-base] for use by
applications on the CE Router. This document takes no position
on whether such functionality is enabled by default or
mechanisms by which users would configure the functionality.
Link-layer requirements:
WLL-1: If the WAN interface supports Ethernet encapsulation, then
the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].
WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE
router MUST support IPv6 over PPP [RFC5072].
WLL-3: If the WAN interface supports PPP encapsulation, in a dual-
stack environment with IPCP and IPV6CP running over one PPP
logical channel, the Network Control Protocols (NCP's) MUST
be treated as independent of each other and start and
Singh, et al. Expires September 9, 2012 [Page 8]
Internet-Draft IPv6 CE Router Requirements March 2012
terminate independently.
Address assignment requirements:
WAA-1: The IPv6 CE router MUST support Stateless Address
Autoconfiguration (SLAAC) [RFC4862].
WAA-2: The IPv6 CE router MUST follow the recommendations in Section
4 of [RFC5942], and in particular the handling of the L flag
in the Router Advertisement Prefix Information option.
WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client
behavior.
WAA-4: The IPv6 CE router MUST be able to support the following
DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and
DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to
support the DNS Search List DNSSL option as specified in
[RFC3646].
WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network
Time Protocol (SNTP) option [RFC4075] and the Information
Refresh Time option [RFC4242].
WAA-6: If the IPv6 CE router receives a Router Advertisement message
(described in [RFC4861]) with the M flag set to 1, the IPv6
CE router MUST do DHCPv6 address assignment (request an IA_NA
option).
WAA-7: If the IPv6 CE router does not acquire global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create
global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network
interfaces, unless configured to require a global IPv6
address on the WAN interface.
WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option
[I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
Advertise or Reply message and set its internal SOL_MAX_RT
parameter to the value contained in the SOL_MAX_RT option.
WAA-9: As a router, the IPv6 CE router MUST follow the weak host
(Weak ES) model [RFC1122]. When originating packets from an
interface, it will use a source address from another one of
its interfaces if the outgoing interface does not have an
address of suitable scope.
Prefix delegation requirements:
Singh, et al. Expires September 9, 2012 [Page 9]
Internet-Draft IPv6 CE Router Requirements March 2012
WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation
requesting router behavior as specified in [RFC3633] (IA_PD
option). The IPv6 CE Router SHOULD support the
[I-D.ietf-dhc-pd-exclude] PD-Exclude option.
WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating
router the size of the prefix it requires. If so, it MUST
ask for a prefix large enough to assign one /64 for each of
its interfaces, rounded up to the nearest nibble, and SHOULD
be configurable to ask for more.
WPD-3: The IPv6 CE router MUST be prepared to accept a delegated
prefix size different from what is given in the hint. If the
delegated prefix is too small to address all of its
interfaces, the IPv6 CE router SHOULD log a system management
error.
WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix
delegation when either the M or O flags are set to 1 in a
received Router Advertisement message.
WPD-5: If the delegated prefix(es) are aggregate route(s) of
multiple, more-specific routes, the IPv6 CE router MUST
discard packets that match the aggregate route(s), but not
any of the more-specific routes. In other words, the next
hop for the aggregate route(s) should be the null
destination. This is necessary to prevent forwarding loops
when some addresses covered by the aggregate are not
reachable [RFC4632].
(a) The IPv6 CE router SHOULD send an ICMPv6 Destination
Unreachable message in accordance with Section 3.1 of
[RFC4443] back to the source of the packet, if the
packet is to be dropped due to this rule.
WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD
option in DHCPv6, it MUST accept an IA_PD option in DHCPv6
Advertise/Reply messages, even if the message does not
contain any addresses, unless configured to only obtain its
WAN IPv6 address via DHCPv6.
WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic
routing protocol on its WAN interface.
Singh, et al. Expires September 9, 2012 [Page 10]
Internet-Draft IPv6 CE Router Requirements March 2012
4.3. LAN-Side Configuration
The IPv6 CE router distributes configuration information obtained
during WAN interface provisioning to IPv6 hosts and assists IPv6
hosts in obtaining IPv6 addresses. It also supports connectivity of
these devices in the absence of any working WAN interface.
An IPv6 CE router is expected to support an IPv6 end-user network and
IPv6 hosts that exhibit the following characteristics:
1. Link-local addresses may be insufficient for allowing IPv6
applications to communicate with each other in the end-user
network. The IPv6 CE router will need to enable this
communication by providing globally scoped unicast addresses or
ULA's [RFC4193], whether or not WAN connectivity exists.
2. IPv6 hosts should be capable of using SLAAC and may be capable of
using DHCPv6 for acquiring their addresses.
3. IPv6 hosts may use DHCPv6 for other configuration information,
such as the DNS_SERVERS option for acquiring DNS information.
Unless otherwise specified, the following requirements apply to the
IPv6 CE router's LAN interfaces only.
ULA requirements:
ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA
prefix [RFC4193].
ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix
consistently across reboots.
ULA-3: The value of the ULA prefix SHOULD be user-configurable.
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
LAN requirements:
Singh, et al. Expires September 9, 2012 [Page 11]
Internet-Draft IPv6 CE Router Requirements March 2012
L-1: The IPv6 CE router MUST support router behavior according to
Neighbor Discovery for IPv6 [RFC4861].
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
L-4: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime [RFC4861] greater than zero if
it has no prefixes configured or delegated to it.
L-5: The IPv6 CE router MUST make each LAN interface an advertising
interface according to [RFC4861].
L-6: In Router Advertisement messages, the Prefix Information
option's A and L flags MUST be set to 1 by default.
L-7: The A and L flags' settings SHOULD be user-configurable.
L-8: The IPv6 CE router MUST support a DHCPv6 server capable of
IPv6 address assignment according to [RFC3315] OR a stateless
DHCPv6 server according to [RFC3736] on its LAN interfaces.
L-9: Unless the IPv6 CE router is configured to support the DHCPv6
IA_NA option, it SHOULD set the M flag to 0 and the O flag to
1 in its Router Advertisement messages [RFC4861].
L-10: The IPv6 CE router MUST support providing DNS information in
the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646].
L-11: The IPv6 CE router MUST support providing DNS information in
the Router Advertisement Recursive DNS Server (RDNSS) and
DNSSL options.
L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6
options (as listed in Section 5.3 of [RFC3736]) received from
the DHCPv6 client on its WAN interface to its LAN-side DHCPv6
server.
Singh, et al. Expires September 9, 2012 [Page 12]
Internet-Draft IPv6 CE Router Requirements March 2012
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero and a Valid
Lifetime of either a) zero, or b) the lower of the current
Valid Lifetime and two hours (which must be decremented in
real time) in a Router Advertisement message as described in
Section 5.5.3, (e) of [RFC4862].
L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
message, code 5 (Source address failed ingress/egress policy)
for packets forwarded to it that use an address from a prefix
that has been deprecated.
4.4. Transition Technologies Support
4.4.1. 6rd
6rd [RFC5969] specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a service provider's IPv4
network infrastructure. Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service that is equivalent to native IPv6 at the sites that are
served by the mechanism. It is expected that such traffic is
forwarded over the CE Router's native IPv4 WAN interface, and not
encapsulated in another tunnel.
The CE Router SHOULD support 6rd functionality. If 6rd is supported,
it MUST be implemented according to [RFC5969]. The following CE
Requirements also apply:
.
6rd requirements:
6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd
DHCPv4 Option (212). If the CE router has obtained an IPv4
network address through some other means such PPP, it SHOULD
use the DHCPINFORM request message [RFC2131] to request the
6rd DHCPv4 Option. The IPv6 CE router MAY use other
mechanisms to configure 6rd parameters. Such mechanisms are
outside the scope of this document.
6RD-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd.
Singh, et al. Expires September 9, 2012 [Page 13]
Internet-Draft IPv6 CE Router Requirements March 2012
6RD-3: If the CE router supports configuration mechanisms other than
the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE
router MUST support 6rd in "hub and spoke" mode. 6rd in "hub
and spoke" requires all IPv6 traffic to go to the 6rd Border
Relay. In effect, this requirement removes the "direct
connect to 6rd" route defined in Section 7.1.1 of [RFC5969].
4.4.2. Dual-Stack Lite (DS-Lite)
Dual-Stack Lite [RFC6333] enables both continued support for IPv4
services and incentives for the deployment of IPv6. It also de-
couples IPv6 deployment in the Service Provider network from the rest
of the Internet, making incremental deployment easier. Dual-Stack
Lite enables a broadband service provider to share IPv4 addresses
among customers by combining two well-known technologies: IP in IP
(IPv4-in-IPv6) and Network Address Translation (NAT). It is expected
that DS-Lite traffic is forwarded over the CE Router's native IPv6
WAN interface, and not encapsulated in another tunnel.
The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS-
Lite is supported, it MUST be implemented according to [RFC6333].
The following CE Router requirements also apply:
WAN requirements:
DLW-1: The CE Router MUST support DS-Lite via the DS-Lite DHCPv6
option [RFC6334]. The IPv6 CE Router MAY use other
mechanisms to configure DS-Lite parameters. Such mechanisms
are outside the scope of this document.
DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address
Translation (NAT) on IPv4 traffic encapsulated using DS-Lite.
DLW-3: If the IPv6 CE Router is configured with an IPv4 address on
its WAN interface then the IPv6 CE Router SHOULD disable the
DS-Lite B4 element.
4.5. Security Considerations
It is considered a best practice to filter obviously malicious
traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus,
the IPv6 CE router ought to support basic stateless egress and
ingress filters. The CE router is also expected to offer mechanisms
to filter traffic entering the customer network; however, the method
by which vendors implement configurable packet filtering is beyond
the scope of this document.
Security requirements:
Singh, et al. Expires September 9, 2012 [Page 14]
Internet-Draft IPv6 CE Router Requirements March 2012
S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular,
the IPv6 CE router SHOULD support functionality sufficient for
implementing the set of recommendations in [RFC6092],
Section 4. This document takes no position on whether such
functionality is enabled by default or mechanisms by which
users would configure it.
S-2: The IPv6 CE router SHOULD support ingress filtering in
accordance with BCP 38 [RFC2827].
S-3: If the IPv6 CE router firewall is configured to filter incoming
tunneled data, the firewall SHOULD provide the capability to
filter decapsulated packets from a tunnel.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
Thanks to the following people (in alphabetical order) for their
guidance and feedback:
Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker, Mohamed
Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou,
Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand,
Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline,
Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi
Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael
Newbery, Carlos Pignataro, John Pomeroy, Antonio Querubin, Hiroki
Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark Townsley,
Bernie Volz, Dan Wing, James Woodyatt, Carl Wuyts, and Cor Zwart.
This document is based in part on CableLabs' eRouter specification.
The authors wish to acknowledge the additional contributors from the
eRouter team:
Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas,
Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego
Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur
Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan
Torbet, and Greg White.
Singh, et al. Expires September 9, 2012 [Page 15]
Internet-Draft IPv6 CE Router Requirements March 2012
7. Contributors
The following people have participated as co-authors or provided
substantial contributions to this document: Ralph Droms, Kirk
Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay,
Yiu Lee, John Jason Brzozowski, and Heather Kirksey.
8. References
8.1. Normative References
[I-D.droms-dhc-dhcpv6-maxsolrt-update]
Droms, R., "Modification to Default Value of MAX_SOL_RT",
draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in
progress), November 2011.
[I-D.ietf-dhc-pd-exclude]
Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", draft-ietf-dhc-pd-exclude-04 (work in
progress), December 2011.
[I-D.ietf-pcp-base]
Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
Penno, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-23 (work in progress), February 2012.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
Singh, et al. Expires September 9, 2012 [Page 16]
Internet-Draft IPv6 CE Router Requirements March 2012
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
[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.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", RFC 4779, January 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Singh, et al. Expires September 9, 2012 [Page 17]
Internet-Draft IPv6 CE Router Requirements March 2012
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092,
January 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
8.2. Informative References
[MULTIHOMING-WITHOUT-NAT]
Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", Work in Progress, December 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, March 2011.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001,
<http://www.upnp.org/>.
Singh, et al. Expires September 9, 2012 [Page 18]#x27; may be sent by the network as
end code for the transfer of information values, through
which special events can be indicated to the user. In
some countries the '*' or '#' may be used instead of
'A', 'B', 'C' or 'D'.
The value of this MIB Object MUST NOT persist across MTA
reboots."
REFERENCE
"ETSI-EN-300-659-1 specification"
DEFVAL {dtmfcodeC}
::= { pktcSigDevObjects 36 }
pktcSigDevVmwiSigProtocol OBJECT-TYPE
SYNTAX PktcSubscriberSideSigProtocol
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the subscriber line protocol used
for signaling the Information on Visual Message Waiting
Indicator (VMWI). Different countries define different
VMWI signaling protocols to support VMWI service.
Frequency shift keying (FSK) is most commonly used.
Dual tone multi-frequency (DTMF) is an alternative.
The value of this MIB Object MUST NOT persist across MTA
reboots."
DEFVAL { fsk }
::= { pktcSigDevObjects 37 }
pktcSigDevVmwiDelayAfterLR OBJECT-TYPE
SYNTAX Unsigned32 (0|300..800)
UNITS "Milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the delay between the end of the
Line Reversal and the start of the FSK or DTMF signal.
This object is only used when pktcSigDevVmwiMode is
set to a value of 'lrETS'.
This timing has a range of 300 to 800 ms.
The following table defines the default values
for this MIB Object, depending on the signal type
(pktcSigDevVmwiMode) and MUST be followed:
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 45]
PacketCable/IPCablecom NCS Signaling MIB August 2007
Value of pktcSigDevVmwiMode Default value
duringringingETS any value (not used)
dtAsETS any value (not used)
rpAsETS any value (not used)
lrAsETS any value (not used)
lrETS 400
An attempt to set this object while the value of
pktcSigDevVmwiMode is not 'lrETS' will result in an
'inconsistentValue' error.
The value of this MIB Object MUST NOT persist across MTA
reboots."
DEFVAL {400}
::= {pktcSigDevObjects 38 }
pktcSigDevVmwiDtmfStartCode OBJECT-TYPE
SYNTAX DtmfCode
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies optional start codes used when
the pktcSigDevVmwiSigProtocol is set to a value of
'dtmf(2)'. Different countries define different On Hook
Data Transmission Protocol signaling codes to support
VMWI.
When Dual tone multi-frequency (DTMF) is used the VMWI
digits are preceded by a 'start code' digit, followed
by the digit transmission sequence <S1>...<Sn> (where
Sx represents the digits 0-9) and terminated by the 'end
code' digit.
For e.g.
<A><S1>...<Sn> <D><S1>...<Sn> <B><S1>...<Sn> <C>.
The start code for redirecting VMWI may be DTMF 'D'
The DTMF code 'B' may be sent by the network as start
code for the transfer of information values, through
which special events can be indicated to the user. In
some countries the '*' or '#' may be used instead of
'A', 'B', 'C' or 'D'.
The value of this MIB Object MUST NOT persist across MTA
reboots."
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 46]
PacketCable/IPCablecom NCS Signaling MIB August 2007
REFERENCE
"ETSI-EN-300-659-1 specification"
DEFVAL {dtmfcodeA}
::= { pktcSigDevObjects 39 }
pktcSigDevVmwiDtmfEndCode OBJECT-TYPE
SYNTAX DtmfCode
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies optional end code used when the
pktcSigDevVmwiSigProtocol is set to a value of
'dtmf(2)'. Different countries define different On Hook
Data Transmission Protocol signaling codes to support
VMWI.
When Dual tone multi-frequency (DTMF) is used the VMWI
digits are preceded by a 'start code' digit, followed
by the digit transmission sequence <S1>...<Sn> (where
Sx represents the digits 0-9) and terminated by the 'end
code' digit.
For e.g.
<A><S1>...<Sn> <D><S1>...<Sn> <B><S1>...<Sn> <C>.
The DTMF code 'C' may be sent by the network as end code
for the transfer of information values, through which
special events can be indicated to the user. In some
countries the '*' or '#' may be used instead of 'A',
'B', 'C' or 'D'.
The value of this MIB Object MUST NOT persist across MTA
reboots."
REFERENCE
"ETSI-EN-300-659-1 specification"
DEFVAL {dtmfcodeC}
::= { pktcSigDevObjects 40 }
pktcSigDevrpAsDtsDuration OBJECT-TYPE
SYNTAX Unsigned32 (0|200..500)
UNITS "Milliseconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object specifies the duration of the rpASDTS ring
pulse prior to the start of the transmission of the
FSK or DTMF containing the Caller ID information. It is
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 47]
PacketCable/IPCablecom NCS Signaling MIB August 2007
only used when pktcSigDevCidMode is set to a value of
'rpAsETS'.
The following table defines the default values
for this MIB Object, depending on the signal type
(pktcSigDevCidMode) and MUST be followed:
Value of pktcSigDevCidMode Default value
duringringingETS any value (not used)
dtAsETS any value (not used)
rpAsETS 250
lrAsETS any value (not used)
lrETS any value (not used)
An attempt to set this object while the value of
pktcSigDevCidMode is not 'rpAsETS' will result in
an 'inconsistentValue' error.
The value of this MIB Object MUST NOT persist across MTA
reboots."
REFERENCE
"ETSI-EN-300-659-1 Specification and Belgacom
BGC_D_48_9811_30_09_EDOC version 3.3"
DEFVAL { 250 }
::= {pktcSigDevObjects 41 }
--
-- The Endpoint Config Table is used to define attributes that
-- are specific to connection EndPoints.
--
pktcSigEndPntConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcSigEndPntConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table describes the information pertaining to each
endpoint of the MTA. All entries in this table represent
the provisioned endpoints provisioned with the information
required by the MTA to maintain the NCS protocol
communication with the CMS. Each endpoint can be assigned
to its own CMS. If the specific endpoint does not have
the corresponding CMS information in this table, the
endpoint is considered as not provisioned with voice
services. Objects in this table do not persist across
MTA reboots."
::= { pktcSigEndPntConfigObjects 1 }
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 48]
PacketCable/IPCablecom NCS Signaling MIB August 2007
pktcSigEndPntConfigEntry OBJECT-TYPE
SYNTAX PktcSigEndPntConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in the pktcSigEndPntConfigTable represents
required signaling parameters for the specific endpoint
provisioned with voice services. The conceptual rows MUST
NOT persist across MTA reboots."
INDEX { ifIndex }
::= { pktcSigEndPntConfigTable 1 }
PktcSigEndPntConfigEntry ::= SEQUENCE {
pktcSigEndPntConfigCallAgentId SnmpAdminString,
pktcSigEndPntConfigCallAgentUdpPort InetPortNumber,
pktcSigEndPntConfigPartialDialTO Unsigned32,
pktcSigEndPntConfigCriticalDialTO Unsigned32,
pktcSigEndPntConfigBusyToneTO Unsigned32,
pktcSigEndPntConfigDialToneTO Unsigned32,
pktcSigEndPntConfigMessageWaitingTO Unsigned32,
pktcSigEndPntConfigOffHookWarnToneTO Unsigned32,
pktcSigEndPntConfigRingingTO Unsigned32,
pktcSigEndPntConfigRingBackTO Unsigned32,
pktcSigEndPntConfigReorderToneTO Unsigned32,
pktcSigEndPntConfigStutterDialToneTO Unsigned32,
pktcSigEndPntConfigTSMax Unsigned32,
pktcSigEndPntConfigMax1 Unsigned32,
pktcSigEndPntConfigMax2 Unsigned32,
pktcSigEndPntConfigMax1QEnable TruthValue,
pktcSigEndPntConfigMax2QEnable TruthValue,
pktcSigEndPntConfigMWD Unsigned32,
pktcSigEndPntConfigTdinit Unsigned32,
pktcSigEndPntConfigTdmin Unsigned32,
pktcSigEndPntConfigTdmax Unsigned32,
pktcSigEndPntConfigRtoMax Unsigned32,
pktcSigEndPntConfigRtoInit Unsigned32,
pktcSigEndPntConfigLongDurationKeepAlive Unsigned32,
pktcSigEndPntConfigThist Unsigned32,
pktcSigEndPntConfigStatus RowStatus,
pktcSigEndPntConfigCallWaitingMaxRep Unsigned32,
pktcSigEndPntConfigCallWaitingDelay Unsigned32,
pktcSigEndPntStatusCallIpAddressType InetAddressType,
pktcSigEndPntStatusCallIpAddress InetAddress,
pktcSigEndPntStatusError INTEGER,
pktcSigEndPntConfigMinHookFlash Unsigned32,
pktcSigEndPntConfigMaxHookFlash Unsigned32,
pktcSigEndPntConfigPulseDialInterdigitTime Unsigned32,
pktcSigEndPntConfigPulseDialMinMakeTime Unsigned32,
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 49]
PacketCable/IPCablecom NCS Signaling MIB August 2007
pktcSigEndPntConfigPulseDialMaxMakeTime Unsigned32,
pktcSigEndPntConfigPulseDialMinBreakTime Unsigned32,
pktcSigEndPntConfigPulseDialMaxBreakTime Unsigned32
}
pktcSigEndPntConfigCallAgentId OBJECT-TYPE
SYNTAX SnmpAdminString(SIZE (3..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains a string indicating the call agent
name (e.g.: ca@example.com). The call agent name, after
the character '@', MUST be a fully qualified domain name
(FQDN) and MUST have a corresponding pktcMtaDevCmsFqdn
entry in the pktcMtaDevCmsTable. The object
pktcMtaDevCmsFqdn is defined in the PacketCable MIBMTA
Specification. For each particular endpoint, the MTA MUST
use the current value of this object to communicate with
the corresponding CMS. The MTA MUST update this object
with the value of the 'Notified Entity' parameter of the
NCS message. Because of the high importance of this object
to the ability of the MTA to maintain reliable NCS
communication with the CMS, it is highly recommended not
to change this object's value using SNMP during normal
operation."
::= { pktcSigEndPntConfigEntry 1 }
pktcSigEndPntConfigCallAgentUdpPort OBJECT-TYPE
SYNTAX InetPortNumber (1025..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the current value of the User
Datagram Protocol (UDP) receive port on which the
call agent will receive NCS from the endpoint.
For each particular endpoint, the MTA MUST use the current
value of this object to communicate with the corresponding
CMS. The MTA MUST update this object with the value of the
'Notified Entity' parameter of the NCS message. If the
Notified Entity parameter does not contain a CallAgent
port, the MTA MUST update this object with the default
value of 2727. Because of the high importance of this
object to the ability of the MTA to maintain reliable NCS
communication with the CMS, it is highly recommended not
to change this object's value using SNMP during normal
operation."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 2727 }
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 50]
PacketCable/IPCablecom NCS Signaling MIB August 2007
::= { pktcSigEndPntConfigEntry 2 }
pktcSigEndPntConfigPartialDialTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the value of the partial dial
time out.
The Time out (TO) elements are intended to limit the time a
tone or frequency is generated. When this MIB Object is set
to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 16 }
::= { pktcSigEndPntConfigEntry 3 }
pktcSigEndPntConfigCriticalDialTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the value of the critical
dial time out.
The Time out (TO) elements are intended to limit the time a
tone or frequency is generated. When this MIB Object is set
to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 4 }
::= { pktcSigEndPntConfigEntry 4 }
pktcSigEndPntConfigBusyToneTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for busy
tone. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 51]
PacketCable/IPCablecom NCS Signaling MIB August 2007
the value of the object is modified by the SNMP Management
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 30 }
::= { pktcSigEndPntConfigEntry 5 }
pktcSigEndPntConfigDialToneTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for dial
tone. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
the value of the object is modified by the SNMP Management
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 16 }
::= { pktcSigEndPntConfigEntry 6 }
pktcSigEndPntConfigMessageWaitingTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for message
waiting indicator. The MTA MUST NOT update this object
with the value provided in the NCS message (if
present). If the value of the object is modified by the
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 52]
PacketCable/IPCablecom NCS Signaling MIB August 2007
SNMP Manager application, the MTA MUST use the new value
as a default only for a new signal requested by the NCS
message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 16 }
::= { pktcSigEndPntConfigEntry 7 }
pktcSigEndPntConfigOffHookWarnToneTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for the off
hook Warning tone. The MTA MUST NOT update this object
with the value provided in the NCS message (if
present). If the value of the object is modified by the
SNMP Manager application, the MTA MUST use the new value
as a default only for a new signal requested by the NCS
message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 0 }
::= { pktcSigEndPntConfigEntry 8 }
pktcSigEndPntConfigRingingTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for
ringing. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 53]
PacketCable/IPCablecom NCS Signaling MIB August 2007
the value of the object is modified by the SNMP Management
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 180 }
::= { pktcSigEndPntConfigEntry 9 }
pktcSigEndPntConfigRingBackTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for ring
back. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
the value of the object is modified by the SNMP Management
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 180 }
::= { pktcSigEndPntConfigEntry 10 }
pktcSigEndPntConfigReorderToneTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for reorder
tone. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
the value of the object is modified by the SNMP Management
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 54]
PacketCable/IPCablecom NCS Signaling MIB August 2007
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 30 }
::= { pktcSigEndPntConfigEntry 11 }
pktcSigEndPntConfigStutterDialToneTO OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the default timeout value for stutter
dial tone. The MTA MUST NOT update this object with the
value provided in the NCS message (if present). If
the value of the object is modified by the SNMP Management
Station, the MTA MUST use the new value as a default only
for a new signal requested by the NCS message.
The Time out (TO) elements are intended to limit the time
a tone or frequency is generated. When this MIB Object is
set to a value of '0', the MTA MUST NOT generate the
corresponding frequency or tone regardless of the
definitions pertaining to frequency, tone duration or
cadence."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 16 }
::= { pktcSigEndPntConfigEntry 12 }
pktcSigEndPntConfigTSMax OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This MIB object is used as part of an NCS
retransmission algorithm. Prior to any retransmission,
the MTA must check to make sure that the time elapsed
since the sending of the initial datagram does not
exceed the value specified by this MIB Object. If more
than Tsmax time has elapsed, then the retransmissions
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 55]
PacketCable/IPCablecom NCS Signaling MIB August 2007
MUST cease.
Refer to the MIB Object pktcSigEndPntConfigThist for
information on when the endpoint becomes disconnected."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 20 }
::= { pktcSigEndPntConfigEntry 13 }
pktcSigEndPntConfigMax1 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the suspicious error threshold for
signaling messages. The pktcSigEndPntConfigMax1 object
indicates the retransmission threshold at which the MTA MAY
actively query the domain name server (DNS) in order to
detect the possible change of call agent interfaces."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 5 }
::= { pktcSigEndPntConfigEntry 14 }
pktcSigEndPntConfigMax2 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object contains the disconnect error threshold for
signaling messages. The pktcSigEndPntConfigMax2 object
indicates the retransmission threshold at which the MTA
SHOULD contact the DNS one more time to see if any other
interfaces to the call agent have become available."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 7 }
::= { pktcSigEndPntConfigEntry 15 }
pktcSigEndPntConfigMax1QEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object enables/disables the Max1 domain name server
(DNS) query operation when the pktcSigEndPntConfigMax1
threshold has been reached.
A value of true(1) indicates enabling, and a value of
false(2) indicates disabling."
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 56]
PacketCable/IPCablecom NCS Signaling MIB August 2007
DEFVAL { true }
::= { pktcSigEndPntConfigEntry 16 }
pktcSigEndPntConfigMax2QEnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object enables/disables the Max2 domain name server
(DNS) query operation when the pktcSigEndPntConfigMax2
threshold has been reached.
A value of true(1) indicates enabling, and a value of
false(2) indicates disabling."
DEFVAL { true }
::= { pktcSigEndPntConfigEntry 17 }
pktcSigEndPntConfigMWD OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum Waiting Delay (MWD) contains the maximum number of
seconds an MTA waits after powering on, before initiating
the restart procedure with the call agent."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 600 }
::= { pktcSigEndPntConfigEntry 18 }
pktcSigEndPntConfigTdinit OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This MIB object represents the 'disconnected' initial
waiting delay within the context of an MTA's 'disconnected
procedure'. The 'disconnected procedure' is initiated when
an endpoint becomes 'disconnected' while attempting to
communicate with a Call Agent.
The 'disconnected timer' associated with the 'disconnected
Procedure' is initialized to a random value, uniformly
distributed between zero and the value contained in this
MIB Object.
For more information on the usage of this timer, please
refer to the PacketCable NCS Specification."
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 57]
PacketCable/IPCablecom NCS Signaling MIB August 2007
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 15 }
::= { pktcSigEndPntConfigEntry 19 }
pktcSigEndPntConfigTdmin OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This MIB object represents the 'disconnected' minimum
waiting delay within the context of an MTA's
'disconnected procedure', specifically when local user
activity is detected.
The 'disconnected procedure' is initiated when
an endpoint becomes 'disconnected' while attempting to
communicate with a Call Agent.
For more information on the usage of this timer, please
refer to the PacketCable NCS Specification."
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 15 }
::= { pktcSigEndPntConfigEntry 20 }
pktcSigEndPntConfigTdmax OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the maximum number of seconds the MTA
waits after a disconnect, before initiating the
disconnected procedure with the call agent.
"
REFERENCE
"PacketCable NCS Specification"
DEFVAL { 600 }
::= { pktcSigEndPntConfigEntry 21 }
pktcSigEndPntConfigRtoMax OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Beacham/Kumar/Channabasappa Expires - January 2008 [Page 58]
PacketCable/IPCablecom NCS Signaling MIB August 2007
"This object specifies the maximum number of seconds the MTA
waits for a response to an NCS message before initiating
a retransmission."
REFERENCE
"PacketCable NCS Specification&
Internet-Draft IPv6 CE Router Requirements March 2012
Appendix A. Changes from RFC 6204
1. Added IP transition technologies available in RFC form.
2. Changed bullet G-5 to augment the condition of losing IPv6
default router(s) with loss of connectivity.
3. Removed bullet WAA-7 due to not reaching consensus by various
service provider standards bodies. The removal of text does not
remove any critical functionality from the CE specification.
4. Changed bullet WAA-8 to qualify WAN behavior only if not
configured to perform DHCPv6. This way a deployment specific
profile can mandate DHCPv6 numbered WAN without conflicting with
this document.
5. Changed the WPD-2 bullet from MUST be configurable to SHOULD be
configurable.
6. Changed bullet WPD-4 for a default behavior without compromising
any prior specification of the CE device. The change was needed
by a specific layer 1 deployment which wanted to specify a MUST
for DHCPv6 in their layer 1 profile and not conflict with this
document.
7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5
and WPD-5 because the text does not have consensus from the IETF
DHC Working Group for what the final solution related to the
removed bullets will be.
8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
that if an service provider does not have DHCPv6 service enabled
CE routers do not send too frequent DHCPv6 requests to the
service provider DHCPv6 server.
9. Changed bullet L-11 from SHOULD provide DNS options in the RA to
MUST provide DNS option in the RA.
10. New bullet added to the Security Considerations section due to
addition of transition technology. The CE router filters
decapsulated 6rd data.
11. Minor change involved changing ICMP to ICMPv6.
12. Added PCP client requirement for the WAN.
13. Added a requirement for the DHCPv6 pd-exclude option.
Singh, et al. Expires September 9, 2012 [Page 19]
Internet-Draft IPv6 CE Router Requirements March 2012
Authors' Addresses
Hemant Singh
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 1622
EMail: shemant@cisco.com
URI: http://www.cisco.com/
Wes Beebee
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 2030
EMail: wbeebee@cisco.com
URI: http://www.cisco.com/
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
EMail: c.donley@cablelabs.com
Barbara Stark
AT&T
725 W Peachtree St.
Atlanta, GA 30308
USA
EMail: barbara.stark@att.com
Singh, et al. Expires September 9, 2012 [Page 20]
Internet-Draft IPv6 CE Router Requirements March 2012
Ole Troan (editor)
Cisco Systems, Inc.
Telemarksvingen 20
N-0655 OSLO,
Norway
EMail: ot@cisco.com
Singh, et al. Expires September 9, 2012 [Page 21]