Network Working Group J. Kaippallimalil
Internet-Draft F. Xia
Expires: January 4, 2009 Huawei USA
July 3, 2008
IPv6 in Broadband Networks
draft-kaippallimalil-v6ops-ipv6-bbnet-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2009.
Kaippallimalil & Xia Expires January 4, 2009 [Page 1]
Internet-Draft IPv6 in Broadband Networks July 2008
Abstract
This document describes IPv6 link models and their applicability in a
fixed broadband network architecture. This document also specifies
the addressing and operation of IPv6 in broadband networks. The
scope of this specification is limited to the operation of IPv6 in a
broadband architecture. This includes the IPv6 link model, address
configuration, router and neighbor discovery in broadband
architecture.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture for IPv6 Broadband Networks . . . . . . . . . . . 4
3.1. Routed RG Model . . . . . . . . . . . . . . . . . . . . . 5
3.2. Bridged RG Model . . . . . . . . . . . . . . . . . . . . . 6
4. IPv6 Link . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IPv6 Link in Fixed Broadband Networks . . . . . . . . . . 7
4.2. Point-to-Point IPv6 Prefix Link . . . . . . . . . . . . . 7
4.3. Shared IPv6 Prefix Link . . . . . . . . . . . . . . . . . 9
5. IPv6 Link Establishment . . . . . . . . . . . . . . . . . . . 9
6. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. RG IPv6 Address . . . . . . . . . . . . . . . . . . . . . 11
6.2. Host IPv6 Address . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Host Behind Routed RG . . . . . . . . . . . . . . . . 13
6.2.2. Host Behind Bridged RG . . . . . . . . . . . . . . . . 15
7. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 17
7.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 17
7.3. Router Lifetime and Periodic Router Advertisements . . . . 18
8. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Kaippallimalil & Xia Expires January 4, 2009 [Page 2]
Internet-Draft IPv6 in Broadband Networks July 2008
1. Introduction
"Broadband Multiservice Architecture & Framework Requirements",
[TR-144] in Broadband Forum envisions support of IPv6 for various
access technologies such as DSL, FTTH over IEEE 802.3 (plain
Ethernet), IEEE 802.11 (wi-fi), IEEE 802.16 (WiMAX). TR-144
architecture applies to IPv4 and IPv6. Broadband Forum
specifications detail access technologies, aggregation networks,
business roles, etc.
This document describes IPv6 link models and their applicability in
the broadband architecture. This document also specifies the
addressing and operation of IPv6 in broadband networks. [RFC4779]
describes IPv6 deployment options in an TR-059 architecture based on
ATM access aggregation. [RFC4241] describes dual stack internet
access service, [RFC4029] describes overall scenarios for introducing
IPv6 into ISP networks and [RFC3769] describe prefix delegation
requirements. This memo applies the concepts in these documents and
focuses on describing IPv6 link models, host addressing for Ethernet
based access in TR-101 and multi-access networks from requirements in
TR-144. The scope of this specification is limited to the operation
of IPv6 in a fixed broadband architecture. This includes the IPv6
link model, address configuration, router and neighbor discovery in
fixed broadband architecture.
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 [RFC2119].
Broadband Network: The terms "broadband networks" and "fixed
broadband networks", are used in this document to refer to network
architectures specified in the Broadband Forum, including TR-101
and WT-145 architecture which is under discussion. The
requirements of this architecture are provided in [TR-144].
Trusted Host: A host authorized (transitively) in the provider
network (IP Edge), by virtue of a host authenticating to RG, and
RG authenticating to IP Edge. Examples include a host at home
that connects to a trusted port of the RG (e.g. wired Ethernet
connection), or authenticates locally to the RG (e.g. Wi-Fi with
local keys).
Untrusted Host: A host that is not trusted in the provider network
as a result of the authenticated RG. Such a host authenticates
directly with the provider network (IP Edge). Typically, nomadic
or mobile hosts are untrusted to begin with.
Kaippallimalil & Xia Expires January 4, 2009 [Page 3]
Internet-Draft IPv6 in Broadband Networks July 2008
AN Access Node
ASP Application Service Provider
DAD Duplicate Address Detection
DHCP Dynamic Host Configuration Protocol
DSL Digital Subscriber Line
EUI End User Identity
IID Interface Identifier
ISP Internet Service Provider
LLC Logical Link Control
MAC Medium Access Control
MLD Multicast Listener Discovery
ND Neighbor Discovery
NSP Network Service Provider
RG Residential Gateway
UE User Equipment
VLAN Virtual Local Area Network
3. Architecture for IPv6 Broadband Networks
A10
|
|----|---[ISP]
T U V W | |
+----+ | +----+ | +----+ | /-----\ | +-------+ /-----\ |
| UE |-|-| RG |--|-| AN |--|-{ Aggr. }-|-|IP Edge|-{ Aggr. }-|---[NSP]
+----+ +----+ +----+ \-----/ +-------+ \-----/ |
| |
|----|---[ASP]
|---------------| |------------------| |------------------|
Customer Premise Access Network Regional Broadband
Network
Figure 1: DSL Network Architecture
Fixed broadband network architecture and requirements are described
in [TR-059], [TR-101], and broadband multiservice requirements in
[TR-144]. The IP Edge depicted in Figure 1 manages the subscriber,
authenticates the user and provides IP QoS to the IP flows. The
architecture allows the injection of services to an end user from
more than one IP Edge. For example, multicast IP TV may be streamed
from a node other than the IP Edge that authenticated the host. The
Access Node (AN), in addition to terminating the subscriber line, may
handle multicast replication.
Kaippallimalil & Xia Expires January 4, 2009 [Page 4]
Internet-Draft IPv6 in Broadband Networks July 2008
Hosts in the network are located at the customer premise. The fixed
broadband architecture supports a routed, or bridged RG. In the case
of a routed RG, the RG authenticates with the network on behalf of
the (trusted) hosts behind it. Typical examples are connections over
wired Ethernet (or local Wi-Fi) to the PC, TV or home phone belonging
to that user. In the case of a bridged RG which is mainly
responsible for layer 2 forwarding, the hosts (UE) authenticate and
connect to the IP Edge. In current networks (IPv4), the bridged RG
is used so that a NATed router is not used at the RG. In upcoming
networks based on IPv6, nomadic or mobile clients that attach to such
networks would find it easy to attach
[RFC4779] describes IPv6 deployment options in a TR-059 architecture
based on ATM access aggregation. The focus in this memo is on
Ethernet based access in TR-101 and the upcoming specifications from
requirements in TR-144. This memo proposes in Section 4, Section 5
and Section 6, the link and addressing model for hosts and RGs for
both routed and bridged models. The descriptions below provide an
overview of the transport layers for both routed and bridged models.
3.1. Routed RG Model
In the routed model shown below, RG and IP Edge are routers. User
authentication is handled primarily by the IP Edge.
+-----+
| App |<---------------------------------------------------->
+-----+ +-------------+ +--------------+
|IPv6 |<---->| IPv6 |<---------------------------->| IPv6 |
+-----+ +-------------+ +--------------+ +-------+------+
| LLC/| | LLC | | LLC | | LLC | |
| | +......+......+ +......+.......+ +.......+ |
| | | | | | |802.1ad|<----->|802.1ad| L2 |
| MAC |<---->| MAC | MAC |<----->| MAC +-------+ +-------+ |
| | | | | | | MAC |<----->| MAC | |
+-----+ +------|------+ +------+-------+ +-------+------+
| PHY1|<---->| PHY1 | PHY2 |<----->| PHY2 | PHY3 |<----->| PHY3 | PHY |
+-----+ +------+------+ +------+-------+ +-------+------+
UE RG AN IP Edge
Figure 2: Routed RG IPv6 Transport Layers
Between the user (RG) and AN, plain Ethernet, C-tagged or priority
tagged VLANs may be used. S-tagged VLANs as specified in [TR-101]
Kaippallimalil & Xia Expires January 4, 2009 [Page 5]
Internet-Draft IPv6 in Broadband Networks July 2008
may be used in the aggregation network between the AN and IP Edge.
In this model with a routed RG, there is an IPv6 link between the RG
and the IP Edge, and a second IPv6 link between the host (UE) and RG.
3.2. Bridged RG Model
In the bridged model shown below, the RG and AN are layer 2 bridges.
User authentication is handled primarily by the IP Edge and it
implements access control for downstream unicast packets.
+-----+
| App |<---------------------------------------------------->
+-----+ +--------------+
|IPv6 |<------------------------------------------------->| IPv6 |
+-----+ +-------------+ +--------------+ +-------+------+
| LLC/| | LLC | | LLC | | LLC | |
| | +......+......+ +......+.......+ +.......+ |
| | | | | | |802.1ad|<----->|802.1ad| L2 |
| MAC |<---->| MAC | MAC |<----->| MAC +-------+ +-------+ |
| | | | | | | MAC |<----->| MAC | |
+-----+ +------|------+ +------+-------+ +-------+------+
| PHY1|<---->| PHY1 | PHY2 |<----->| PHY2 | PHY3 |<----->| PHY3 | PHY |
+-----+ +------+------+ +------+-------+ +-------+------+
UE RG AN IP Edge
Figure 3: Bridged IPv6 Transport Layers
Between the user (UE) and AN, plain Ethernet, C-tagged or priority
tagged VLANs may be used. S-tagged VLANs as specified in [TR-101]
may be used in the aggregation network between the AN and IP Edge.
In this model, the IPv6 link extends between the host (UE) and IP
Edge.
4. IPv6 Link
[RFC4903] defines link to refer to a topological area bounded by
routers that decrement the (IPv4 TTL or) IPv6 hop limit when
forwarding the packet. It further recommends the use of one of two
IP link models: multi-access link model (described here as shared
link model), and point-to-point link model. The sections below
describe the point-to-point IPv6 link model and shared IPv6 link
Kaippallimalil & Xia Expires January 4, 2009 [Page 6]
Internet-Draft IPv6 in Broadband Networks July 2008
model for a fixed broadband network.
4.1. IPv6 Link in Fixed Broadband Networks
In fixed broadband networks, hosts may be attached to the network
from behind a routed RG or a bridged RG. In the routed RG case,
there is an IP link between host and RG, and a second IP link between
RG and IP Edge. In the bridged RG case, there is one IP link between
the host and IP Edge.
Some basic requirements for subscriber links in an IPv4 DSL network
include network separation of attached hosts and a high address
assignment efficiency. The point-to-point IPv6 link model provides a
natural separation between hosts in a public access network.
Addresses assignment efficiency is not as high as in shared link
model. In a point-to-point link model, each IPv6 host interface
belongs to a separate IP link. A unique prefix is assigned to each
separate link. This link is consistent with a standard IP link, and
conforms with the definitions of point-to-point link in neighbor
discovery for IPv6 [RFC4861].
In a home network, a shared link model or point-to-point may be used
since network separation may not be as important.
4.2. Point-to-Point IPv6 Prefix Link
In this model, each IPv6 prefix link between a host and IP Edge is
allocated a separate, unique prefix by the IP Edge. This model is
well suited for public access network, such as fixed broadband
networks, where there is a need to separate the accesses belonging to
different users. Fixed broadband networks use aggregation between
the host and IP Edge and thus will not share the physical medium for
the entire IP link. This is a logical transport connection and can
be viewed as a point-to-point IPv6 link. The underlying transport
connection may be built from Ethernet, IEEE 802.1ad.
Kaippallimalil & Xia Expires January 4, 2009 [Page 7]
Internet-Draft IPv6 in Broadband Networks July 2008
+-------------+ +------+ +-------+
UE1----| RG1(routing)|------------| ... |---------| |
+-------------+ | | | |
| | | |
+-------------+ | AN | | |
UE2----|RG2(bridging)|------------|.... |---------|IP Edge|
+-------------+ | | | |
| | | |
| | | |
UE3-------------------|.... |---------| |
+------+ +-------+
|------------------------------------|
Point-to-point IPv6 links
Figure 4: Point-to-Point IPv6 Prefix Model
Figure 4 identifies three cases:
1. routed RG (RG1) with hosts behind it (UE1).
2. host connected behind a bridged RG (UE2, RG2).
3. host connected directly to the service provider network (UE3).
In the routed RG case (1), RG1 configures its link local address and
obtains a unique prefix in a router advertisement from the IP Edge.
The address derived using this prefix is used in RG management
traffic. The underlying layer 2 network should use a 1:1 VLAN
between RG and AN. RG1 uses [RFC3633] to obtain a delegated prefix
for hosts behind it (e.g. UE1). UE1 represents trusted hosts in the
home network (such as a PC, TV). The delegated prefix obtained using
[RFC3633] is off-link at the IP Edge.
In the bridged RG case (2), the host (UE2) configures its link local
address and then obtains a unique prefix in a router advertisement
from the IP Edge. The address(es) derived using this prefix are used
by the host for all its traffic. Between RG and AN, the underlying
layer 2 network may use N:1 VLAN to identify the hosts connected.
The directly connected host (case 3) is similar to case 2 for link
local address, global unicast prefix configuration. However, a 1:1
VLAN can be used in this case.
In a home network, UE1 represent trusted hosts of the user (such as a
PC, TV) connected to a trusted port in the RG. UE2 is a host that
connects to an untrusted port and has a bridged connection to the
access network for authentication and connection establishment. UE3
depicts a host over a network such as WiMAX .
Kaippallimalil & Xia Expires January 4, 2009 [Page 8]
Internet-Draft IPv6 in Broadband Networks July 2008
The point-to-point link IPv6 prefix model described here uses
existing specifications and does not require any protocol changes or
new protocols. No changes are required for the host either.
4.3. Shared IPv6 Prefix Link
In this model, hosts attached to an RG share one or more prefixes
used for constructing their global IPv6 addresses. The figure below
gives a high level overview of a shared IPv6 prefix link.
UE1-----\
| +-----------+ +---------+
UE2-----+-------|RG1(routed)|-------(AN)-------| IP Edge |
| +-----------+ +---------+
UE3-----/
|---------------|
shared link for
UE1, UE2, UE3
Figure 5: Shared IPv6 Prefix Link Model
When devices in the home connect to an RG (routed) and do not need
network separation, the RG may advertise a shared prefix IPv6 link to
multiple hosts. The figure shows RG1, a routed RG that advertises
common prefixes to UE1, UE2 and UE3. RG1 obtains these prefixes
using [RFC3633] prefix delegation. Shared link IPv6 model should not
be used in the provider network.
It should be noted that the RG in the home may use a point-to-point
IPv6 prefix model (as in previous section, Section 4.2) or a shared
IPv6 prefix model. When a shared prefix is used, the RG requires
only a /64 delegated prefix to advertise to hosts. When point-to-
point prefixes are used, a shorter delegated prefix is needed to
advertise unique /64 prefixes to hosts.
The shared link IPv6 prefix model uses existing specifications and
does not require any protocol changes or new protocols for routers or
hosts.
5. IPv6 Link Establishment
In order to enable the sending and receiving of IPv6 packets between
Kaippallimalil & Xia Expires January 4, 2009 [Page 9]
Internet-Draft IPv6 in Broadband Networks July 2008
the end host and IP edge, an IPv6 link between them must be
established. This section outlines the IPv6 link establishment
process.
The host (RG or UE) goes through the following IPv6 link setup
sequence:
1. RG or UE establishes basic link layer connectivity with the AN.
(Alternatively, for hosts behind routed RG, UE establishes link
layer connectivity with the routed RG). The procedures for
establishing the link are based on the physical and link layers
(such as DSL, FTTH, Ethernet and 802.11).
2. The end host, RG or UE, authenticates itself. An RG or UE
connected to the network provider authenticates with the IP Edge.
UEs behind a routed RG connect to trusted ports of an RG and are
transitively trusted by the network.
3. Upon successful authentication, the AN changes its access control
filters to allow flows on that IP link.
4. The host (RG or UE) sends a router solicitation to the access
router.
5. The router responds with router advertisement. At this point,
the IPv6 link is established.
6. IPv6 Addressing
The RG and UE are each initially configured with 48-bit globally
unique MAC addresses. This MAC address maybe used to generate the
modified EUI-64 format-based interface identifier as specified in "IP
Version 6 Addressing Architecture" [RFC4291]. The modified EUI-64
interface identifier is used in stateless address autoconfiguration.
Fixed broadband network architectures require a mechanism to provide
addresses to UEs directly connected to the network (or bridged RG) as
well as to UEs behind a routed RG. The following methods are used:
o Routed RG configures its link-local address on its upstream
interface. RG then uses [RFC3633] to obtain a delegated prefix to
advertise to hosts behind it. RG can be contacted using the sub-
router anycast address corresponding the allocated prefix
(however, the RG must use a global unicast IPv6 address as source
address in the response).
o Host (UE) configures its link-local address. The host then
configures its global address either statelessly or statefully
based on the indication in router advertisement from the access
router (routed RG, or IP Edge in case of bridged RG).
Duplicate Address Detection (DAD) SHOULD be performed as per
"Neighbor Discovery for IP Version 6 (IPv6)", [RFC4861] and "IPv6
Stateless Address Autoconfiguration" [RFC4862]. For point-to-point
Kaippallimalil & Xia Expires January 4, 2009 [Page 10]
Internet-Draft IPv6 in Broadband Networks July 2008
links, the only addresses are the host and router interface. Thus,
the chance of conflict is very low. For shared links in the home,
the DAD procedure is used to detect any duplicate addresses.
When stateless address autoconfiguration is performed, it MUST be
performed as specified in [RFC4861] and [RFC4862]. The IP Edge (or
routed RG) indicates in the router advertisement message if a host is
expected to use stateless address autoconfiguration.
When stateful address autoconfiguration is performed, it MUST be
performed as specified in [RFC4861] and [RFC3315]. The IP Edge (or
routed RG) indicates in the router advertisement message if a host is
expected to use stateful address autoconfiguration.
The sections below describe the procedure for RG and host address
configuration.
6.1. RG IPv6 Address
This section shows how the RG derives its own address for its
upstream interface. Following authentication, the RG derives its
link-local interface address using neighbor discovery mechanism in
[RFC4861].
RG
+---+ +--------------------+
|UE1|--------[P1]........ |
+---+ | : |
: | : |
+---+ | : |
|UEn|--------[Pn].......: |
+---+ | : +---+ |
| :...| R |.[NI]----------------
| +---+ : +---+ |
| |RG'|...: |
| +---+ |
+--------------------+
Figure 6: RG Address Model
When the RG obtains a delegated prefix using [RFC3633], the RG
allocates prefixes to trusted hosts behind it (UE1, UEn) that connect
to trusted ports (P1, Pn). The RG is reachable using the sub-router
anycast address corresponding to the [RFC3633] allocated prefix. The
Kaippallimalil & Xia Expires January 4, 2009 [Page 11]
Internet-Draft IPv6 in Broadband Networks July 2008
sub-router anycast address is represented as RG'.
The figure below shows a simple sequence of steps for configuring the
RG upstream address.
+-------+ +------+ +-------+
| RG | | AN | |IP Edge|
+-------+ +------+ +-------+
| | |
| 1 Authentication | |
|<--------------------------------------------->|
| | |
| 2 Link Local IPv6 | |
|Address Configuration | |
|------+ | |
| | | |
|<-----+ | |
| | |
| 3 MLD Join | |
|---------------------------------------------->|
| | |
| 4 DAD NS | |
|---------------------------------------------->|
| | |
| 5 RS | |
|---------------------------------------------->|
| | |
| 6 RA | |
|<----------------------------------------------|
| | |
Figure 7: RG Address Configuration Example
With respect to address configuration, the RG behaves as a host from
the IP Edge perspective, while it is a default router from the UEs
perspective. The sequence of steps for configuration is described
below:
1. RG authenticates with the provider network (IP Edge).
2. During upstream interface initiation, the RG forms its link local
address by combining the well-known prefix FE80::/10 with an
interface identifier (EUI-64).
Kaippallimalil & Xia Expires January 4, 2009 [Page 12]
Internet-Draft IPv6 in Broadband Networks July 2008
3. When the interface is enabled, the RG joins the all-nodes
multicast address on that interface, as well as its corresponding
solicited-node multicast address.
4. RG may verify address uniqueness by sending DAD NS to initiate
the DAD procedure. Since it is a point-to-point link, the only
other possibility of interface collision is that of the IP Edge
router interface (very low probability)
5. RG sends router solicitation to IP Edge.
6. IP Edge sends router advertisements indicating the configuration
method. When the IP Edge indicates stateless address config,
prefix information options are included in the RA. The RG
already has a link-local address and does not need to obtain a
global-scope IPv6 address. The IP Edge may reclaim these
advertised (but not used) prefixes when it receives a [RFC3633]
delegated address configuration request from the RG.
[draft-miles-dhc-dhcpv6-ldra-00] is used to relay DHCP messages
through the AN.
6.2. Host IPv6 Address
Hosts may be connected to trusted ports of an RG, bridged through an
RG (untrusted port) or connected directly to an access node. When
hosts are connected to trusted RG ports, the RG is a router and is
responsible for allocating prefixes for hosts behind it. When hosts
are connected over bridged RG or directly to the AN, the IP Edge is
responsible for allocating host prefixes. Section 6.2.1 describes a
host behind routed RG, Section 6.2.2 describes a host behind bridged
RG or a directly connected host.
6.2.1. Host Behind Routed RG
A host attached to a routed RG connects to the trusted ports of the
RG. The RG allocates prefixes/addresses based on the prefix that it
obtained using DHCP/[RFC3633]. The RG may allocate prefixes using
stateless autoconfiguration and advertise a prefix to the host (UE),
or the RG may use stateful address configuration based on DHCP
([RFC3315]. The host discovers the address configuration method in
the router advertisement sent by the RG. The host derives its
interface identity (IID) when necessary and performs neighbor
discovery in a standard manner. The figure below describes a
stateless autoconfiguration sequence with a routed RG and host.
Kaippallimalil & Xia Expires January 4, 2009 [Page 13]
Internet-Draft IPv6 in Broadband Networks July 2008
+-------+ +-------+ +------+ +-------+
| UE | | RG | | AN | |IP Edge|
+-------+ +-------+ +------+ +-------+
| | | |
| | 1 DHCP Request | |
| |----------------------------------->|
| | 2 DHCP Reply | |
| |<-----------------------------------|
| 3 Link local | | |
| address config | | |
|<----------------->| | |
| | | |
| 4 RA | | |
|<------------------| | |
| | | |
|5 Stateless Address| | |
|configuration | | |
|------+ | | |
| | | | |
|<-----+ | | |
| | | |
| 6 NS DAD | | |
|------------------>| | |
| | | |
| 7 DHCP | | |
| Configuration | | |
|<----------------->| | |
| | | |
Figure 8: UE Address Configuration, routed RG
In this example, the UE connects to the trusted port of an RG.
Hence, authentication is not required (or uses established locally
between UE and RG).
1. RG sends DHCP message to IP Edge requesting prefixes ([RFC3633])
and options requesting configuration parameters (DNS, NTP, SIP
etc.). Prefixes requested/assigned may be /64 when it is a
multi-access link for UEs, and smaller (e.g. /56, /48) when a
point-to-point model for UEs is used.
2. IP Edge sends DHCP reply with prefix and other configuration
information. IP Edge may assign an delegated prefix (e.g. /56,
/48) or provide a /64 delegated prefix.
3. UE configures its link local address according to [RFC4862].
Kaippallimalil & Xia Expires January 4, 2009 [Page 14]
Internet-Draft IPv6 in Broadband Networks July 2008
4. RA message contains indication as to whether stateless or
stateful configuration should be used.
5. Stateless method is assumed in this flow. The UE configures its
IID (EUI-64) and uses the prefix information in RA. (If it were
a stateful procedure, DHCP sequence would be used in place of
this step).
6. UE performs NS DAD with the derived/assigned address.
7. UE requests for configuration information such as DNS, NTP, SIP
server etc. using DHCP configuration.
6.2.2. Host Behind Bridged RG
A host attached to a bridged RG, or attached directly to an AN is not
trusted prior to authentication. This is the case when a UE is
nomadic or mobile. In this case, a host completes authentication and
then obtains a prefix or address from the network. The IP Edge sends
a router advertisement that indicates if the prefix is sent for
stateless address autoconfiguration, or if stateful address
autoconfiguration is required in the network. The figure below
illustrates a sequence that shows stateless address autoconfiguration
for a host behind an RG. A directly connected host would have the
same behavior since both the RG and AN behave as transparent bridges
with respect to obtaining the address/prefix.
Kaippallimalil & Xia Expires January 4, 2009 [Page 15]
Internet-Draft IPv6 in Broadband Networks July 2008
+-------+ +-------+ +-----+ +-------+
| UE | | RG | | AN | |IP Edge|
+-------+ +-------+ +-----+ +-------+
| | | |
| | 1 Authentication | |
|<------------------------------------------------------>|
| | | |
| | 2 Link local | |
| | address config | |
|<------------------------------------------------------>|
| | | |
| | 3 RS | |
|------------------------------------------------------->|
| | | |
| | 4 RA | |
|<-------------------------------------------------------|
| | | |
|5 Stateless Address| | |
|configuration | | |
|------+ | | |
| | | | |
|<-----+ | | |
| | | |
| | 6 NS DAD | |
|------------------------------------------------------->|
| | | |
| | 7 DHCP | |
| | Configuration | |
|<------------------------------------------------------>|
| | | |
Figure 9: UE Address Configuration, RG Bridged Mode
1. User is authenticated using one of 802.1X/DHCP/PANA.
2. UE configures its link-local address according to [RFC4862]. UE
joins the all-nodes multicast address on that interface, as well
as solicited-node multicast address corresponding to link local
IP addresses assigned to the interface. NS DAD is also
performed. Details of this procedure can be found in example in
Figure 7.
3. UE sends router solicitation message to IP Edge.
4. IP Edge responds with router advertisement message to UE
including an indication of stateless address configuration (and
advertised prefixes).
Kaippallimalil & Xia Expires January 4, 2009 [Page 16]
Internet-Draft IPv6 in Broadband Networks July 2008
5. Stateless method is assumed in this flow. The UE configures its
IID (EUI-64) and uses the prefix information in RA. (If it were
a stateful procedure, DHCP sequence would be used in place of
this step).
6. UE performs NS DAD with the derived/assigned address.
7. UE requests for configuration information such as DNS, NTP, SIP
server etc. using DHCP configuration.
7. Router Discovery
7.1. Router Solicitation
On completion of the establishment of the layer 2 link and
authentication, the host must send a router solicitation message to
request a router advertisement message from the access router and
acquire necessary information as per the neighbor discovery for IPv6
specification [RFC4861]. A UE or RG that is attached to the provider
network may send router solicitations to the IP Edge at any time on a
IPv6 link that has previously been established. A host (UE) behind a
routed RG may send a router solicitation following layer 2 link
establishment (and authentication to RG).
7.2. Router Advertisement
Router solicitations from the host trigger the sending of router
advertisements. The router advertisements are unicast back to the
host. Unsolicited router advertisements should not be sent.
Fixed broadband network architectures cover a number of access
technologies, some of them wired, and others wireless. For some
wireless networks, the frequency of router advertisements is lower
than that specified in [RFC4861] to avoid waking up a host. The IP
Edge should be configured to send the router advertisement at the
lowest rate required for the various access links. Alternatively,
the IP Edge may support different router advertisement frequency
based on access type.
[RFC2460] mandates 1280 bytes as a minimum MTU (Maximum Transmission
Unit) size for link layer and recommends at least 1500 bytes for IPv6
over Ethernet transmission. When VLANs are deployed on the link
between a UE and IP Edge, there may be restrictions on the supported
packet size. Adding VLAN tags to Ethernet frames increases the
length of the original Ethernet frame by 4 bytes for each VLAN tag,
which may cause the Ethernet frame to be discarded in the link
between the UE and the IP Edge. Therefore, the network operator
should consider the size of stacked VLAN tags when deploying VLANs
and set the MTU of the link. Neighbor discovery for IPv6 [RFC4861]
Kaippallimalil & Xia Expires January 4, 2009 [Page 17]
Internet-Draft IPv6 in Broadband Networks July 2008
defines an MTU option that an AR MUST advertise, via router
advertisement (RA), if a value different from 1500 is used. The UE
processes this option as defined in [RFC4861]. Nodes that implement
Path MTU Discovery [RFC1981] MAY use the mechanism to determine the
MTU for the IPv6 packets.
7.3. Router Lifetime and Periodic Router Advertisements
The router lifetime value SHOULD be set to a large value, preferably
in hours. The host should initiate a router solicitation well before
the end of router lifetime. This would trigger the router to reply
with a new router advertisement.
8. Multicast Listener Discovery
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
SHOULD be supported by hosts and AN attached via a layer 2 link.
Interface initialization as per [RFC4861] requires that when a
multicast capable interface becomes enabled, the node MUST join the
all-nodes multicast address on that interfaces, as well as the
solicited node multicast address corresponding to each of the IP
addresses assigned to the interface.
In fixed broadband networks, AN handles multicast access control and
replication. The AN should behave as an MLDv2 proxy for link-local
multicast and terminate MLD signaling for global multicast. For
link-local multicast (i.e. all-nodes and solicited-node multicast)
the AN should transparently forward all packets to the IP Edge.
Neighbor discovery messages use link-local multicast and should be
handled in the IP Edge.
9. Security Considerations
This document does not introduce any new vulnerabilities to IPv6
specifications or operation. The security of the various access
networks supported by the DSL architecture is the subject of those
specifications.
10. Acknowledgements
The authors would like to thank David Miles for reviewing this
document.
11. References
Kaippallimalil & Xia Expires January 4, 2009 [Page 18]
Internet-Draft IPv6 in Broadband Networks July 2008
11.1. Normative References
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[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.
11.2. Informative References
[TR-101] "Migration to Ethernet based DSL Aggregation", ,
April 2006.
[WT-146] "Subscriber Sessions", WT 146 (work in progress),
April 2007.
[TR-144] "Broadband Multiservice Architecture & Framework
Requirements", , April 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
Kaippallimalil & Xia Expires January 4, 2009 [Page 19]
Internet-Draft IPv6 in Broadband Networks July 2008
RFC 3314, September 2002.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A.
Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet
Access Service", RFC 4241, December 2005.
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method
for Subscriber Separation on an Ethernet Access Network",
RFC 4562, June 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.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
Kaippallimalil & Xia Expires January 4, 2009 [Page 20]
Internet-Draft IPv6 in Broadband Networks July 2008
Authors' Addresses
John Kaippallimalil
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 214-606-2005
Email: jkaippal@huawei.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Kaippallimalil & Xia Expires January 4, 2009 [Page 21]
Internet-Draft IPv6 in Broadband Networks July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kaippallimalil & Xia Expires January 4, 2009 [Page 22]