5.11.2 802.16E and Wimax Support for Ipv6
Total Page：16
File Type：pdf, Size：1020Kb
Project WiMAX Forum Network Working Group
Title IPv6 operation with the PtP link model
Number and 060915_NWG_Stage2_Figure 7_6.doc File Name
Company name(s) – in alphabetical order mailto: [email protected], [email protected], Source(s) Huawei, Nokia, Samsung [email protected]
Membership Are all proposing organizations members of the WiMAX Forum? Yes [X ] No [ ]
Re: IPv6 updates to stage 3 based on the consensus to adopt the point-to-point link model.
Rational Changes to IPv6 operation based on each MS being allocated a unique prefix.
Current Text Section Sec 5.11.3 Number
This document is submitted to the WiMAX Forum as a basis for discussion and is not binding on the contributing Notice individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Each contributor grants a free, irrevocable license to the WiMAX Forum to incorporate material contained in this contribution, and any modifications thereof, in the creation of a WiMAX Forum publication and at the WiMAX Forum’s sole discretion to permit others to reproduce in whole or in part the resulting WIMAX Forum publication. Release The contributor also acknowledges and accepts that this contribution may be made public by WiMAX Forum. Complete IPR and copyright rules governing contributions submitted to the WiMAX Forum are available from the WiMAX Forum administrator.
1 11.1 IPv6
2 5.11.1 Introduction 3[JH] This is copied from ver04 4 5This section describes the operation of IPv6 over the IPv6 convergence sub-layer based on IETFs IPv6 RFCs. IPv6 6in the case of IPv6 CS in WiMAX runs directly over the MAC layer. The behavior of hosts and the network 7elements including the base station and the ASN GW/AR referred to as AR hereafter are explained in this section.
8 5.11.2 802.16e and WiMAX Support for IPv6 9[JH] This is copied from ver04 10 11IEEE has defined several convergence sub-layers for 802.16e. IP and Ethernet are the most relevant ones for running 12IPv6 over the .16 link. WiMAX has specified IP as the mandatory convergence sub-layer. IPv4 and IPv6 have a 13corresponding IP CS over the MAC layer. While IPv6 can be operated over the IPv6 CS, it SHOULD be noted that 14IPv6 can also be operated over the Ethernet convergence sub-layer as well. IPv6 over IPv6 CS and Ethernet CS are 15both described in the following sections. 16The .16 air interface is akin to any other wireless link and transmission of IP over it is rudimentary. However some 17considerations about the link model need to be accounted for and optimized accordingly. .16e itself does not have 18any special characteristics that supports IPv6. The 802.16e link is designed for supporting IP traffic in an optimal 19manner. 20802.16e has specified several convergence sublayers for supporting IPv6. IPv6 can be operated over eiher the IPv6 21convergence sublayer (CS) or can be operated over Ethernet which sits above the Ethernet CS. The frame structure 22of IPv6/Ethernet CS is specified in [Ref1]
231.1.1 Functional Model 24[JH] This is copied from ver04 25 26The IPv6 capable MS is connected via the BS to an IPv6 access router (AR). The IPv6 access router functionality 27exists either in the ASN GW in the case of profiles A and C, and as an integral part of the ASN in the case of profile 28B. This access router acts as the first hop router from the perspective of the MS. The model is illustrated in Figure 295-1:
1 R1
1
IPv6 BS AR ASN-GW 1 MS R6 R3 R1
Profiles A and C ASN
IPv6 BS AR ASN-GW MS R6 R3 ASN R1
Profiles A and C ASN
IPv6 BS MS AR R3 R1 ASN Profile B
IPv6 BS MS AR R3 R1 ASN Profile B
IPv6
IPv6 BS AR ASN-GW MS R6 R3 R1
Profiles A and C ASN
IPv6
IPv6 BS MS AR R3 R1 ASN Profile B 2
3 Figure 5-1 – IPv6 Model 4 5In the figure above the MS is attached at the IP layer to the IPv6 access router in the ASN GW. IPv6 packets 6between the BS and ASN GW are transported over a tunneled interface, refered to as the R6 reference point in the 7architecture. This is applicable in the case of Profiles A and C. In the case of Profile B, the MS is attached at the IP 8layer to an IPv6 access router which is a functional entity within the scope of an ASN.
91.1.2 IPv6 link model 10[JH] I re-wrote this. I defined the link following 3GPP case in RFC 3314. Kindly check whther the link definition is 11ok. I’ll go over the section one more time tomorrow. 12 1
1RFC 2461 defines link as a communication facility or medium over which nodes can communicate at the link layer, 2i.e., the layer immediately below IP. Usually a link is bounded by routers that decrement TTL. When an MS moves 3within a link, it can keep using its IP addresses. This is a layer 3 definition and note that the definition is not 4identical with the definition of the term '(L2) link' in IEEE 802 standards. This section presents a model for the last 5mile link, i.e. the link to which MSs attach themselves by describing the characteristics of Access Router, On-link 6neighbor and Prefix assignment. 7 8For IPv6 operation, we recommend point-to-point link model, i.e. 'per MS prefix model' following the 3GPP 9precedent in RFC 3314 [Refy]. In WiMAX, there exists a connection (service flow) between an MS and the AR via 10a BS, over which packets are transferred. 11 12'per MS prefix model' defines the collection of all service flows (transport connections) to thea same MS as a single 13link. AR should treat the collection of service flows to each MS as a separate virtual link and manage a virtual 14interface for each virtual link. 15 16Each link has only an MS and an AR. Each MS belongs to a different link. No two MSs belong to the same link. A 17different prefix should be assigned to a different link. This link is fully consistent with a standard IP link, without 18exception and conforms with t. The definition of ais as a point-to-point link inas of RFC 2461。 19
201.1.2.1 On-link neighbor 21In any link, there are only an MS and an AR. On link neighbor of an MS is always an A R. Link-scope multicast is 22also supported. 23
241.1.2.2 IPv6 prefix 25[JH] This section may need further details. I’ll go over the section one more time tomorrow 26 27In this model, each link between an MS and the AR is allocated a separate, unique 64-bit prefix or unique set of 28prefixes by the AR. No two MSs share the same prefix. Bear in mind that a prefix is assigned not to an MS but to the 29link between the MS and the AR. ARSN GW notifies an assigned prefix by sending the prefix in a Router 30Advertisement (RA) message. 31 32An AR should manage the pool of prefixes and assign an unique prefix or an unique set of prefixes for each MS. An 33AR should keep track of a prefix or a set of prefixes per an MS and advertise an MS its prefixes accordingly. If an 34MS sends an RS, the AR should reply an RA with a prefix that is assigned for the soliciting MS (precisely speaking 35a prefix that is assigned on the link to which the soliciting MS belongs). When an MS moves within an AR and 36makes a new attachment, the AR recognizes its previous attachment and advertise the MS's existing prefix. 37 38We recommend the aggregation of prefixes. AR may get a 48-bit prefix and allocate 64-bit sub prefixes to MSs. 39
401.1.3 Transport connection for configuring the host 41[Raj] Explain the establishment of the ISF as is in the current section. Add details about the granularity of the GRE 42tunnel between the BS and the ASN-GW/AR. 43[JH] This is copied from ver04. I didn’t mention the granulity because I don’t know whether to put that. 1
1The mobile station performs initial network entry as described in [Reference to network entry procedure in section 25.5]. The subscriber profile is downloaded to the ASN as part of the succesful completion of the network entry 3procedure. 4On completion of the network entry procedure, the the initial service flow (ISF) for IPv6 CS is established by the 5network. The ISF establishment procedure is described in [Reference to ISF in QoS section]. The trigger or decision 6to establish the IPv6 ISF is based on the subscribers profile and controlled by the SFA in the ASN. 7The establishment of the ISF enables the sending and receiving of IPv6 packets between the MS and the access 8router in the ASN over IPv6 CS. On completion of the establishment of the ISF, router advertisements and address 9assignment procedures are initiated.
101.1.3.1 Anchor Data Path Function 11[Raj]As explained in the current document. Add further details if needed. 12[JH] This is copied from ver04. 13The ISF triggers the creation of the Anchor data path function at the Access router (AR). The Anchor DPF is 14responsible for buffering IPv6 packets destined to an MS when the MS is in idle mode. The Anchor DPF interacts 15with the Anchor paging controller function (APCF) as described in [Ref Paging section].
161.1.4 Router Discovery 17[Raj]Utilize current text keeping in mind the PtP link model. 18[JH] I rearranged the sections but contents are just copied from ver04. The section needs further detail w.r.t. p2p link 19model. I’ll update this tomorrow. 20 21Router Discovery defines how an MS locates the routers that reside on an attached link. After attaching to a new BS, 22an MS needs to establish an initial transport connection that can be used for IP signaling such as RS/ RA and NS/ 23NA messages. 24An MS MAY send an RS (Router Solicitation) message to solicit an RA (Router Advertisement) message from 25ASN to acquire necessary information as specified in RFC 2461. Upon receiving an RS message, the ARASN MAY 26reply an RA to the soliciting MS. Because only one ARSN-GW receives the RS, the RA can be sent without any 27random delay. 28ARSN MAY send unsolicited RAs periodically as specified in RFC 2461 or immediately after the initial transport 29connection has been established as specified in FRD (Fast Router Discovery) below to speed up Router Discovery.
301.1.4.1 Scenario1: When an MS attaches to a new BS
311.1.4.1.1 FRD
MS BS AR
1. Network Entry and Network Authentication
2. Transport Connection Establishment
ISF
3. Router Advertisement
32
33 Figure 5-11 -2 Router Discovery using FRD 1
1 1) An MS makes a registration to ARSN according to 802.16e/ WiMAX procedure. 2 2) The MS establishes the initial service flow for the host configuration. 3 3) The establishment of the initial service flow triggers the IPv6 AR in the ASN to send an unsolicited RA to 4 the MS
51.1.4.1.2 RS/ RA Exchange 6As explained in the current document. Add further details if needed.
MS BS AR
1. Network Entry and Network Authentication
2. Transport Connection Establishment
3. Router Solicitation 4. Router Advertisement ISF 7
8 Figure 5-11-3Router discovery using RS/RA exchange 9 4) An MS performs registration to an ARSN according to 802.16e/ WiMAX procedures. 10 5) The MS establishes the initial service flow which is used for the host configuration. 11 6) The MS sends an RS (Router Solicitation) with the destination address set to the all-routers multicast 12 address and unspecified address as the source address via the transport connection established in Step2. The 13 RS is delivered to the IPv6 AR in the ASN as a unicast message. Even though the destination address is set 14 to the all-routers multicast address, the combination of the transport connection and the ISF creates a point 15 to point connection between the MS and the AR and hence the RS is delivered as a unicast message. 16 7) The ASN responds with an RA with all-nodes multicast address set as the destination IP address and the AR 17 link local address as the source address via the ISF/transport connection established in Step 2. The RA is 18 delivered only to the MS with which the ISF is associated. It should be noted that the AR sends the RA to 19 the all-nodes multicast address. But the RA is delivered via the data-path associated with the ISF and links 20 it to a single MS. The RA is not delivered to every MS that has a link with the AR. The AR has to deliver 21 the RA to the DPF from which the RS was received which ensures that the RA is delivered only to the MS 22 that sent the RS. 23
241.1.4.2 Scenario2: When an MS remains at the current BS
251.1.4.2.1 Periodic Unsolicited RA 26An ARASN MAY send unsolicited RAs periodically as specified in RFC2461 to facilitate the interoperation with 27the standard abiding MSs. However even the periodic unsolicited RAs are recommended to be delivered in unicast. 28The period between these Router Advertisements can be increased to a suitable value comparable to (less than) 29router lifetime to reduce the overhead on the air interface. The current MaxRtrAdvInterval as defined in RFC2461 30has a Max value of 1800 seconds and a default of 600 seconds. The Max value of 1800 seconds may need to be 31configured to a greater value in a WiMAX environment and a change to the Max value requested to be made in 32RFC2461.
331.1.4.2.2 RS/ RA Exchange 34A mobile station that is attached to an AR and is aware of the AR’s unicast address may send router solicitations 35randomly or intermittently. The figure below shows such a scenario: 1
MS BS ASN
1. Router Solicitation
2. Router Advertisement
ISF 1
2 Figure 5-11-4 Random or intermittent RS/RA exchange 3 8) An MS sends an RS with the AR’s IP address as destination address and the MS address as source address. 4 9) The AR in ASN receives the RS and replies an RA with the MS address as destination address and ARSN- 5 GW address as source address 6
71.1.4.3 Router Advertisement Content 8Each MS belongs to a different link. ASN GW should send different MSs different RAs accordingly. Especially 9different prefixes should be advertised for different MSs. 10RFC 2461 allows an AR to omit some information from an RA at its own discretion. For example, an AR MAY 11advertise an RA without any prefix included. However, it is recommended that any RA, whether solicited or 12unsolicited, SHOULD NOT omit some options such as PIO (Prefix Information Option) and contain all the 13information. L- and A-bits of PIO should be set to force the stateless address autoconfiguration at the MS.
141.1.4.4 Upstream Route Advertisement 15In per-MS prefix model, AR advertises /64 prefixes obtained from a /48 or /32 prefix. AR MUST advertise /48 or / 1632 route upstream in order to achieve the route aggregation. 17
181.1.5 Address resolution 19[Raj] Explain that there is no address conflict in a PtP link model. However DAD still needs to be performed and 20supported. 21[JH] I combined the section from ver04 and Behcet’s writing. . 22 23Address resolution is the process by which an IPv6 node determines the link-layer address of an on-link destination 24(e.g., a neighbor) given only the destination's IP address. In case of IPv6 CS, the MAC address is not used for 25delivering the frames; hence the address resolution is not needed. 26However an MS implemented as per the IPv6 specification may perform address resolution. Even in such cases, 27address resolution is only needed between an ARSN GW and an MS and performed as of RFC 2461. 28An intelligent/future implementation MAY choose not to do the address resolution if the access technology is 29802.16 with IPv6 CS. 30In the per-MS subnet prefix model, there normally is no address conflict. However duplicate address detection 31(DAD) still needs to be performed. AR and MS create their respective link local addresses and perform DAD within 32the link independently. 1
11.1.6 Next Hop 2[JH] This is copied from ver04. 3 4Next-hop determination is a process for mapping an IP destination address into the IP address of the neighbor to 5which traffic for the destination SHOULD be sent. In WiMAX Architecture, the next hop for an MS is always an 6ARSN. 7An intelligent/future implementation MAY choose not to do the next-hop determination if the access technology is 8802.16 by preventing such packets from being sent by the host.
91.1.7 NUD 10[JH] This is copied from ver04. 11 12An MS may lose communication link with another corresponding host or to its access router at any time. If a path 13has failed, it is possible to recover from such a failure. RFC2461 specifies neighbor unreachability detection (NUD) 14that is applicable to hosts and routers. NUD is used to test the path between hosts, between host s and router and, 15between routers and hosts. Router-to-router communication path is not considered here. 16In the case of WiMAX the MS and BS are aware of the link state over the 802.16 air interface. When the MS is in 17Idle mode, the data path between the BS and ARSN-GW/access router is torn down. Paging is used to wake an Idle 18mode MS and establish a data path before packets destined to an MS can be delivered. Hence NUD at the IP layer is 19not always required. A host may however perform NUD. But if an MS is in Idle mode, NUD becomes a suboptimal 20operation. A WiMAX-link aware host may be designed to avoid NUD. But for regular IPv6 hosts such as laptops 21with data cards NUD SHOULDshould be supported.
221.1.8 Path MTU 23[JH] This is copied from ver04. 24 25RFC2460 specifies that every link in the Internet has an MTU of 1280 octets or greater. When IPv6 is run over 26Ethernet the MTU is set to 1500 octets. This is generally viewed as the optimal MTU for a host given the link types 27in the core network. 28The MTU at the link layer for 802.16/e is specified as 1522 octets [Ref1]. Hence the IPv6 MTU should be less than 29the link MTU. MTU setting is important in order to avoid fragmentation of packets. When an MS sends an IPv6 30packet over IPv6 CS, the packet is carried over the R1 reference point. The packet size at the IPv6 CS is the size of 31the IPv6 packet and the 6 octet MAC header. The MAC header is stripped at the BS and the IPv6 packet is sent to 32the access router via the R6 tunnel in the case of Profiles A and C and delivered to the access router function in the 33case of profile B. When the IPv6 packet is transported over R6, it is encapsulated with a GRE header and carried 34over IPv4. Hence MTU at the MS and access router need to consider the overhead of the R6 and R4 tunnels. In 35order to avoid fragmentation in various scenarios such as IPsec in tunnel mode and others, the recommendation for 36default MTU is 1400 octets at the MS. The recommendation for default MTU size is 1280 octets at the MS if GRE is 37carried over IPv6 [reft]. Note that this is a configurable parameter and operators may choose to override the default 38MTU based on network configuration and link types. 39RFC2461 also recommends that IPv6 nodes implement Path MTU discovery. WiMAXThe hosts can learn the SDU 40size from the BS using DSA-REQ/RSP messages where TLV 16 identifies the SDU size. This value SHOULD be 41used as the MTU size.
421.1.9 IPv6 Addressing for hosts 43[Raj] Simplify this section as a result of the PtP link model. Complete all the subsections for this. 44[JH] I rewrote the section which has become much simplified. Kindly check. 45 1
1The addressing scheme for IPv6 hosts in WiMAX follows the IETFs recommendation for hosts specified in RFC 22494. The IPv6 node requirements RFC specifies a set of RFCs that are applicable for addressing. These include: 3 The IPv6 Addressing Architecture – RFC3513 (Updated by RFC3879) 4 IPv6 stateless address autoconfiguration - RFC2462 5 Privacy Extensions for Address Configuration in IPv6 - RFC 3041 6 Default Address Selection for IPv6 - RFC 3484 7 Stateful Address Autoconfiguration - DHCPv6, RFC-3315 8The node requirements RFC (2494) specifies which of the above addressing related RFCs are mandatory to 9implement and which are optional.
101.1.9.1 Interface Identifier (IID) 11The MS has a 48-bit MAC address as specified in [Ref1]. This MAC address is used to generate the 64 bit interface 12identifier which is used by the MS for address autoconfiguration. The IID is generated by the MS as specified in 13RFC2464. 14IPv6 address is formed by adding an Interface Identifier (IID) to the prefix learnt from Router Advertisement. The 15IID forms the least significant bits of the IPv6 address as shown below
IPv6 Prefix (64 bits) Interface Identifier (64 bits) 16
17 Figure 5-11-Error! No text of specified style in document.-5 IPv6 address format 18The length of the IID is fixed and must be 64-bits for all nodes in the WIMAX Network. 19The IID for 802.16 interfaces is based on the EUI-64 identifier derived from the interface's built-in 48-bit MAC 20address. EUI-64 bit identifier is formed by inserting 0xFFFE in the MAC address between the company ID (first 24 21bits) and the manufacturer selected extension ID (last 24 bits). The IID is then formed from the EUI-64 by inverting 22the universal/local (u/l) bit. This is the 7th bit of the most significant octet. Inverting this bit will generally change a 230 value to a 1 meaning globally unique IPv6 IID.
cccccc00 cccccccc cccccccc Extension ID (24-bit) 48-bit MAC Address
cccccc00 cccccccc cccccccc 0xFF 0xFE Extension ID (24-bit) 64-bit EUI Address
cccccc10 cccccccc cccccccc 0xFF 0xFE Extension ID (24-bit) 64-bit IPv6 IID 24
25 Figure 5-11-Error! No text of specified style in document.-6 Illustration of forming the IID 26For addresses that are based on privacy extensions, the MS may generate random IIDs as specified in RFC3041.
271.1.9.2 Duplicate Address Detection (DAD) 28DAD is performed as perof RFC 2461, 2462. 1
11.1.9.3 Stateless address auto-configuration 2If L- and A-bits in PIO are set and M-flag not set MS performs sStateless address auto-configuration is performed as 3perof RFC 2461, 2462. The access router in the ASN is the default router that advertises a prefix that is used by the 4MS to configure an address.
51.1.9.4 Stateful address auto-configuration 6If the M-flag is set in the RA message from the access router to the MS, the MS MAY perform, stateful address 7configuration. If the M-flag is set, A bit in the Prefix Information Option MUST not be set. For this purpose, the MS 8SHALL use DHCPv6 procedures as defined in RFC 3315. The MS SHALL send the DHCP request message to the 9all-nodes DHCP server or all-nodes DHCP relay addresses. The ARSN-GW/ASN acts as the DHCP-server (proxy) 10or DHCP-relay to assist the MS to acquire an IPv6 address in a stateful manner. If acting as a relay, the A RSN-GW 11SHALL follow the relay procedures defined in RFC3315. 12 13If DHCP is used for address configiguration ('M=1' in the Router Advertisement), the DHCP server must provide 14addresses with a separate prefix per mobile node. The prefix must of course match whatever prefix the ARSN 15Gateway has advertised to the mobile node (if any).
161.1.10 DNS Discovery 17[JH] This is copied from ver04. 18 19In order to be able to use the Dynamic Name Service (DNS), the MS has to be configured with the IPv6 DNS server 20addresses. Currently there are two mechanisms in use in the Internet for dynamically configuring the DNS server 21addresses: Using well-known addresses for the IPv6 DNS servers and dynamically configuring the DNS server 22addresses via Dynamic Host Configuration Protocol (DHCP) for IPv6 using DNS Configuration options [RefzX,Y]. 23Choosing the right DNS Server configuration method is dependent on the address allocation mechanisms. If stateful, 24DHCP-based, address auto-configuration is used; the DHCPv6 DNS Configuration options SHALL be used. 25However, ifwhen using stateless address auto-configuration is used, well-known addresses, or stateless DHCPv6 26[RefuZ] SHALL be used. 27The DNS Server address SHALL be from the same network as the MS’es IP address. The information for the DNS 28Configuration Options is set to the DHCP proxy with the AAA procedures as described in the section [the spec and 29the section number where the stage 3 AAA procedures are] I do not understand this sentence and could not fix it:
301.1.10.1 Well Known Addresses for DNS Server Discovery 31[JH] This is copied from ver04. I remember V&V comments on this. We may need to change. 32 33An MS that uses IPv6 DNS Server discovery SHALL use the following three addresses as the primary DNS server 34address, and the secondary addresses respectively. 35 fec0:0000:0000:ffff::1, 36 fec0:0000:0000:ffff::2 37 fec0:0000:0000:ffff::3 38An MS using well-known addresses SHALL send the DNS queries to one of these addresses. 39MS MAY support well-known addresses. The network SHALL support well-known addresses.
401.1.10.2 DHCPv6 DNS configuration options 41[JH] This is copied from ver04. I remember V&V comments on this. We may need to change. 42 1
1The DHCPv6 DNS configuration options are defined in [RefzY]. The DNS recursive name server options SHALL 2be populated by the network’s name server addresses. In addition, the Domain search list option MAY be present 3and populated with the network’s search list. 4The MS MAY use DHCPv6 DNS Configuration Options [RefzY] – either with DHCPv6 [RefwX] when stateful 5address configuration is used, or Stateless DHCPv6 [RefuZ] when stateless address auto-configuration is used. 6The network SHALL support DHCPv6 [RefwX] and DHCPv6 DNS Configuration Options [RefzY] when stateful 7address auto-configuration, is used. The network SHALL support stateless DHCPv6 [RefuZ] with the DNS 8Configuration options [RefzY] when stateless address auto-configuration is used.
91.1.10.3 RA Option 10[JH] This is copied from ver04. I remember V&V comments on this. We may need to change. 11 12The RA option for DNS discovery is described in RFC4339.
131.1.11 ICMPv6 14[JH] This is copied from ver04. 15 16ICMPvV6 MUST be implemented as specified in RFC4443.
171.1.12 IP Security (IPSec) 18[JH] This is copied from ver04. 19 20IPsec is an integral part of the IPv6 stack on hosts. IPsec is also commonly used for VPNs and other applications. 21IKEv2 should also be supported as per RFC 4306. Security for mobile stations should be supported as specified in 22RFC4294.
231.1.13 Uplink and downlinkg transmission of IPv6 packets 24[JH] This is copied from ver04. 25
261.1.13.1 Uplink 27IPv6 packets can be sent by the MS over IPv6 CS via a transport connection that maps to either the Initial service 28flow or to another pre-provisiioned service flow in the ASN. The MS sends IPv6 packets that are carried over a 29transport connection identified by a connection Identifier (CID). The IPv6 CS at the BS receives the IPv6 packet. 30Based on the CID that the packet was received on, the BS has a mapping to a service flow which maps to a Data 31Path ID (GRE key). The BS uses the Data path ID (GRE key) to send the packet to the Access router (AR) via the 32GRE tunnel (R6) when the BS and Access router are separated (Profiles A and C). In the case of Profile B, the BS 33forwards the IPv6 packet to the AR.
341.1.13.2 Downlink 35When a packet destined for an MS arrives at the ASN GW/AR, the ASN GW/AR looks at the IPv6 packet header 36and/or flow ID to determine the service flow ID (SFID) that this packet needs to be mapped on to. The SFID maps 37to a data path ID. The ASN GW uses the GRE key associated with the data path ID to forward the IPv6 packet via 38the GRE tunnel to the BS in the case when the AR and the BS are separated by the R6 interface (Profiles A and C). 39In the case of Profile B, the AR forwards the packet to the BS in case the BS and AR are not colocated. The BS 40receives the IPv6 packet. The BS may not be able to directly map an IPv6 packet to a transport connection (CID) 41based on just the GRE key when the granularity of the GRE key is not at a per MS or service flow basis . In such 42instances the BS will use the GRE key as well as the tuples in the IPv6 header to identify the appropriate CID to 1
1send the IPv6 packet on. The BS forwards the IPv6 packet on a transport connection identified by a CID to the 2appropriate MS.
31.1.14 Prefix management at the AR 4[JH] We’d better keep from using the term ‘prefix delegation’ People may be consuded that the prefix is delegated 5to an MS, not assigned on a p2p link. Also I wonder whether we need to include such complicated scheme. It seems 6simpler to just use local pool in ASN GW. 7
81.1.14.1 Using DHCPv6 for Prefix management 9The figure below presents a prefix delegation procedure using DHCPv6.
ASN-GW
DHCP DHCP DHCP MS SFA Auth client relay Server
(1) PKMv2 EAP (2) Auth Success
(3) Solicit
(4)Relay-forward
(5)Relay-Reply (6)Advertise
(7)Request (8)Relay-forward
(9)Relay-Reply (10)Reply (11)Prefix Delegation
(12) ISF Established
(13)Router Advertisement 10
11 Table Using DHCPv6 for Prefix Delegation
Step Description MS performs initial network entry and authentication procedures. as described the previous sections 1
2 Once authentication succeeds, Auth function module notifies DHCP client module. Auth Success message includes some of MS’ information , such as MAC address and so on. 1
Step Description
3 DHCP messages should be relayed if the AR and a DHCP server are not connected directly. The above figure illustrates the scenario that the ARSN-GW and the DHCP Server aren't connected directly. The DHCP Client initiates DHCP procedure with Solicit to request prefixes for the MS. The ARSN-GW creates and transmits a Solicit message as described in sections 17.1.1, "Creation of Solicit Messages" and 17.1.2, transmission of Solicit Messages" of RFC 3315. The ARSN-GW creates an IA_PD and assigns it an IAID. IAID can’t be created based on the MS’ MAC address, and the algorithm is implemention specific. The ARSN-GW MUST include the IA_PD option in the Solicit message 4 The DHCP Server’s IP address should be configured in the ARSN-GW. DHCP Relay module relays the Solicit message to tThe DHCP Server. 5,6 The DHCP server sends an Advertise message to the DHCP Client through DHCP Relay in the same way as described in section 7.2.2, "Creation and transmission of Advertise messages" of RFC 3315. 7,8,9,10 The DHCP Client uses the same message exchanges as described in section 18, "DHCP Client- Initiated configuration Exchange" of RFC 3315 to obtain or update prefixes from a DHCP server. The DHCP Client and the DHCP server use the IA_PD Prefix option to exchange information about prefixes in much the same way as IA Address options are used for assigned addresses. 11 The DHCP Client sends the delegated delegation prefixes to SFA module. 12 ISF is established 13 SFA module advertises the prefixes to MS through RA message. 1 2Prefixes can be released in two ways, prefix aging or DHCP release procedure. In the former way, a prefix 3SHOULD be deleted by the DHCP Client when the prefix ages, and the DHCP Server can delegate it to another 4MS. In the latter way, the ARSN-GW initiates a Release message which is relayed by DHCP Relay to give back 5the prefixes to the DHCP server. The server responds with a Reply message and then the prefixes can be reused 6by other MSs. 7Renumbering can be obtained through Renew Message or Server Initiated Reconfiguration. To extend the valid and 8preferred lifetimes for the prefixes associated with an MS, the MS sends a Renew message to the DHCP server. 9The server determines new lifetimes for the prefixes. The server MAY add new prefixes to the MS for 10renumbering. As for Server Initiated Reconfiguration, DHCP server initiates a configuration message exchange 11with the ASN-GW by sending a Reconfigure message. The reconfigure message triggers the DHCP Client to send 12Renew message.
131.1.14.2 Using Local Prefix Pool 14Just like address allocation a local prefix pool in the ASN-GW can be used for prefix delegation. Compared to the 15above method, some manual configuration should be done, and a prefix delegation algorithm should be designed.
161.1.14.3 Using AAA Servers for Prefix Management 17During network entry, AR as RADIUS (Diameter) client sends Access-Request (AA-Request) message to AAA 18server. AR MAY include Delegated-IPv6-Prefix [Refx] attribute in Access-Request (AA-Request). If MS passes the 19authentication, AAA server SHOULD send Access-Accept (AA-Answer) message with Delegated-IPv6-Prefix 20attribute. The attribute can appear multiple times when RADIUS server assigns multiple prefixes to MS. 21AR releases the prefixes when MS handsoff or switches off by sending Accounting-Request message to AAA server 22with Delegated-IPv6-Prefix carrying the prefix(es) to be released. 23 1
11.1.14.4 Using Local Prefix Pool 2Just like address allocation which is a DHCP server functionality, a local prefix pool in the AR can be used for 3prefix management at the AR. Compared to the above methods, some manual configuration should be done, and a 4prefix allocation/deallocation algorithm should be designed.
5 [Refx] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", September 2006, 6