idnits 2.17.1 draft-jee-16ng-ps-goals-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 6. The solution SHOULD not introduce any new security threats. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2006) is 6633 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0826' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 604, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-05 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jee, Editor 3 Internet-Draft ETRI 4 Expires: August 31, 2006 S. Madanapalli 5 Samsung ISO 6 J. Mandin 7 Runcom 8 G. Montenegro 9 Microsoft 10 S. Park 11 Samsung Electronics 12 M. Riegel 13 Siemens 14 February 27, 2006 16 IP over 802.16 Problem Statements and Goals 17 draft-jee-16ng-ps-goals-00.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 31, 2006. 44 Copyright Notice 46 Copyright (C) The Internet Society (2006). 48 Abstract 50 This draft provides overview of 802.16 Network characteristics and 51 Convergence Sublayers, and specifies the problems in running the IETF 52 IP (both IPv4 and IPv6) protocols over 802.16 Networks. This 53 document also presents the goals that point at relevant work to be at 54 IETF. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 4 62 4.1. Transport Connections . . . . . . . . . . . . . . . . . . 5 63 4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 5 64 4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 5 65 5. 16ng Problem Statements . . . . . . . . . . . . . . . . . . . 6 66 5.1. Root Causes . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2. IP over 802.16 with IP CS: Problems . . . . . . . . . . . 7 68 5.2.1. IPv4 over IP CS . . . . . . . . . . . . . . . . . . . 7 69 5.2.2. IPv6 over IP CS . . . . . . . . . . . . . . . . . . . 8 70 5.3. IP over 802.16 with Ethernet CS: Problems . . . . . . . . 9 71 5.3.1. IPv4 over Ethernet CS . . . . . . . . . . . . . . . . 9 72 5.3.2. IPv6 over Ethernet CS . . . . . . . . . . . . . . . . 10 73 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Appendix A. IP Link Model . . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . . . 16 85 1. Introduction 87 Broadband Wireless Access networks address the inadequacies of low 88 bandwidth wireless communication for user requirements such as high 89 quality data/voice service, fast mobility, wide coverage, etc. The 90 IEEE 802.16 Working Group on Broadband Wireless Access Standards 91 develops standards and recommended practices to support the 92 development and deployment of broadband Wireless Metropolitan Area 93 Networks [IEEE802.16]. Additionally, IEEE 802.16e is an amendment 94 that adds support for mobility over the base IEEE 802.16 95 specification [IEEE802.16e]. 97 Recently, the WiMAX Forum, and, in particular, its NWG (Network 98 Working Group) is defining the IEEE 802.16(e) network architecture 99 (e.g., IPv4, IPv6, Mobility, Interworking with different networks, 100 AAA, etc). The NWG is thus taking on work at layers above those 101 defined by the IEEE 802 standards (typically limited to the physical 102 and link layers only). Similarly, WiBro (Wireless Broadband), a 103 Korean effort which focuses on the 2.3 GHz spectrum band, is also 104 based on the IEEE 802.16e specification [IEEE802.16e]. 106 IEEE 802.16(e) is different from existing wireless access 107 technologies such as IEEE 802.11 or 3G. For example: immediately 108 subsequent to network entry, an 802.16 SS (Subscriber Station) has no 109 capability whatsoever for data (as opposed to management) 110 connectivity. The criteria by which the BS (Base Station) sets up 111 the 802.16 MAC connections for data transport is not part of the 112 802.16 standard and depends on the type of data services being 113 offered (ie. the set up of transport connections will be different 114 for IPv4 and IPv6 services). Additionally - as 802.16 is a point-to- 115 multipoint network - an 802.16 subscriber station is not capable of 116 broadcasting (e.g., for neighbor discovery or dynamic address 117 binding) or direct communication to the other nodes in the network. 119 This lacking of facility for native multicasting for IP packet 120 transfer results in inappropriateness to apply the basic IP operation 121 like IPv4 Address Resolution Protocol or IPv6 Neighbor Discovery 122 Protocol. Accordingly, while 802.16 defines the encapsulation of an 123 IP datagram in an IEEE 802.16 MAC payload, complete description of IP 124 operation is not present. Thus, IP operation over IEEE 802.16 can 125 benefit from IETF input and specification. Two styles of link layers 126 are available from 802.16e [IEEE802.16e] as IP CS and Ethernet CS. 127 Also, WiMAX Forum has decided to make IP CS mandatory for IEEE 128 802.16e profile, and EthernetCS is an optional. Therefore, the 129 Ethernet capability layer does not exist in all implementations of 130 IEEE 802.16e profile. This document will describe the problems 131 identified in adopting IP over IEEE 802.16 networks. Also several 132 goals that point at relevant work to be done at IETF are presented 133 subsequently. 135 2. Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119] . 141 3. Terminology 143 Subscriber Station (SS): A generalized equipment set providing 144 connectivity between subscriber equipment and a base station (BS) 146 Base Station (BS): A generalized equipment sets providing 147 connectivity, management, and control of the subscriber station (SS). 149 IP Gateway: An entity which performs IP routing function to provide 150 IP connectivity for SSes. 152 Protocol Data Unit (PDU): This refers to the data format passed from 153 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 154 contains SDU data after fragmentation, encryption, etc. 156 Service Data Unit (SDU): This refers to the data format passed to the 157 upper edge of the 802.16 MAC 159 IP Link : This has the same meaning with the "IP Subnet" in case of 160 IPv4. This terminology represents both IPv6 link and IPv4 subnet 161 throughout this document. Under the same IP Link, a specific SS can 162 communicate with its communication peer without depending on the IP 163 routing facility. SSes under the same IP link share the same IP 164 network information, IPv4 subnet address or IPv6 link prefix. 166 4. Overview of the IEEE 802.16-2004 MAC layer 168 The topology of the IEEE 802.16-2004 [IEEE802.16] network is point- 169 to-multipoint (PMP): a Base Station (BS) communicates with a number 170 of Subscriber Stations (SSes). Each node in the network possesses a 171 48-bit MAC address (though in the Base Station this 48-bit unique 172 identifier is called "BSId"). Each node possesses RSA-based 173 authorization mechanism using x.509 certificate attesting to its MAC 174 address/BSId. The [IEEE802.16e] enhanced RSA-based authorization and 175 developed EAP-based authentication defined in [RFC3748] accordingly. 176 So EAP-based authentication is recommended for mobile user. The BS 177 and SS learn each others' MAC Address/BSId during the SS's entry into 178 the network. 180 4.1. Transport Connections 182 User data traffic (in both the BS-bound and SS-bound directions) is 183 carried on unidirectional "transport connections". Each transport 184 connection has a particular set of associated parameters indicating 185 characteristics such as cryptographic suite and quality-of-service. 187 After successful entry of a SS to the 802.16 network, no data traffic 188 is possible - as there are as yet no transport connections between 189 the BS and SS. Transport connections are established by a 3-message 190 signaling sequence within the MAC layer (usually initiated by the 191 BS). 193 A downlink-direction transport connection is regarded as "multicast" 194 if it has been made available (via MAC signaling) to more than one 195 SS. Uplink-direction connections are always unicast. 197 4.2. 802.16 PDU format 199 An 802.16 PDU (ie. the format that is transmitted over the airlink) 200 consists of a 6-byte MAC header, various optional subheaders, and a 201 data payload. 203 The 802.16 6-byte MAC header carries the Connection Identifer (CID) 204 of the connection with which the PDU is associated. We should 205 observe that there is no source or destination address present in the 206 raw 802.16 MAC header. 208 4.3. 802.16 Convergence Sublayer 210 The 802.16 convergence sublayer (CS) is the component of the MAC that 211 is responsible for assigning transmit-direction SDUs (originating 212 from a higher layer application - eg. an IP stack at the BS or SS) to 213 a specific outbound transport connection. The convergence sublayer 214 maintains an ordered "classifier table". Each entry in the 215 classifier table includes a classifier and a target CID. A 216 classifier, in turn, consists of a conjunction of one or more 217 subclassifiers - where each subclassifier specifies a packet field 218 (eg. the destination MAC address in an Ethernet frame, or the TOS 219 field of an IP datagram contained in an Ethernet frame) together with 220 a particular value or range of values for the field. To perform 221 classification on an outbound SDU, the convergence sublayer proceeds 222 from the first entry of the classifier table to the last, and 223 evaluates the fields of the SDU for a match with the table entry's 224 classifier When a match is found, the convergence sublayer associates 225 the SDU with the target CID (for eventual transmission), and the 226 remainder of the 802.16 MAC and PHY processing can take place. 228 802.16 define numerous convergence sublayer types. The "type" of the 229 convergence sublayer determines the fields that may appear in 230 classifiers eg. 232 o "802.3/Ethernet CS" permits classifiers that examine fields in 233 802.3-style headers 235 o "IPv4 CS" permits classifiers that examine fields of IPv4 (and 236 encapsulated TCP/ UDP headers) 238 o "IPv6 CS" permits classifiers that examine fields of IPv6 (and 239 encapsulated TCP/ UDP headers) 241 Other CS types include ATM, IPv4-over-ethernet CS and IPv6-over- 242 ethernet CS. An implementation of 802.16 can support multiple CS 243 types. 245 We can observe that the CS type actually defines the type of data 246 interface (eg. IPv4/IPv6 or 802.3 ) that is presented by 802.16 to 247 the higher layer application. 249 5. 16ng Problem Statements 251 5.1. Root Causes 253 This section describes common problem statements regardless of 254 convergence sublayer. 256 The following are the root causes that prevent running IP protocols 257 (both IPv4 and IPv6) over 802.16 networks smoothly. The consequences 258 of these characteristics are listed in Section 5.2 and 5.3. 260 - Point-to-Multipoint architecture: 262 The 802.16 is a point-to-multipoint network without bi-directional 263 native multicast support. This prevents IP nodes from multicasting. 264 In 802.16 specification, when the 802.16 MAC receives a unicast/ 265 multicast/broadcast packet from upper Layers, it just looks at the 266 various fields (classifiers) in the headers and maps to the outgoing 267 CID (This can also be a multicast CID in case of downlink). 269 When 802.16 MAC receives a PDU from the PHY, it simply passes it to 270 the layer above the MAC (eg. Ethernet or IP). It is the upper 271 layer's responsibility to deliver the packet to the correct 272 destination which nonetheless is limited by the existence of downlink 273 multicast/broadcast connections for multicast/broadcast frames. 274 Because IP layer services (e.g. IPv4 ARP, DHCPv4, IPv6 NDP, DHCPv6 275 etc.) rely on link-layer multicast--or services with similar 276 semantics at the link-layer--, alternative mechanisms must be 277 specified. 279 - Limitation of Ethernet capability layer of 802.16: 281 The Ethernet capability layer of 802.16 (called the convergence 282 sublayer) specifies only how Ethernet frames are to be encapsulated 283 over 802.16 wireless connections. This demonstrates that Ethernet CS 284 does not itself emulate Ethernet like functionality, and multicast/ 285 broadcast frames can not be processed at the 802.16 MAC layer only. 286 These frames must be sent to an Ethernet/bridge layer, which in turn 287 may send PDUs back to 802.16 downlink, to send out these multicast/ 288 broadcast frames there should be a downlink multicast/broadcast 289 connection to which all SSes are listening. 291 - Communication among SSes on the same IP link: 293 It is unclear in 802.16 networks how SSes under a certain IP gateway 294 communicate each other under the assumption that they are in same IP 295 Link. In IPv6 case, [I-D.ietf-ipv6-2461bis] defines IP Link as a 296 communication facility or medium over which nodes can communicate at 297 the link layer, i.e., the layer immediately below IP. Examples are 298 Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM 299 networks as well as internet (or higher) layer "tunnels", such as 300 tunnels over IPv4 or IPv6 itself. The 802.16 network has a 301 connection oriented feature, where a connection always ends at the 302 BS. There is no support from 802.16 MAC/PHY for the direct 303 communication among SSes under the same IP link. The issue of 304 configuring an "IP Link" over IEEE 802.16 network is described in the 305 Appendix A. 307 5.2. IP over 802.16 with IP CS: Problems 309 5.2.1. IPv4 over IP CS 311 - DHCPv4 IP Address management and assignment: 313 For the IPv4 address management and assignment, IEEE 802.16 network 314 refers primarily to allocation of Dynamic Host Configuration Protocol 315 [RFC2131], static method is configured by manual though. DHCPv4 is a 316 broadcasting-based IP allocation protocol. When initializing its IP 317 configuration, the SS broadcasts a DHCPDISCOVER message on its local 318 physical subnet. After receiving multiple DHCPOFFER messages, the SS 319 broadcasts a DHCPREQUEST message with several options specifying 320 desired configuration values. However, current DHCPv4 operations are 321 tricky because of IEEE 802.16 non-broadcasting characteristics. 322 Especially, DHCPv4 operation is tightly related to ARP facilities 323 (e.g., checking on the uniqueness of allocated network address, 324 etc.). For management and configuration requirements of SS, an IETF- 325 based IP address allocation solutions should be specified in 326 compliance with IEEE 802.16(e) networks. In DHCPv6 [RFC3315] case, 327 it is modeled on DHCPv4, so, the problems described above still 328 remain. For MIP-based mobile terminals, MIPv4 [RFC3344] based IP 329 addressing is used instead of DHCPv4. However, it still requires 330 multicast/broadcast facilities for supporting ICMP Router 331 Advertisement [RFC1256]. 333 - ARP resolution and ARP cache: 335 Address Resolution is the process by which nodes determine the link- 336 layer address of a destination node on the same subnet given only the 337 destination's IP address and it is a mandatory function of TCP/IP. 338 In IPCS case, however, there is no need for address resolution 339 because MAC message is made by IP Gateway instead of SS and hence ARP 340 cache as 802.16 MAC address is never used as part of the 802.16 341 Frame. Blocking ARP needs to be implemented by SS itself in an 342 implementation manner. There is no way of how to use ARP facilities 343 on SS. 345 5.2.2. IPv6 over IP CS 347 - Router Discovery: 349 Because there is no MAC Address used in case of IPCS, it is unclear 350 whether source link layer address need to be carried in the RS 351 (Router Solicitation). As 802.16 MAC Address is not used for 352 delivering the frames the RS may need to have source IP address 353 specified, so that the RA (Router Advertisement) can be sent back. 354 This may require the completion of Link Local Address configuration 355 before sending an RS. 357 For sending periodic Router Advertisements in 802.16 Networks, BS 358 either needs to send the RA in unicast manner for each SS explicitly 359 or send the RA in multicast connection. 361 - Prefix Assignment: 363 If the same IP prefix is shared with multiple SSes then the link 364 consists of multiple SSes. In this model a SS assumes that there 365 exist on-link neighbors and tries to resolve the L2 address for the 366 on-link prefixes. However, direct communication using Link Layer 367 Address between two SSs may not be possible. This poses a problem 368 for sharing a prefix with multiple SSes. 370 - Address Resolution and Neighbor Cache: 372 Address Resolution is the process by which nodes determine the link- 373 layer address of an on-link destination (e.g., a neighbor) given only 374 the destination's IP address. In case of IP CS, there is no need for 375 Address Resolution and hence Neighbor Cache as 802.16 MAC address is 376 never used as part of the 802.16 Frame. 378 - Neighbor Unreachability Detection (NUD): 380 In case of IP CS, a SS may always see the IP Gateway as the next hop, 381 the NUD is required only for the IP Gateway(s). Also the requirement 382 of NUD may depend on the existence of a connection to the BS for that 383 particular destination. If there exists multiple IP Gateways (so the 384 default routers), it is unknown if the NUD is required if an IP 385 Gateway is not serving any 802.16 MAC connection. 387 - Address Autoconfiguration: 389 How Address Autoconfiguration can be achieved in 802.16 networks is 390 dependent on following: 1) Whether the SSes attached to the same BS 391 are neighbors (IP link Model), 2) Whether the prefix is being shared 392 with other SSes. If a unique prefix is assigned to each SS similar 393 to 3G approach, then the subnet consists of only one SS and hence 394 duplicate address detection (DAD) is trivial. If the same prefix is 395 shared with multiple SSes then the subnet consists of multiple SSes 396 and DAD is required. DAD in 802.16 requires explicit multicast 397 support from the Networks as there is no native multicast support. 398 Thus, the explicit mechanism to perform the DAD procedure in the 399 802.16 network needs to be specified. 401 5.3. IP over 802.16 with Ethernet CS: Problems 403 We assume that the IP gateway supports Ethernet interface and the IP 404 Gateway sees the Ethernet frame sent by the SS unchanged. 406 5.3.1. IPv4 over Ethernet CS 408 DHCPv4 IP Address management and assignment: 410 In the Ethernet CS case, the SS act as a layer 2 device and IP 411 assignment will be carried through for hosts behind the BS. In this 412 case, the BS simply forwards the DHCPv4 messages between the DHCPv4 413 client and DHCPv4 server. However, as pointed out in above, Ethernet 414 CS is an optional function over IEEE 802.16 networks, so it can not 415 be applied for all SSes and limitation of DHCPv4 still remains. 417 - ARP resolution and ARP cache: 419 Address Resolution is the process by which nodes determine the link- 420 layer address of a destination node on the same subnet given only the 421 destination's IP address and it is a mandatory function of TCP/IP. 422 In Ethernet CS case, if ARP is blocked by SS like IPCS, there is no 423 way to obtain the MAC address of IP Gateway without ARP process 424 because SS have to generate its ARP request message by itself. There 425 is no way of how to use ARP facilities on SS. 427 5.3.2. IPv6 over Ethernet CS 429 - Router Discovery: 431 For sending periodic Router Advertisements in 802.16 Networks, BS 432 either needs to send the RA in unicast manner for each SS explicitly 433 or send the RA through the multicast connection if available. 435 - Prefix Assignment: 437 Similar to IP CS case. 439 - Address Resolution and Neighbor Cache: 441 In case of Ethernet CS, if the prefix is shared with L-bit set, the 442 Address Resolution may be required, which in turn requires multicast 443 support from 802.16 MAC. If the prefixes are advertised with L bit 444 reset, then Address Resolution and Neighbor Cache for other SSes may 445 not be required. In this case, Neighbor Cache is maintained only for 446 IP Gateway. 448 - Neighbor Unreachability Detection (NUD): 450 Same as IP CS case. 452 - Address Autoconfiguration: 454 Same as IP CS case. 456 6. Gap Analysis 458 This section analyzes gaps between 802.16 networks and possible 459 alternative approaches. 461 3GPP recommendation [RFC3314]: 463 From the 3GPP recommendation, separate prefixes are allocated to each 464 SSes resulting in the different IP links for each SSes. IP Gateway 465 might be comparable to the GGSN of 3GPP network. However, using PPP 466 directly is not feasible in 802.16 networks because there is no PPP 467 Convergence Sublayer that permits classification to transport 468 connections based on fields in a PPP header. Moreover, more 469 preferable way is to configure a common IP link for all SSes under an 470 ASN IP Gateway. Thus, how to form a common IP link for all SSes 471 under a certain IP Gateway needs to be focused. 473 LAN model [RFC0894]: 475 It seems easy to follow the LAN model where BS and IP Gateway reside 476 on the same box. However, the BS implementation to emulate a LAN 477 feature would be different from the previous Wireless LAN bridge. In 478 802.16, BS does not directly see the destination Ethernet address to 479 forward the layer 2 frame. The MAC common part needs to deliver the 480 MAC SDU to the convergence sublayer to be classified to the 481 confirming MAC connection. We can also recognize the different point 482 from the Wireless LAN bridge. Mostly AP in the wireless LAN 483 translates the 802.11 frame to 802.3 frame by the help of the 484 existence of same LLC. However, there is no LLC in the 802.16 485 protocol stack thus, it is problematic to convert 802.16 frame to 486 802.3 frame directly. Thus, in 802.16, it is expected that MAC 487 common layer of 802.16 to deliver the MAC SDU to the upper packet 488 convergence sublayer to reconstruct the higher layer PDU to classify 489 to the confirming connection. 491 7. Goals 493 We need to first identify which "IP Link" model is a feasible one 494 depending on each CS is used. According to the identified "IP Link" 495 model for each CS, we would specify the following work items. 497 * IPv4 transmission for 802.16 network in case where IPv4 CS is used. 499 * IPv4 transmission for 802.16 network in case where Ethernet CS is 500 used. 502 * IPv6 transmission for 802.16 network in case where IPv6 CS is used. 504 * IPv6 transmission for 802.16 network in case where Ethernet CS is 505 used. 507 The following are the goals in no particular order that point at 508 relevant work to be done in IETF. 510 1. The solution SHOULD work with the existing or normal IP host 511 implementations. 513 2. In case where Ethernet CS is used for multiple interface hosts, 514 it is desirable to provide a single host stack that could work 515 without depending on the specific media characteristic. 517 3. It SHOULD be specified which connection (Secondary Management or 518 a new IP signaling connection) an SS should use to send ICMP 519 messages. One possible way of implementing IP signaling such as ICMP 520 (and even IPv6 ND) is to use 802.16/16e transport connection rather 521 than secondary management connection. In this implementation, one IP 522 layer broadcast/multicast packet which needs to be delivered to a 523 specific SS can be delivered to the SS based on demand. For example, 524 if the IP Gateway which is co-located with IPv4 Foreign Agent needs 525 to transfer Agent Advertisement to SS, unicast transport connection 526 between BS and SS can be used. 528 4. It is desirable to have a model for multicast/broadcast support 529 in 802.16 so that an SS can send a multicast packet to all SSes 530 within an IP Link. There should also be an option to turn off this 531 facility in cases where it is not required or undesirable. 533 5. The solution SHOULD avoid using the air bandwidth wherever 534 possible. 536 6. The solution SHOULD not introduce any new security threats. 538 8. Security Considerations 540 As described in the section 4, several authentication and 541 authorization mechanisms are defined by [IEEE802.16] and 542 [IEEE802.16e]. In [IEEE802.16e] case, PKMv2 EAP-based authentication 543 is recommended for the secure connection between SS and BS/IP 544 Gateway. 546 9. IANA Considerations 548 No new protocol numbers are required. 550 10. Acknowledgment 552 We would like to express special thanks to IETF Mobility Working 553 Group members of KWISF (Korea Wireless Internet Standardization 554 Forum) for their initial efforts and remarkably to HeeYoung Jung for 555 his motivation in proceeding this work. 557 We also would like to express special thanks to the previous authors 558 of the previous problem statement document, Myung-Ki Shin, Eun-Kyoung 559 Paik and Jaesun Cha. 561 We also would like to express thanks to Jicheol Lee, Sung Il Kim, Se 562 Jun Park, Sang Eon Kim, Han-Lim Kim and Jung-Mo Moon for their inputs 563 to this work. 565 11. References 567 11.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 11.2. Informative References 574 [I-D.ietf-ipv6-2461bis] 575 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 576 draft-ietf-ipv6-2461bis-05 (work in progress), 577 October 2005. 579 [IEEE802.16] 580 IEEE Std 802.16-2004, "IEEE Standard for Local and 581 metropolitan area networks, Part 16: Air Interface for 582 Fixed Broadband Wireless Access Systems", October 2004. 584 [IEEE802.16e] 585 IEEE P802.16e-2005, "Draft IEEE Standard for Local and 586 metropolitan area networks, Amendment for Physical and 587 Medium Access Control Layers for Combined Fixed and 588 Mobile Operation in Licensed Bands", 2005. 590 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 591 converting network protocol addresses to 48.bit Ethernet 592 address for transmission on Ethernet hardware", STD 37, 593 RFC 826, November 1982. 595 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 596 over Ethernet networks", STD 41, RFC 894, April 1984. 598 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 599 September 1991. 601 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 602 RFC 2131, March 1997. 604 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 605 Discovery for IP Version 6 (IPv6)", RFC 2461, 606 December 1998. 608 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 609 Generation Partnership Project (3GPP) Standards", 610 RFC 3314, September 2002. 612 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 613 and M. Carney, "Dynamic Host Configuration Protocol for 614 IPv6 (DHCPv6)", RFC 3315, July 2003. 616 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 617 August 2002. 619 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 620 Levkowetz, "Extensible Authentication Protocol (EAP)", 621 RFC 3748, June 2004. 623 Appendix A. IP Link Model 625 [I-D.ietf-ipv6-2461bis] defines IP Link as a communication facility 626 or medium over which nodes can communicate at the link layer, i.e., 627 the layer immediately below IP. Examples are Ethernets (simple or 628 bridged), PPP links, X.25, Frame Relay, or ATM networks as well as 629 internet (or higher) layer "tunnels", such as tunnels over IPv4 or 630 IPv6 itself. 802.16 connection oriented technology but the connection 631 always ends at Base Station unlike in NBMA technologies (e.g. ATM 632 and Frame Relay) where connections exist between peer entities. 634 Because of this characteristic, it is also unclear how two nodes 635 connected to two different base stations communicate each other under 636 the assumption that they are in same IP Link. As 802.16 MAC/PHY is 637 not used to communicate directly between to nodes the definition of 638 IP Link in 802.16 is unclear. 640 Depending on the use of Convergence Sublayer, prefix assignment and 641 the preference of operators, there can be three different types of 642 subnet IP link models. 644 - The IP link consisting of multiple BSes and all the SSes hanging 645 off them with multiple IP Gateways. 647 - The IP link consisting of multiple BSes and all the SSes hanging 648 off it with single IP Gateway. 650 - The IP link consisting of just the point to point connectivity 651 between an IP Gateway and one SS. 653 Authors' Addresses 655 Junghoon Jee 656 ETRI 658 Email: jhjee@etri.re.kr 660 Syam Madanapalli 661 Samsung ISO 663 Email: syam@samsung.com 665 Jeff Mandin 666 Runcom 668 Email: jeff@streetwaves-networks.com 670 gabriel_montenegro_2000@yahoo.com 671 Microsoft 673 Email: gabriel_montenegro_2000@yahoo.com 675 Soohong Daniel Park 676 Samsung Electronics 678 Email: soohong.park@samsung.com 680 Maximilian Riegel 681 Siemens 683 Email: maximilian.riegel@siemens.com 685 Intellectual Property Statement 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed to 689 pertain to the implementation or use of the technology described in 690 this document or the extent to which any license under such rights 691 might or might not be available; nor does it represent that it has 692 made any independent effort to identify any such rights. Information 693 on the procedures with respect to rights in RFC documents can be 694 found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use of 699 such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository at 701 http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org. 709 Disclaimer of Validity 711 This document and the information contained herein are provided on an 712 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 713 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 714 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 715 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 716 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 717 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 719 Copyright Statement 721 Copyright (C) The Internet Society (2006). This document is subject 722 to the rights, licenses and restrictions contained in BCP 78, and 723 except as set forth therein, the authors retain all their rights. 725 Acknowledgment 727 Funding for the RFC Editor function is currently provided by the 728 Internet Society.