Figure 8.1 describes the current WLAN architecture. Customer | Access Provider | Service Provider Premise | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | |Access Router/| | Provider | |Edge | |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP |Router| ---- | | | | | | | |Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| +------+ Figure 8.1
The host should have a wireless Network Interface Card (NIC) in order to connect to a WLAN network. WLAN is a flat broadcast network and works in a similar fashion as Ethernet. When a host initiates a connection, it is authenticated by the AAA server located at the SP network. All the authentication parameters (username, password, etc.) are forwarded by the Access Point (AP) to the AAA server. The AAA server authenticates the host; once successfully authenticated, the host can send data packets. The AP is located near the host and acts as a bridge. The AP forwards all the packets coming to/from host to the Edge Router. The underlying connection between the AP and Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL, etc. WLANs operate within limited areas known as WiFi Hot Spots. While users are present in the area covered by the WLAN range, they can be connected to the Internet given they have a wireless NIC and required configuration settings in their devices (notebook PCs, PDAs, etc.). Once the user initiates the connection, the IP address is assigned by the SP using DHCPv4. In most of the cases, SP assigns a limited number of public IP addresses to its customers. When the user disconnects the connection and moves to a new WiFi hot spot, the above-mentioned process of authentication, address assignment, and accessing the Internet is repeated. There are IPv4 deployments where customers can use WLAN routers to connect over wireless to their service provider. These deployment types do not fit in the typical Hot Spot concept, but rather they serve fixed customers. For this reason, this section discusses the WLAN router options as well. In this case, the ISP provides a public IP address and the WLAN Router assigns private addresses [RFC1918] to all WLAN users. The WLAN Router provides NAT functionality while WLAN users access the Internet. While deploying IPv6 in the above-mentioned WLAN architecture, there are three possible scenarios as discussed below. A. Layer 2 NAP with Layer 3 termination at NSP Edge Router B. Layer 3 aware NAP with Layer 3 termination at Access Router C. PPP-Based Model
When initiating the connection, the WLAN Host is authenticated by the AAA server located at the SP network. All the parameters related to authentication (username, password, etc.) are forwarded by the AP to the AAA server. The AAA server authenticates the WLAN Hosts, and once the WLAN Host is authenticated and associated successfully with the WLAN AP, it acquires an IPv6 address. Note that the initiation and authentication process is the same as used in IPv4. Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is located between AP and Edge Router. Customer | Access Provider | Service Provider Premise | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | | Provider | |Edge | |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP |Router| ---- | | | | | | | |Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| +------+ Figure 8.1.1 RFC2462]. All hosts on the WLAN belong to the same /64 subnet that is statically configured on the Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other information of interest such as DNS, etc. B. The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6 address from the DHCPv6 server. In this case, the DHCPv6 server would be located in the SP core network, and the Edge Router would simply act as a DHCP Relay Agent. This option is similar
to what is done today in case of DHCPv4. It is important to note that host implementation of stateful auto-configuration is rather limited at this time, and this should be considered if choosing this address assignment option. When a customer WLAN Router is present, the WLAN Host has two possible options as well for acquiring IPv6 address. A. The WLAN Router may be assigned a prefix between /48 and /64 [RFC3177] depending on the SP policy and customer requirements. If the WLAN Router has multiple networks connected to its interfaces, the network administrator will have to configure the /64 prefixes to the WLAN Router interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration. B. The WLAN Router can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. In this option, the WLAN Router would act as a requesting router and the Edge Router would act as a delegating router. Once the prefix is received by the WLAN Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration. The uplink to the ISP network is configured with a /64 prefix as well. Usually it is easier for the SPs to stay with the DHCP-PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations, etc. Using this model, the SP could change prefixes on the fly, and the WLAN Router would simply pull the newest prefix based on the valid/ preferred lifetime. The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
Section 8.1.1. Figure 8.1.2 describes the WLAN architecture when the Access Router is located between the AP and Edge Router. Customer | Access Provider | Service Provider Premise | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | | Provider | |Edge | |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Router| ---- | | | | | | | |Network +------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA | |Server| +------+ Figure 8.1.2
RFC3315] for IPv6 prefix assignments to the WLAN Host/Router. There is no use of DHCP PD or stateless auto-configuration in this option. The DHCPv6 server can be located on the Access Router, the Edge Router, or somewhere in the SP network. In this case, depending on where the DHCPv6 server is located, the Access Router or the Edge Router would relay the DHCPv6 requests. C. It can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. In this option, the Access Router would act as a requesting router, and the Edge Router would act as a delegating router. Once the prefix is received by the Access Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Host/ Router on the customer site. The WLAN Host/Router connected to these interfaces can automatically configure itself using stateless auto-configuration. The uplink to the ISP network is configured with a /64 prefix as well. It is easier for the SPs to stay with the DHCP PD and stateless auto- configuration model and point the clients to a central server for DNS/domain information, proxy configurations, and others. Using this model, the provider could change prefixes on the fly, and the Access Router would simply pull the newest prefix based on the valid/ preferred lifetime.
As mentioned before, the prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows the maximum summarization possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6. Sections 6.2.2 and 6.2.3, respectively, can also be deployed in IPv6 WLAN environment. Figure 220.127.116.11 describes the PTA Model in IPv6 WLAN environment.
Customer | Access Provider | Service Provider Premise | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | | Provider | |Edge | |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Router| ---- | | | | | | | |Network +------+ +--+ +--------------+ +----------+ +------+ | |---------------------------| +------+ PPP |AAA | |Server| +------+ Figure 18.104.22.168 Section 22.214.171.124 apply to the IPv6 WLAN PTA scenario as well. Section 126.96.36.199 apply to the IPv6 WLAN PTA scenario as well. Figure 188.8.131.52 describes the LAA Model in IPv6 WLAN environment.
Customer | Access Provider | Service Provider Premise | | +------+ +--+ +--------------+ +----------+ +------+ |WLAN | ---- | | | | | Provider | |Edge | |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Router| ---- | | | | | | | |Network +------+ +--+ +--------------+ +----------+ +------+ | |-------------------------------------------------- | PPP | |--------------------- | L2TPv2 | +------+ |AAA | |Server| +------+ Figure 184.108.40.206 Section 220.127.116.11 apply to the IPv6 WLAN LAA scenario as well. Section 18.104.22.168 apply to the IPv6 WLAN LAA scenario as well.
It is important to note that in the shared wireless environments, multicast can have a significant bandwidth impact. For this reason, the bandwidth allocated to multicast traffic should be limited and fixed, based on the overall capacity of the wireless specification used in 802.11a, 802.11b, or 802.11g. The IPv6 WLAN Hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If WLAN/Access Routers are used, then they have to be enabled to support MLDv1 and MLDv2 in order to process the requests of the IPv6 WLAN Hosts. The WLAN/ Access Router also needs to be enabled to support PIM-SSM in order to send PIM joins up to the Edge Router. When enabling this functionality on a WLAN/Access Router, its limited resources should be taken into consideration. Another option would be for the WLAN/ Access Router to support MLD proxy routing. The Edge Router has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from the IPv6 WLAN Host or WLAN/Access Router (if present). The Edge Router has also needs to be enabled for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ Access Router (if present), and send joins towards the SP core. MLD authentication, authorization, and accounting are usually configured on the Edge Router in order to enable the SP to do billing for the content services provided. Further investigation should be made in finding alternative mechanisms that would support these functions. Concerns have been raised in the past related to running IPv6 multicast over WLAN links. Potentially these are the same kind of issues when running any Layer 3 protocol over a WLAN link that has a high loss-to-signal ratio, where certain frames that are multicast based are dropped when settings are not adjusted properly. For instance, this behavior is similar to an IGMP host membership report, when done on a WLAN link with a high loss-to-signal ratio and high interference. This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast. While deploying WLAN (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. These problems are usually caused when the AP is placed too far (not following the distance limitations), high interference, etc. These issues may impact a real multicast application such as streaming video or basic operation of IPv6 if the frames were dropped. Basic IPv6 communications uses functions such as Duplicate Address Detection (DAD), Router and Neighbor
Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA), etc., which could be impacted by the above mentioned issues as these frames are Layer 2 Ethernet multicast frames. Please refer to Section 6.3 for more IPv6 multicast details. RFC3041] for auto-configuration should be used by the hosts with the same consideration for host traceability as described in Section 6.5. IPv6 firewall functions should be enabled on the WLAN Host/Router, if present. The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from outside its network. Such services do not apply at the access level of the network discussed here.
If the host authentication at hotspots is done using a web-based authentication system, then the level of security would depend on the particular implementation. User credentials should never be sent as clear text via HTTP. Secure HTTP (HTTPS) should be used between the web browser and authentication server. The authentication server could use RADIUS and LDAP services at the back end. Authentication is an important aspect of securing WLAN networks prior to implementing Layer 3 security policies. For example, this would help avoid threats to the ND or stateless auto-configuration processes. 802.1x [IEEE8021X] provides the means to secure the network access; however, the many types of EAP (PEAP, EAP-TLS, EAP- TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to support some of the features might make it difficult to implement a comprehensive and consistent policy. The 802.11i [IEEE80211i] amendment has many components, the most obvious of which are the two new data-confidentiality protocols, Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system to control access to the network. Because 802.11 handles unicast and broadcast traffic differently, each traffic type has different security concerns. With several data-confidentiality protocols and the key distribution, 802.11i includes a negotiation process for selecting the correct confidentiality protocol and key system for each traffic type. Other features introduced include key caching and pre-authentication. The 802.11i amendment is a step forward in wireless security. The amendment adds stronger encryption, authentication, and key management strategies that could make wireless data and systems more secure. If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD). The device that is the Layer 3 next hop for the subscribers (Access or Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security]. The Access and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: RS, NS, and MLD Requests. Rate limiting should be implemented on all
subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
PLC/BPL could also be used in the medium voltage network (often configured as Metropolitan Area Networks), but this is also out of the scope of this document, as it will be part of the core network, not the access one. Figure 9.1 depicts all the network elements indicated above. Customer Premise | Network Access Provider | Network Service Provider +-----+ +------+ +-----+ +------+ +--------+ |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP +-----+ +------+ +-----+ | End | | Router +=>Network +--+---+ +--------+ +-----+ +------+ +-----+ | |Hosts|--| BCPE |--| RPT |-----------+ +-----+ +------+ +-----+ Figure 9.1
The logical topology and design of PLC/BPL is very similar to Ethernet Broadband Networks as discussed in Section 7. IP connectivity is typically provided in a Point-to-Point model, as described in Section 7.2.1
followed by a request via DHCP-PD for a prefix shorter than /64 (typically /48 [RFC3177]) that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. This should be the preferred provisioning method, being cheaper and easier to manage. The Edge Router needs to have a prefix, considering that each customer in general will receive a /48 prefix, and that each HE will accommodate customers. Consequently, each HE will require n x /48 prefixes. It could be possible to use a kind of Hierarchical Prefix Delegation to automatically provision the required prefixes and fully auto- configure the HEs, and consequently reduce the network setup, operation, and maintenance cost. The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
Section 7.6. Note that there may be a need to define MIB modules for PLC networks and interfaces, but this is not necessarily related to IPv6 management. section 5, changes will need to be made to the DOCSIS specification in order for SPs to deploy native IPv6 over cable networks. The CM and CMTS will both need to support IPv6 natively in order to forward IPv6 unicast and multicast traffic. This is required for IPv6 Neighbor Discovery to work over DOCSIS cable networks. Additional classifiers need to be added to the DOCSIS specification in order to classify IPv6 traffic at the CM and CMTS in order to provide QoS. These issues are addressed in a recent proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS3.0-Reqs].
B. Section 6 stated that current RBE-based IPv4 deployment might not be the best approach for IPv6, where the addressing space available gives the SP the opportunity to separate the users on different subnets. The differences between IPv4 RBE and IPv6 RBE were highlighted in Section 6. If, however, support and reason are found for a deployment similar to IPv4 RBE, then the environment becomes NBMA and the new feature should observe RFC2491 recommendations. C. Section 6 discussed the constraints imposed on an LAA-based IPv6 deployment by the fact that it is expected that the subscribers keep their assigned prefix, regardless of LNS. A deployment approach was proposed that would maintain the addressing schemes contiguous and offers prefix summarization opportunities. The topic could be further investigated for other solutions or improvements. D. Sections 6 and 7 pointed out the limitations (previously documented in [IPv6-Multicast]) in deploying inter-domain ASM; however, SSM-based services seem more likely at this time. For such SSM-based services of content delivery (video or audio), mechanisms are needed to facilitate the billing and management of listeners. The currently available feature of MLD AAA is suggested; however, other methods or mechanisms might be developed and proposed. E. In relation to Section 8, concerns have been raised related to running IPv6 multicast over WLAN links. Potentially, these are the same kind of issues when running any Layer 3 protocol over a WLAN link that has a high loss-to-signal ratio; certain frames that are multicast based are dropped when settings are not adjusted properly. For instance this behavior is similar to an IGMP host membership report, when done on a WLAN link with high loss-to-signal ratio and high interference. This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast. F. The privacy extensions were mentioned as a popular means to provide some form of host security. ISPs can track relatively easily the prefixes assigned to subscribers. If, however, the ISPs are required by regulations to track their users at host address level, the privacy extensions [RFC3041] can be implemented only in parallel with network management tools that could provide traceability of the hosts. Mechanisms should be defined to implement this aspect of user management.
G. Tunnels are an effective way to avoid deployment dependencies on the IPv6 support on platforms that are out of the SP control (GWRs or CPEs) or over technologies that did not standardize the IPv6 support yet (cable). They can be used in the following ways: i. Tunnels directly to the CPE or GWR with public or private IPv4 addresses. ii. Tunnels directly to hosts with public or private IPv4 addresses. Recommendations on the exact tunneling mechanisms that can/should be used for last-mile access need to be investigated further and should be addressed by the IETF Softwire Working Group. H. Through its larger address space, IPv6 allows SPs to assign fixed, globally routable prefixes to the links connecting each subscriber. This approach changes the provisioning methodologies that were used for IPv4. Static configuration of the IPv6 addresses for all these links on the Edge Routers or Access Routers might not be a scalable option. New provisioning mechanisms or features might need to be developed in order to deal with this issue, such as automatic mapping of VLAN IDs/PVCs (or other customer-specific information) to IPv6 prefixes. I. New deployment models are emerging for the Layer 2 portion of the NAP where individual VLANs are not dedicated to each subscriber. This approach allows Layer 2 switches to aggregate more then 4096 users. MAC Forced Forwarding [RFC4562] is an example of such an implementation, where a broadcast domain is turned into an NBMA- like environment by forwarding the frames based on both Source and Destination MAC addresses. Since these models are being adopted by the field, the implications of deploying IPv6 in such environments need to be further investigated. J. The deployment of IPv6 in continuously evolving access service models raises some issues that may need further investigation. Examples of such topics are [AUTO-CONFIG]: i. Network Service Selection & Authentication (NSSA) mechanisms working in association with stateless auto-configuration. As an example, NSSA relevant information, such as ISP preference, passwords, or profile ID, can be sent by hosts with the RS [RFC4191].
ii. Providing additional information in Router Advertisements to help access nodes with prefix selection in multi-ISP/ multi-homed environments. Solutions to some of these topics range from making a media access capable of supporting native IPv6 (cable) to improving operational aspects of native IPv6 deployments. ISP-CASES]. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. [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. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [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. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands across IPv4 Clouds with BGP", Work in Progress, December 2006. [AUTO-CONFIG] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of IPv6 stateless auto-configuration in access network", 8th International Conference on Telecommunications, ConTEL 2005, June 2005.
[BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006. [DOCSIS3.0-OSSI] CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM- SP-OSSIv3.0-D02-060504)", May 2006. [DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F. Mule, "DOCSIS 3.0 Requirements for IPv6 Support", Work in Progress, March 2006. [DynamicTunnel] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005. [IEEE80211i] IEEE, "IEEE Standards for Information Technology: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 6: Medium Access Control (MAC) Security Enhancements", July 2004. [IEEE8021X] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001", June 2001. [IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, April 2004. [IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", March 2004. [ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2005. [ISP-CASES] Mickles, C., "Transition Scenarios for ISP Networks", Work in Progress, September 2002. [Protocol41] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol 41 in NAT Boxes", Work in Progress, October 2003. [RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10- 051209)", 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.
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas, Madrid E-28108 Spain Phone: +34 91 151 81 99 EMail: email@example.com
Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.