idnits 2.17.1 draft-ietf-16ng-ipv6-link-model-analysis-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 721. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 10, 2006) is 6405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 642, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (ref. '5') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3315 (ref. '6') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2472 (ref. '9') (Obsoleted by RFC 5072, RFC 5172) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 16ng Working Group S. Madanapalli, Ed. 3 Internet-Draft LogicaCMG 4 Intended status: Informational October 10, 2006 5 Expires: April 13, 2007 7 Analysis of IPv6 Link Models for 802.16 based Networks 8 draft-ietf-16ng-ipv6-link-model-analysis-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 13, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document provides different IPv6 link models that are suitable 42 for 802.16 based networks and provides analysis of various 43 considerations for each link model and the applicability of each link 44 model under different deployment scenarios. This document is result 45 of a Design Team that was formed to analyze the IPv6 link models for 46 802.16 based networks. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. IPv6 Link Models for 802.16 based Networks . . . . . . . . . . 4 53 3.1. Shared IPv6 Prefix Link Model . . . . . . . . . . . . . . 4 54 3.1.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 5 55 3.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 5 56 3.1.3. Duplicate Address Detection . . . . . . . . . . . . . 5 57 3.1.4. Considerations . . . . . . . . . . . . . . . . . . . . 6 58 3.1.5. Applicability . . . . . . . . . . . . . . . . . . . . 7 59 3.2. Point-to-point Link Model . . . . . . . . . . . . . . . . 7 60 3.2.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 8 61 3.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 8 62 3.2.3. Considerations . . . . . . . . . . . . . . . . . . . . 8 63 3.2.4. Applicability . . . . . . . . . . . . . . . . . . . . 10 64 3.3. Ethernet Like Link Model . . . . . . . . . . . . . . . . . 10 65 3.3.1. Prefix Assignment . . . . . . . . . . . . . . . . . . 11 66 3.3.2. Address Autoconfiguration . . . . . . . . . . . . . . 11 67 3.3.3. Duplicate Address Detection . . . . . . . . . . . . . 11 68 3.3.4. Considerations . . . . . . . . . . . . . . . . . . . . 11 69 3.3.5. Applicability . . . . . . . . . . . . . . . . . . . . 12 70 4. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Effect on Dormant Mode . . . . . . . . . . . . . . . . . . . . 13 72 6. SeND Support . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Conclusions and Relevant Link Models . . . . . . . . . . . . . 13 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 Intellectual Property and Copyright Statements . . . . . . . . . . 17 82 1. Introduction 84 802.16 [1] [2] is a connection oriented access technology for the 85 last mile without bi-directional native multicast support. 802.16 has 86 only downlink multicast support and there is no mechanisms defined 87 for mobile stations to be able to send multicast packets that can be 88 mapped to downlink multicast connection. This could be a problem for 89 IP protocols (e.g. ARP, IPv6 ND) that traditionally assume the 90 availability of multicast at the link layer. This is further 91 complicated by the definition of commercial network models like 92 WiMAX, which defines the WiMAX transport connection that extend the 93 802.16b MAC transport connection all the way to an access router by 94 using a tunnel between the base station and the access router. This 95 leads to multiple ways of deploying IP over 802.16 based networks. 97 This document looks at various considerations in selecting a link 98 model for 802.16 based networks and provides an analysis of the 99 various possible link models. 101 2. Terminology 103 Access Router (AR): An entity that performs an IP routing function to 104 provide IP connectivity for Mobile Stations. In WiMAX Networks, the 105 AR is an Access Service Network Gateway. 107 Access Service Network (ASN): A complete set of network functions 108 needed to provide radio access to a Mobile Station. 110 Base Station (BS): A generalized equipment sets providing 111 connectivity, management, and control of the subscriber station (SS). 113 Dormant Mode: A state in which a mobile station restricts its ability 114 to receive normal IP traffic by reducing monitoring of radio 115 channels. This allows the mobile station to save power and reduces 116 signaling load on the network. In the dormant mode, the MS is only 117 listening at scheduled intervals to the paging channel. The network 118 (e.g. the AR) maintains state about an MS which has transitioned to 119 dormant mode and can page it when needed. 121 IP Link: This has been defined in [3] as below. 122 - a communication facility or medium over which nodes can 123 communicate at the link layer, i.e., the layer immediately below 124 IP. Examples are Ethernets (simple or bridged), PPP links, X.25, 125 Frame Relay, or ATM networks as well as Internet (or higher) layer 126 "tunnels", such as tunnels over IPv4 or IPv6 itself. 128 Mobile Station (MS): An end-user equipment that provides connectivity 129 to 802.16 based networks. 131 3. IPv6 Link Models for 802.16 based Networks 133 This section discusses various IPv6 link models for 802.16 based 134 networks and provides their operational considerations in practical 135 deployment scenarios. 137 3.1. Shared IPv6 Prefix Link Model 139 The following figures illustrates high level view of the link model 140 using a shared prefix for an IPv6 link wherein one more prefixes 141 advertised on the link would be used by all nodes attached to the 142 IPv6 link. 144 +-----+ 145 | MS1 |-----+ 146 +-----+ | 147 | 148 | 149 +-----+ | +-----+ +--------+ 150 | MS2 |-----+-----| BS1 |----------| AR |-------[Internet] 151 +-----+ | +-----+ +--------+ 152 . | ____________ 153 . | ()__________() 154 +-----+ | L2 Tunnel 155 | MSn |-----+ 156 +-----+ 158 Figure 1. Shared IPv6 Prefix Link Model 160 The above figure shows the case where the BS and AR exist as separate 161 entities. In this case a tunnel exists between the BS and AR per MS 162 basis. 164 In this link model, the link between the MS and the AR at the IPv6 165 layer is viewed as a shared link and the lower layer link between the 166 MS and BS is a point-to-point link. This point-to-point link between 167 the MS and BS is extended all the way to the AR when the granularity 168 of the tunnel between the BS and AR is on per MS basis. This is 169 illustrated in the following figure below. 171 MS 172 +----+ +----+ 173 | | IPv6 (Shared link) | | 174 | L3 |=====================================| | 175 | | | | 176 |----| PTP conn. +----+ L2 Tunnel | AR |---[Internet] 177 | L2 |-------------| BS |==================| | 178 | | | | | | 179 +----+ +----+ | | 180 | | 181 +----+ L2 Tunnel | | 182 | BS |==================| | 183 | | | | 184 +----+ +----+ 186 Figure 2. Shared IPv6 Prefix Link Model - Layered View 188 In this link model, an AR can serve one or more BSs. All MSs 189 connected to BSs that are served by an AR are on the same IPv6 link. 190 This model is different from Ethernet Like Link model wherein the 191 later model provides Ethernet link abstraction and multicast 192 capability to IPv6 layer, whereas the Shared IPv6 Prefix Link Model 193 defined here does not provide native link layer multicast and 194 broadcast capabilities. 196 3.1.1. Prefix Assignment 198 One or more IPv6 prefixes are assigned to the link and hence shared 199 by all the nodes that are attached to the link. The prefixes are 200 advertised with autonomous flag (A-Flag) set and the On-link flag 201 (L-flag) reset for address autoconfiguration so that the nodes may 202 not make an on-link assumption for the addresses in those prefixes. 204 3.1.2. Address Autoconfiguration 206 The standard IPv6 address autoconfiguration mechanisms, which are 207 specified in [4] [6] are used. 209 3.1.3. Duplicate Address Detection 211 The DAD procedure as specified in [4] does not adapt well to the 212 802.16 air interface as there is no native multicast support. The 213 DAD can be performed with MLD snooping and the AR relaying the DAD 214 probe to the address owners in case if the address is duplicate, 215 called Relay DAD. In this method, the MS behavior is same as 216 specified in [4] and the optimization is achieved with the support of 217 AR, which maintains MLD table for a list of multicast addresses and 218 the nodes that joined the multicast address. The relay DAD works as 219 below: 220 1. An MS constructs a Link Local Address as specified in [4]. 221 2. The MS constructs a solicited node multicast address for the 222 corresponding Link Local Address and sends an MLD Join request 223 for the solicited node multicast address. 224 3. The MS starts verifying address uniqueness by sending a DAD NS on 225 the initial MAC transport connection. 226 4. The AR consults the MLD table for who joined the multicast 227 address. If the AR does not find any entry in the MLD table, the 228 AR silently discards the DAD NS. If the AR founds a match, the 229 AR relays the DAD NS to the address owner. 230 5. The address owner defends the address by sending DAD NA, which is 231 relayed to the DAD originating MS via the AR. 232 6. If the DAD originating MS does not receive any response (DAD NA) 233 to its DAD NS, the MS assigns the address to its interface. If 234 the MS receives the DAD NA, the MS discards the tentative address 235 and behaves as specified in [4]. 237 3.1.4. Considerations 239 3.1.4.1. Reuse of existing standards 241 The shared IPv6 prefix model uses the existing specification and does 242 not require any protocol changes or any new protocols. However this 243 model requires implementation changes for DAD optimization on the AR. 245 3.1.4.2. On-link Multicast Support 247 No native on-link multicast is possible with this method. However 248 the multicast can be supported with support of AR performing MLD 249 snooping(?). 251 3.1.4.3. Consistency in IP Link Definition 253 The definition of IPv6 link is consistent for all procedures and 254 functionalities except for the support of native on-link multicast 255 support. 257 3.1.4.4. Packet Forwarding 259 All the packets travel to the AR before being delivered to the final 260 destination as the layer 2 transport connection exists between the MS 261 and AR. The AR handles the packets with external IPv6 addresses 262 normally. However the packets with link local destination addresses 263 are relayed by the AR to destination without decrementing the hop- 264 limit. 266 3.1.4.5. Changes to Host Implementation 268 This link model does not require any implementation changes to the 269 host side. However the hosts are required to perform duplicate 270 address detection for all addresses even if the host is reusing the 271 interface identifier. 273 3.1.4.6. Changes to Router Implementation 275 This link model requires MLD snooping in the AR for supporting Relay 276 DAD. 278 3.1.5. Applicability 280 This model is applicable to service provider public access networks 281 like cellular networks in conjunction with IPv6 CS. 283 This link model is also under consideration of the WiMAX Forum 284 Network Working Group for using with IPv6 CS access. 286 3.2. Point-to-point Link Model 288 In this model, a set of MAC transport connections between an MS and 289 the AR are treated as a single link. The point-to-point link model 290 follows the recommendations of [8]. In this model, each link between 291 an MS and the AR is allocated a separate, unique prefix or a set of 292 unique prefixes by the AR. No other node under the AR has the same 293 prefixes on the link between it and the AR. The following diagram 294 illustrates this model. 296 +----+ +----+ 297 +-----+ | | Tunnel | | 298 | MS1 |-------------|....|===================| | 299 +-----+ | | | | 300 | | | | 301 +-----+ | | Tunnel | | 302 | MS2 |-------------|....|===================| |---[Internet] 303 +-----+ | | | AR | 304 | BS | | | 305 +-----+ | | Tunnel | | 306 | MS3 |-------------|....|===================| | 307 +-----+ | | | | 308 +----+ +----+ 310 Figure 3. Point-to-point Link Model 312 There are multiple possible ways that the point-to-point link between 313 the AR and the MS can be implemented. 314 1. One way to accomplish this is to run PPP on the link [8]. 315 Running PPP requires that the 802.16 link use the Ethernet CS and 316 PPP over Ethernet [10]. Since the IPv6 CS does not support PPP, 317 whether PPP can be run depends on the network architecture. 318 2. If the actual physical medium is shared, like Ethernet, but PPP 319 is not run, the link can be made point to point between the MS 320 and AR by having each MS on a separate VLAN [12]. 321 3. If neither PPP nor VLAN is used, the set of 802.16 connections 322 can be viewed as a virtual point-to-point link for the purpose of 323 neighbor discovery and address configuration. For IPv6 CS, this 324 may be used to implement the point-to-point link. 326 3.2.1. Prefix Assignment 328 Prefixes are assigned to the link using the standard [3] Router 329 Advertisement mechanism. The AR assigns a unique prefix or set of 330 unique prefixes for each MS. In the prefix information options, both 331 the A-flag and L-flag are set to 1, as they can be used for address 332 autoconfiguration and the prefixes are on link. 334 3.2.2. Address Autoconfiguration 336 MSs perform link local as well as global address autoconfiguration 337 exactly as specified in [4], including duplicate address detection. 338 Because there is only one other node on the link, the AR, there is 339 only a possibility of an address conflict with the AR, so collisions 340 are statistically very unlikely, and easy to fix if they should 341 occur. 343 If DHCP is used for address configuration ('M=1' in the Router 344 Advertisement), the DHCP server must provide addresses with a 345 separate prefix per MS. The prefix must of course match a prefix the 346 ASN Gateway has advertised to the MS (if any). 348 3.2.3. Considerations 350 3.2.3.1. Reuse of existing standards 352 This solution reuses RFC 2461, 2462, and if PPP is used, RFC 2472 and 353 RFC 2516. No changes in these protocols are required, the protocols 354 must only be configured properly. 356 If PPP is not used, any VLAN solution, such as IEEE 802.1Q [9], or 357 any L2 tunnel can be used. 359 3.2.3.2. On-link Multicast Support 361 Since the link between the MS and the AR is point to point, any 362 multicast can only be sent by one or the other node. Link local 363 multicast between other nodes and the AR will not be seen. 365 3.2.3.3. Consistency in IP Link Definition 367 The IP link is fully consistent with a standard IP point-to-point 368 link, without exception. 370 3.2.3.4. Packet Forwarding 372 The MS always sends all packets to the AR, because it is the only 373 other node on the link. Link local unicast and multicast packets are 374 also forwarded only between the two. 376 When the p2p link model is used, the BS acts as a bridge. For each 377 MS, the BS bridges the unique prefix or set of prefixes assigned by 378 the AR to the link between itself and the MS. This means, in 379 particular, that the per MS prefix or set of prefixes are routed on 380 both sides (wireless and wired) of the BS, and that the BS needs to 381 participate in all 802 standard bridging protocols. 383 3.2.3.5. Changes to Host Implementation 385 Host implementations follow standard IPv6 stack procedures. No 386 changes needed. 388 3.2.3.6. Changes to Router Implementation 390 If PPP is used, no changes in router implementations are needed. If 391 PPP is not used, the AR must be capable of doing the following: 392 1. Each MS is assigned a separate VLAN when 802.1X [13] or each MS 393 must have an L2 tunnel to the AR to aggregate all the connections 394 to the MS and present these set of connections as an interface to 395 the IPv6 layer. 396 2. The AR must be configured to include a unique prefix or set of 397 prefixes for each MS. This unique prefix or set of prefixes must 398 be included in Router Advertisements every time they are sent, 399 and if DHCP is used, the addresses leased to the MS must include 400 only the uniquely advertised prefixes. 402 Note that, depending on the router implementation, these functions 403 may or may not be possible with simple configuration. No protocol 404 changes are required, however. 406 3.2.4. Applicability 408 In enterprise networks, shared services including printers, fax 409 machines, and other such on-line services are often available in on 410 the local link. These services are typically discovered using some 411 kind of link local service discovery protocol. The unique prefix per 412 MS model is not appropriate for these kinds of deployments, since it 413 is not possible to have shared link services in the ASN. 415 The p2p link model is applicable to deployments where there are no 416 shared services in the ASN. Such deployments are typical of service 417 provider networks like cellular network which provide public access 418 to wireless network. 420 3.3. Ethernet Like Link Model 422 This model describes a scheme for configuration and provisioning of 423 an IEEE 802.16 networks so that it emulates a broadcast link in a 424 manner similar to Ethernet. Figure 4 illustrates an example of the 425 Ethernet model. This model essentially functions like an Ethernet 426 link, which means the model works as described in [3], [4]. 428 One way to construct an Ethernet like link is to implement bridging 429 between BSs and AR like switched Ethernet. In the Figure 4, bridging 430 performs link aggregation between BSs and AR. Bridging also supports 431 multicast packet filtering. Another way to implement this model is 432 by using VLAN function [12]. 434 In this model, an IPv6 prefix is shared by multiple MSs on top of 435 IEEE 802.16 point-to-multipoint links. Also this model supports 436 multiple access routers and multiple hosts behind an MS as shown in 437 Figure 4. 439 +-----+ +---+ +----+ +-----+ ISP 1 440 | MS1 |-+ | | +---|AR1 |---| ER1 |===>Network 441 +-----+ | | S| | +----+ +-----+ 442 +-----+ | +-----+ |E w| | 443 | MS2 |-+--| BS1 |--|t i| | 444 +-----+ +-----+ |h t|--+ 445 | c| | +----+ +-----+ ISP 2 446 +-----+ +-----+ +-----+ | h| +---|AR2 |---| ER2 |===>Network 447 |Hosts|--|MS/GW|----| BS2 |--| | +----+ +-----+ 448 +-----+ +-----+ +-----+ +---+ 449 A network 450 may exists behind 451 MS/GW 453 Figure 4: Ethernet Like Link Model 455 3.3.1. Prefix Assignment 457 Prefixes are assigned as specified in [3], [4]. 459 3.3.2. Address Autoconfiguration 461 It is the same as described in [4]. 463 3.3.3. Duplicate Address Detection 465 It is the same as described in [4]. 467 3.3.4. Considerations 469 3.3.4.1. Reuse of existing standards 471 All the IPv6 standards can be preserved or reused in this model. 473 3.3.4.2. On-link Multicast Support 475 On-link multicast can be emulated in unicast manner by efficiently 476 bridging between all BSs with IEEE 802.16 providing the links between 477 the MSs and the bridge on top of the BS. Nevertheless, in case of 478 bridging, direct inter-MSs communication may not be not allowed due 479 to restrictions from the service providers. Another way to emulate 480 on-link multicast is to use VLAN. 482 3.3.4.3. Consistency in IP Link Definition 484 This model is consistent with the IP link definition. 486 3.3.4.4. Packet Forwarding 488 When properly configured and assisted by simple bridging or VLAN 489 functions, IEEE 802.16 can emulate a simple broadcast network like 490 Ethernet. 492 3.3.4.5. Changes to Host Implementation 494 No special impact on host implementation. 496 3.3.4.6. Changes to Router Implementation 498 No special impact on router implementation under a separated AR-BS 499 model, if the bridging is implemented in BS. Some networks e.g. 500 WiMAX networks may require bridging or VLAN to be implemented in the 501 AR (ASN Gateway). 503 3.3.5. Applicability 505 This model works with the Ethernet CS and is chosen for fixed/nomadic 506 WiMAX networks by the WiMAX Forum Network Working Group. 508 4. Renumbering 510 If the downstream prefixes managed by the AR are involved in 511 renumbering, it may be necessary to renumber each link under the AR. 512 [11] discusses recommended procedures for renumbering. 514 If the prefixes are advertised in RAs, the AR must withdraw the 515 existing prefixes and advertise the new ones. Since each MS 516 irrespective of the link model is on a separate point-to-point link 517 at the MAC level because of the 802.16 connection oriented 518 architecture, the AR must send an RA withdrawing the old prefix and 519 advertising the new one to each link. In point-to-point link model, 520 the number of RAs sent is equal to the number of nodes the AR serves, 521 whereas in the other two models, the AR sends a single RA to BS that 522 is sent to all the MSs as separate RAs. 524 If DHCP is used to assign addresses, either the DHCP address lease 525 lifetime may be reduced prior to the renumbering event to encourage 526 MSs to renew their addresses quickly or a DHCP Reconfigure message 527 may be sent to each of the MSs by the server to cause them to renew 528 their addresses. 530 In conclusion, the amount of traffic on the air-interface is same for 531 all link models. However the number of RAs sent by the AR to BS can 532 be more compared to the other two models. 534 5. Effect on Dormant Mode 536 If the network needs to deliver packets to an MS, which is in dormant 537 mode, the AR pages the MS. The MS that is monitoring the paging 538 channel receives the page and transitions out of the dormant mode to 539 active mode. It establishes connectivity with the network by 540 requesting and obtaining the radio resources. The network is then 541 able to deliver the packets to the MS. In many networks, packets 542 destined to an MS in dormant mode are buffered at the AR in the 543 network until connectivity is established. 545 Support for dormant MSs is critical in mobile networks and hence it 546 is a necessary feature. Paging capability and optimizations possible 547 for paging an MS are not either enhanced or handicapped by the link 548 model itself. However the multicast capability within a link may 549 cause for an MS to wake up for unwanted packet. This can be avoided 550 by filtering the multicast packets and delivering the packets to only 551 for MSs that are listening for particular multicast packets. As the 552 Shared IPv6 Prefix model does not have the multicast capability and 553 point-to-point link model has only one node on the link, they do not 554 have any effect on the dormant mode. The Ethernet like link model 555 may have the multicast capability, which requires filtering at the BS 556 to support the dormant mode for the MSs. 558 6. SeND Support 560 SEND is fully supported by all models described in this document. 561 And SeND should be used to secure the neighbor discovery procedures. 563 7. Conclusions and Relevant Link Models 565 Ethernet Like Link model would be used when the deployment requires 566 the use of Ethernet CS as this is the only model being proposed for 567 the Ethernet CS and running IPv6 over Ethernet is well understood. 569 For IPv6 CS, point-to-point link model appears to the choice because 570 of its simplicity for performing the DAD and does not break any 571 existing applications or require defining any new protocol. However 572 the IPv6 shared prefix model would be defined if there is any 573 interest from service provider community. 575 8. Security Considerations 577 This document provides the analysis of various IPv6 link models for 578 802.16 based networks and this document as such does not introduce 579 any new security threats. Nonetheless, this document encourages 580 usage of SeND for securing the neighbor discovery messages on any 581 IPv6 link. 583 9. IANA Considerations 585 This document has no actions for IANA. 587 10. Acknowledgements 589 This document is a result of discussions in v6subnet design team for 590 IPv6 Prefix Model Analysis. The members of this design team in 591 alphabetical order were: Dave Thaler, David Johnston, Junghoon Jee, 592 Max Riegel, Myungki Shin and Syam Madanapalli. The discussion in the 593 DT was benefited from the active participation of James Kempf, Behcet 594 Sarikaya, Basavaraj Patil and JinHyeock Choi in the DT mailing list. 595 The DT thanks the chairs (Gabriel Montenegro Soohong Daniel Park) and 596 Shepherding AD (Jari Arkko) for their active participation and 597 motivation. 599 11. Contributors 601 The members who provided the text based on the DT discussion are: 603 Myung-Ki Shin 604 ETRI 605 myungki.shin@gmail.com 607 James Kempf 608 DoCoMo Communications Labs USA 609 kempf@docomolabs-usa.com 611 Soohong Daniel Park 612 Samsung Electronics 613 soohong.park@samsung.com 615 Dave Thaler 616 Microsoft 617 dthaler@microsoft.com 618 JinHyeock Choi 619 Samsung Advanced Institute of Technology 620 jinchoe@samsung.com 622 Behcet Sarikaya 623 Huawei USA 624 sarikaya@ieee.org 626 12. References 628 [1] "IEEE 802.16-2004, IEEE standard for Local and metropolitan 629 area networks, Part 16:Air Interface for fixed broadband 630 wireless access systems", October 2004. 632 [2] "IEEE 802.16e, IEEE standard for Local and metropolitan area 633 networks, Part 16:Air Interface for fixed and Mobile broadband 634 wireless access systems", October 2005. 636 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 637 for IP Version 6 (IPv6)", RFC 2461, December 1998. 639 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 640 Autoconfiguration", RFC 2462, December 1998. 642 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 643 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 645 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 646 Carney, "Dynamic Host Configuration Protocol for IPv6 647 (DHCPv6)", RFC 3315, July 2003. 649 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 650 Architecture", RFC 4291, February 2006. 652 [8] Wasserman, M., "Recommendations for IPv6 in Third Generation 653 Partnership Project (3GPP) Standards", RFC 3314, 654 September 2002. 656 [9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 657 December 1998. 659 [10] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and 660 R. Wheeler, "A Method for Transmitting PPP Over Ethernet 661 (PPPoE)", RFC 2516, February 1999. 663 [11] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 664 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 666 [12] "IEEE, Virtual Bridged Local Area Networks, IEEE 802.1Q", 667 May 2003. 669 [13] "IEEE, Port-based Network Access Control, IEEE 802.1X", 670 December 2004. 672 Author's Address 674 Syam Madanapalli (editor) 675 LogicaCMG 676 125 Yemlur P.O. 677 Off Airport Road 678 Bangalore 560037 679 India 681 Email: smadanapalli@gmail.com 683 Full Copyright Statement 685 Copyright (C) The Internet Society (2006). 687 This document is subject to the rights, licenses and restrictions 688 contained in BCP 78, and except as set forth therein, the authors 689 retain all their rights. 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Intellectual Property 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 The IETF invites any interested party to bring to its attention any 718 copyrights, patents or patent applications, or other proprietary 719 rights that may cover technology that may be required to implement 720 this standard. Please address the information to the IETF at 721 ietf-ipr@ietf.org. 723 Acknowledgment 725 Funding for the RFC Editor function is provided by the IETF 726 Administrative Support Activity (IASA).