Network Working Group J. Kaippallimalil Internet-Draft F. Xia Expires: January 4, 2009 Huawei USA July 3, 2008 IPv6 in Broadband Networks draft-v6ops-kaippallimalil-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, xx) 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]