idnits 2.17.1 draft-stupar-dime-mos-options-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 773. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 592 has weird spacing: '...ability is ...' -- 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 18, 2008) is 5911 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) == Missing Reference: 'RFC TBD' is mentioned on line 628, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 ** Downref: Normative reference to an Informational draft: draft-ietf-mipshop-mis-ps (ref. 'I-D.ietf-mipshop-mis-ps') == Outdated reference: A later version (-12) exists of draft-ietf-mipshop-mstp-solution-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE80221' -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and P. Stupar, Ed. 3 Extensions (DIME) NEC 4 Internet-Draft S. Das 5 Intended status: Standards Track Telcordia 6 Expires: August 21, 2008 J. Korhonen 7 Teliasonera 8 T. Melia 9 Cisco 10 February 18, 2008 12 Diameter extensions for MoS discovery 13 draft-stupar-dime-mos-options-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 IEEE 802.21 standard defines three distinct service types to 47 facilitate link layer handovers across heterogeneous technologies. 48 This document focuses on the Diameter Network Access Server (NAS) to 49 home Authentication, Authorization and Accounting server (HAAA) 50 interface defining a number of Diameters AVPs containing domain names 51 or IP addresses. Such information is related to IEEE 802.21 services 52 assisting a mobile node in handover preparation (network discovery) 53 and handover decision (network selection). 55 Requirements Language 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Mobility Service scenarios . . . . . . . . . . . . . . . . 5 67 3.2. Sequence of operations . . . . . . . . . . . . . . . . . . 6 68 4. Commands and AVP . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Command codes . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . 8 71 4.1.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . 9 72 4.1.3. AA-Request . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.4. AA-Answer . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Attribute Value Pair Definitions . . . . . . . . . . . . . 10 75 4.2.1. MIH-MoS-Info . . . . . . . . . . . . . . . . . . . . . 11 76 4.2.2. MIH-MoS-Address AVP . . . . . . . . . . . . . . . . . 11 77 4.2.3. MIH-MoS-FQDN AVP . . . . . . . . . . . . . . . . . . . 11 78 4.2.4. MIH-MoS-type AVP . . . . . . . . . . . . . . . . . . . 11 79 4.2.5. MIH-MoS-Capability AVP . . . . . . . . . . . . . . . . 12 80 5. AVP Information Tables . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Request and Response Commands AVP Table . . . . . . . . . 12 82 5.2. Mobility Services AVPs . . . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 6.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 13 85 6.2. New Registry: Mobility Services Capability . . . . . . . . 14 86 6.3. New Registry: Mobility Services Type . . . . . . . . . . . 14 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 93 Intellectual Property and Copyright Statements . . . . . . . . . . 18 95 1. Introduction 97 IEEE 802.21 [IEEE80221] defines three distinct service types to 98 facilitate link layer handovers across heterogeneous technologies. 99 In IEEE terminology these services are called Media Independent 100 Handover (MIH) services. The services are named Mobility Services 101 (MoS) and are the following: 103 Information Services (IS) IS provide a unified framework to the 104 higher layer entities across the heterogeneous network environment 105 to facilitate discovery and selection of multiple types of 106 networks existing within a geographical area, with the objective 107 to help the higher layer mobility protocols to acquire a global 108 view of the heterogeneous networks and perform seamless handover 109 across these networks. 111 Event Services (ES) ES provide a way to indicate changes in state 112 and transmission behavior of the physical, data link and logical 113 link layers, or predict state changes of these layers. The Event 114 Service may also be used to indicate management actions or command 115 status on the part of the network or some management entity. 117 Command Services (CS) CS enable higher layers to control the 118 physical, data link, and logical link layers. The higher layers 119 may control the reconfiguration or selection of an appropriate 120 link through a set of handover commands. 122 While these services may be co-located, the different pattern and 123 type of information they provide does not necessitate the co- 124 location, hence a server providing such services will not necessarily 125 host all the three of them together. A mobile node may make use of 126 any of these MIH service types separately or any combination of them. 128 [I-D.ietf-mipshop-mstp-solution] defines different reference 129 scenarios characterized by the location of the mobile node and the 130 MoS which can be discovered by the node. Some of the considered 131 scenarios enable the assignment of MoS provided the fact that the 132 scenario is of type integrated (see for reference 133 [I-D.ietf-mip6-bootstrapping-integrated-dhc]). In this case, 134 assignment is performed through the interaction between DHCP and AAA 135 frameworks, assuming the definition of extensions aimed at conveying 136 MoS information. [I-D.bajko-mos-dhcp-options] defines the DHCP 137 extensions and this document focuses on the Diameter extensions. 139 2. Terminology 140 Mobility Services (MoS) Those services, as defined in the MIH 141 problem statement document [I-D.ietf-mipshop-mis-ps] , which 142 include the MIH IS, CS, and ES services defined by the IEEE 802.21 143 standard. 145 Home Mobility Services (MoSh) Mobility Services assigned in the 146 mobile node's Home Network. 148 Visited Mobility Services (MoSv) Mobility Services assigned in the 149 Visited Network. 151 3rd Party Mobility Services (MoS3) Mobility Services assigned in a 152 3rd Party Network, which is a network that is neither the Home 153 Network nor the current Visited Network. 155 Authentication, Authorization and Accounting (AAA) A set of network 156 management services that respectively determine the validity of a 157 user's ID, determine whether a user is allowed to use network 158 resources, and track users' use of network resources. 160 Home AAA server (HAAA) An AAA server located in the MN's home 161 network. 163 Visited AAA server (VAAA) An AAA server located in the network 164 visited by the MN. 166 Mobile Node (MN) An Internet device whose location changes, along 167 with its point of connection to the network. 169 Network Node (NN) An Internet device whose location and network 170 point of attachment do not change. 172 Mobility Server (MS) A NN providing a MoS. It can be located in the 173 home network, in a visited network or in a 3rd party network. 175 Access Service Authorizer (ASA) A network operator that 176 authenticates a mobile node and establishes the mobile node's 177 authorization to receive Internet service. 179 Access Service Provider (ASP) A network operator that provides 180 direct IP packet forwarding to and from the end host. 182 3. Overview 184 IEEE 802.21 [IEEE80221] defines three distinct service types (see 185 [I-D.ietf-mipshop-mstp-solution]) to facilitate link layer handovers 186 across heterogeneous technologies. As these services have different 187 characteristics and purpose, a Mobility Server does not necessarily 188 host all three of these services together, thus there is a need to 189 define a solution enabling the discovery of each MoS or of a set 190 containing all or part of them. 192 This draft integrates the MoS discovery solution defined in 193 [I-D.ietf-mipshop-mstp-solution] and focuses on the required Diameter 194 extensions in order to enable the use of DHCP to discover MoS located 195 both in home network and in the visited network. It focuses on the 196 interface between NAS and AAA and defines Diameter extensions 197 providing MoS-related information. 199 3.1. Mobility Service scenarios 201 [I-D.ietf-mipshop-mstp-solution] defines a solution to discover MoS. 202 As Mobility Servers can be located in different places, different 203 protocols may be used depending on their location ; to achieve this, 204 the mentioned document defines different scenarios characterized by 205 the position of the Mobility Servers. Such scenarios are the 206 following: 208 Scenario S1 (Home Network MoS): The MN and the services are located 209 in the home network. In this scenario, the MoS is referred as 210 MoSh. 212 Scenario S2 (Visited Network MoS): The MN is in the visited network 213 and mobility services are provided by the visited network. In 214 this scenario, the MoS is referred as MoSv. 216 Scenario S3 (Roaming MoS) The MN is located in the visited network 217 and mobility services are provided by the home network. In this 218 scenario, the MoS is referred as roaming MoS. 220 Scenario S4: Third party MoS The MN is in its home network or in a 221 visited network and services are provided by a 3rd party network 222 in this scenario, these MoS are referred as MoS3. 224 Scenarios S1, S2 and S3 are integrated as the ASA is the entity 225 establishing the authorization for the MN to use any MoS, located in 226 the home or in the visited network. As outlined in 227 [I-D.ietf-mipshop-mstp-solution], in these scenarios MoS can be 228 assigned through DHCP. To achieve this, an interaction between DHCP 229 and AAA is required. Such interaction requires that the NAS and the 230 DHCP Relay are co-located as shown in Figure 1, representing the 231 network elements and the layout taking as reference by this document. 233 Visited Network | Home Network 234 | 235 +--------------+ | +---------+ 236 | VAAA |<-------Diameter------>| HAAA | 237 +--------------+ | +---------+ 238 /\ | 239 || | 240 || +====+ | +====+ 241 Diameter |MoSv| | |MoSh| 242 || +====+ | +====+ 243 \/ | 244 +-----------------+ | 245 | NAS/ DHCP Relay | | 246 | Diameter Client| | 247 +-----------------+ | 248 /\ | 249 || | 250 802.1x,EAP, 251 DHCP 252 || 253 \/ 254 +--------+ 255 | MN | 256 +--------+ 258 Figure 1: Network elements layout 260 3.2. Sequence of operations 262 This section outlines the message flows and actions taken by the 263 network elements that are part of the integrated scenario of MoS 264 assignment. 266 |=======| |===============| |=============| |=======| |======| 267 MN DHCP Relay/NAS DHCP Server AAA MoS 268 |=======| |===============| |=============| |=======| |======| 269 | | | | | 270 | | | | | 271 |-------(1)------>|<-------(1)-------|-----(1)------>| | 272 | | | | | 273 | | | | | 274 | | | | | 275 | | | | | 276 | | | | | 277 |-------(2)------>|-------(2)------->| | | 278 | | | | | 279 |<----------------|<------(3)--------| | | 280 | | | | | 281 | | | | | 282 | | | | | 283 |<----------------|-------(4)--------|---------------|---------->| 285 Figure 2: Sequence of operations 287 (1) During AAA phase, MN gets authenticated and authorized by the 288 home AAA to get network access. At first MN interacts with the NAS 289 at the visited network, which in turns polls AAA infrastructure to 290 obtain MN access credentials. In this phase, AAA defines which MoS 291 the MN can access to (i.e. if the authorized MoS are MoSh or MoSv and 292 which kind of services are provided). After the successfull 293 authentication and network access authorization, the AAA has provided 294 to the NAS the list of MoS (identified either by a FQDN or their IP 295 address) and the list of service (ES, CS, IS) they are able to 296 provide. To support the MoS assignment, the NAS MUST be able to 297 provide such MoS related information to the DHCP Relay colocated with 298 it. 300 (2) In this phase , node starts DHCP signalling to get the MoS 301 address. It sends a DISCOVER or INFORM message or 302 Information_request depending on supported IP version. In order to 303 request the MoS information, it inserts in the message MoS- 304 information options as described in [I-D.bajko-mos-dhcp-options]. 305 The DHCP Relay inserts the MoS information ( when it is available via 306 NAS) and forward it to the DHCP Server. 308 (3) In this phase DHCP server replies back to the received request by 309 introducing the collected MoS information, which the DHCP server 310 SHOULD extract from the Relay agent option whenever available. This 311 document doesn't specify any solution regarding the collection of MoS 312 information DHCP should make where no options are inserted by the 313 DHCP Relay agent. 315 After receiving the message back from the DHCP Server, the node owns 316 the list of the assigned MoS and can start using the available 317 services (4) as defined in [IEEE80221]. 319 4. Commands and AVP 321 This section contains Diameter specifications to convey MoS related 322 information from the HAAA to the NAS for the scenario described in 323 Section 3.2. It extends the HAAA-NAS interface by defining MoS 324 specific AVPs. This specification does not define any new Diameter 325 application. The AVPs defined in this specification MAY be used with 326 any present and the future Diameter application. As title of 327 example, messages defined in [RFC4072] and [RFC4005] are taken into 328 consideration. 330 4.1. Command codes 332 This section lists the Diameter commands used to convey MIH-MoS AVPs 333 in order to assign MoS-related information in the integrated scenario 334 described in Section 3.1 . Such commands are: 336 Command-Name Abbrev. Code Reference Application 338 Diameter-EAP-Request DER 268 RFC 4072 EAP 339 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 341 AA-Request AAR 265 RFC 4005 NASREQ 342 AA-Answer AAA 265 RFC 4005 NASREQ 344 Figure 3: MIPv6 Bootstrapping NAS to HAAA Interface Command Codes 346 4.1.1. Diameter-EAP-Request 348 The Diameter-EAP-Request (DER) message defined in [RFC4072], 349 indicated by the Command- Code field set to 268 and the 'R' bit set 350 in the Command Flags field, is sent by the NAS to the Diameter server 351 to initiate a network access authentication and authorization 352 procedure. The DER message format is the same as defined in 353 [RFC4072]. The message MAY include optional MIH-MoS AVPs: 355 ::= < Diameter Header: 268, REQ, PXY > 356 < Session-Id > 357 { Auth-Application-Id } 358 { Origin-Host } 359 { Origin-Realm } 360 { Destination-Realm } 361 { Auth-Request-Type } 363 * [ MIH-MoS-Info ] 364 [ MIH-MoS-Capability ] 366 [ User-Name ] 367 [ Destination-Host ] 368 ... 369 * [ AVP ] 371 4.1.2. Diameter-EAP-Answer 373 The Diameter-EAP-Answer (DEA) message defined in [RFC4072], indicated 374 by the Command-Code field set to 268 and 'R' bit cleared in the 375 Command Flags field, is sent in response to the Diameter-EAP-Request 376 message (DER). If the network access authentication procedure was 377 successful then the response MAY include any set of MIH-MoS AVPs. 378 The DEA message format is the same as defined in [RFC4072] with an 379 addition of optional MIH-MoS AVPs: 381 ::= < Diameter Header: 268, PXY > 382 < Session-Id > 383 { Auth-Application-Id } 384 { Auth-Request-Type } 385 { Result-Code } 386 { Origin-Host } 387 { Origin-Realm } 389 * [ MIH-MoS-Info ] 390 [ MIH-MoS-Capability ] 392 [ User-Name ] 393 ... 394 * [ AVP ] 396 4.1.3. AA-Request 398 The Diameter AA-Request (AAR) message defined in [RFC4005], indicated 399 by setting the Command-Code field to 265 and the 'R' bit in the 400 Command Flags field, is used to request authentication and/or 401 authorization for a given NAS user. The AAR message format is the 402 same as defined in [RFC4005]. The message MAY contain additional 403 MIH-MoS AVPs: 405 ::= < Diameter Header: 265, REQ, PXY > 406 < Session-Id > 407 { Auth-Application-Id } 408 { Origin-Host } 409 { Origin-Realm } 410 { Destination-Realm } 411 { Auth-Request-Type } 413 * [ MIH-MoS-Info ] 414 [ MIH-MoS-Capability ] 416 [ User-Name ] 417 [ Destination-Host ] 418 ... 419 * [ AVP ] 421 4.1.4. AA-Answer 423 The Diameter AA-Answer (AAA) message defined in [RFC4005], indicated 424 by setting the Command-Code field to 265 and clearing the 'R' bit in 425 the Command Flags field, is sent in response to the AA-Request (AAR) 426 message. If the network access authentication procedure was 427 successful then the response MAY include any set of MIH-MoS AVPs. 428 The AAA message format is the same as defined in [RFC4005] with an 429 addition of optional MIH-MoS AVPs: 431 ::= < Diameter Header: 265, PXY > 432 < Session-Id > 433 { Auth-Application-Id } 434 { Auth-Request-Type } 435 { Result-Code } 436 { Origin-Host } 437 { Origin-Realm } 439 * [ MIH-MoS-Info ] 440 [ MIH-MoS-Capability ] 442 [ User-Name ] 443 [ Destination-Host ] 444 ... 445 * [ AVP ] 447 4.2. Attribute Value Pair Definitions 449 This section defines the AVP introduced by this document. 451 4.2.1. MIH-MoS-Info 453 The MIH-MoS-Info AVP (AVP code TBD) is of type Grouped and contains 454 necessary information to assign a MoS to the MN. When the MIH-MoS- 455 Info AVP is present in a message, it MUST contain either a MIH-MoS- 456 Address AVP or a MIH-MoS-FQDN AVP, but not both: MIH-MoS-Address 457 SHOULD be preferred over MIH-MoS-FQDN. The grouped AVP has the 458 following grammar: 460 ::= < AVP Header: TBD > 461 [ MIH-MoS-Address ] 462 [ MIH-MoS-FQDN] 463 [ MIH-MoS-type] 464 * [ AVP ] 466 4.2.2. MIH-MoS-Address AVP 468 The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and 469 contains the MoS address. The Diameter server MAY decide to assign a 470 MoS to the MN depending on different reasons. For example, in case 471 of MoSv, MoS that is in close proximity to the point of attachment 472 (e.g., determined by the NAS-Identifier AVP) MAY be assigned. There 473 may be other reasons for dynamically assigning a MoS to the MN. 475 This AVP MAY also be attached by the NAS when sent to the Diameter 476 server in a request message as a hint of a locally assigned MoS 477 address. 479 4.2.3. MIH-MoS-FQDN AVP 481 The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8String and 482 contains the FQDN of a MoS. The usage of this AVP is equivalent to 483 the MIH-MoS-Address AVP but offers an additional level of indirection 484 via the DNS infrastructure. 486 4.2.4. MIH-MoS-type AVP 488 The MIH-MoS-type AVP (AVP Code TBD) is of type Unsigned 32 and 489 contains the type of MoS service the server supports. In case the 490 MoS-related information is reported, the all NULL MIH-MoS_type is 491 implicitly set. The following values are defined: 493 o IS_TYPE (0x00000001): this flag is set when the MoS provides 494 Information Service. 496 o ES_TYPE (0x00000002): this flag is set when the MoS provides Event 497 Service. 499 o CS_TYPE (0x00000004): this flag is set when the MoS provides 500 Command Service. 502 4.2.5. MIH-MoS-Capability AVP 504 The MIH-MoS-Capability AVP (AVP Code TBD) is of type Unsigned32 and 505 contains a 32 bits flags field of supported capabilities of the NAS/ 506 ASP. Sending and receiving the MIH-MoS-Capability AVP with value 0 507 MUST be supported. 509 The NAS MAY include this AVP to indicate capabilities of the NAS/ASP 510 to the Diameter server. For example, the NAS may indicate that a 511 local MoS can be provided. Similarly, the Diameter server MAY 512 include this AVP to inform the NAS/ASP about which of the NAS/ASP 513 indicated capabilities are supported or authorized by the ASA or by 514 the MoS authorizer. 516 The following capabilities are defined in this document: 518 o MoS_SERVCE_CAPABILITY (0x00000001) -- This flag indicates whether 519 the assignment of MoS information is supported or authorized. 521 o LOCAL_MoS_ASSIGNMENT (0x00000002) -- This flag indicates whether 522 the assignement of vMoS information is supported or authorized. 524 The NAS sets the MoS_SERVICE_CAPABILITY bit in order to communicate 525 to HAAA that the assignment of MoS is supported. The HAAA sets this 526 bit in order to allow MoS assignment through the solution outlined in 527 Section 3.2. 529 The LOCAL_MoS_ASSIGNMENT is set either by the NAS or by the VAAA when 530 a local MoS assignment is wished. Additional MIH-MoS-Info MAY be 531 inserted in order to provide a hint to the HAAA about the MoS the 532 visited network is willing to assign. This flag is set when the use 533 of a local MoS is allowed by the HAAA. In this case, HAAA MUST NOT 534 insert any MIH-MoS-Info it received by the visited network but MAY 535 insert own MIH-MoS-Info providing MoS FQDNs or addresses in order to 536 enable the NAS to chose the MoS (vMoS or hMoS) to assign to the MN. 538 5. AVP Information Tables 540 5.1. Request and Response Commands AVP Table 542 The following table lists the additional MoS related AVPs that may 543 optionally be present in any Request and Response, independent of the 544 used Diameter application. In the case the Diameter application 545 being used requires multiple round trips, then the Request and 546 Respone correspond to the first and the last messages of the multiple 547 round trips message exchange. 549 +-----------+ 550 | Cmd-Code | 551 |-----+-----+ 552 Attribute Name | Req | Rep | 553 -------------------------------|-----+-----| 554 MIH-MoS-Info | 0+ | 0+ | 555 MIH-MoS-Capability | 0-1 | 0-1 | 556 +-----+-----+ 558 Figure 9: Request and Response Commands AVP Table 560 5.2. Mobility Services AVPs 562 The following table describes the Diameter AVPs, their AVP Code 563 values, types, possible flag values, and whether the AVP MAY be 564 encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules 565 for AVPs in Section 4.2. 567 +---------------------+ 568 | AVP Flag rules | 569 +----+-----+----+-----+----+ 570 AVP Section | | |SHLD|MUST | | 571 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 572 ------------------------------------------+----+-----+----+-----+----+ 573 MIH-MoS-Info TBD 4.2.1 Grouped | | P | | V,M | Y | 574 MIH-MoS-Address TBD 4.2.2 Address | | P | | V,M | Y | 575 MIH-MoS-FQDN TBD 4.2.3 Grouped | | P | | V,M | Y | 576 MIH-MoS-Type TBD 4.2.4 Unsigned32 | | P | | V,M | Y | 577 MIH-MoS-Capability TBD 4.2.5 Unsigned64 | | P | | V,M | Y | 578 ------------------------------------------+----+-----+----+-----+----+ 580 Figure 10: AVP Flag Rules Table 582 6. IANA Considerations 584 6.1. Registration of new AVPs 586 This specification defines the following new AVPs: 588 MIH-MoS-Info is set to TBD 589 MIH-MoS-Address is set to TBD 590 MIH-MoS-FQDN is set to TBD 591 MIH-MoS-Type is set to TBD 592 MIH-MoS-Capability is set to TBD 594 6.2. New Registry: Mobility Services Capability 596 IANA is requested to create a new registry for the Mobility Services 597 Capability as described in Section 4.2.5. 599 Token | Value | Description 600 ----------------------------------+--------------+------------ 601 MoS_SERVCE_CAPABILITY | 0x00000001 | [RFC TBD] 602 LOCAL_MoS_ASSIGNMENT | 0x00000002 | [RFC TBD] 603 Available for Assignment via IANA | 2^x | 605 Allocation rule: Only numeric values that are 2^x (power of two) are 606 allowed based on the allocation policy described below. 608 Following the policies outlined in [RFC3775] new values with a 609 description of their semantic for usage with the MIH-MoS-Capability 610 AVP together with a Token will be assigned after Expert Review 611 initiated by the O&M Area Directors in consultation with the DIME 612 working group chairs or the working group chairs of a designated 613 successor working group. Updates can be provided based on expert 614 approval only. A designated expert will be appointed by the O&M Area 615 Directors. No mechanism to mark entries as "deprecated" is 616 envisioned. Based on expert approval it is possible to delete 617 entries from the registry. 619 6.3. New Registry: Mobility Services Type 621 IANA is requested to create a new registry for the Mobility Services 622 Type as described in Section 4.2.4. 624 Token | Value | Description 625 ----------------------------------+--------------+------------ 626 IS_TYPE | 0x00000001 | [RFC TBD] 627 ES_TYPE | 0x00000002 | [RFC TBD] 628 CS_TYPE | 0x00000004 | [RFC TBD] 629 Available for Assignment via IANA | 2^x | 631 Allocation rule: Only numeric values that are 2^x (power of two) are 632 allowed based on the allocation policy described in Section 6.2. 634 7. Security Considerations 636 The security considerations for the Diameter interaction required to 637 accomplish the MoS discovery are described in 638 [I-D.ietf-mipshop-mstp-solution]. Additionally, the security 639 considerations of the Diameter base protocol [RFC3588], Diameter 640 NASREQ application [RFC4005] and Diameter EAP [RFC4072] applications 641 (with respect to network access authentication and the transport of 642 keying material) are applicable to this document. This document does 643 not introduce new security vulnerabilities. 645 8. Acknowledgements 647 Authors would like to thank Victor Fajardo for the valuable comments 648 and support. 650 9. References 652 9.1. Normative References 654 [I-D.bajko-mos-dhcp-options] 655 Bajko, G. and S. Das, "Dynamic Host Configuration Protocol 656 (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) 657 discovery", draft-bajko-mos-dhcp-options-02 (work in 658 progress), February 2008. 660 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 661 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 662 Integrated Scenario", 663 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 664 progress), July 2007. 666 [I-D.ietf-mipshop-mis-ps] 667 Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y., 668 Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services 669 Transport: Problem Statement", 670 draft-ietf-mipshop-mis-ps-05 (work in progress), 671 November 2007. 673 [I-D.ietf-mipshop-mstp-solution] 674 Melia, T., Bajko, G., Das, S., Golmie, N., Xia, Z., and J. 675 Zuniga, "Mobility Services Framework Design", 676 draft-ietf-mipshop-mstp-solution-01 (work in progress), 677 February 2008. 679 [IEEE80221] 680 "Draft IEEE Standard for Local and Metropolitan Area 681 Networks: Media Independent Handover Services", IEEE LAN/ 682 MAN Draft IEEE P802.21/D07.00, July 2007. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 9.2. Informative References 689 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 690 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 692 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 693 in IPv6", RFC 3775, June 2004. 695 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 696 "Diameter Network Access Server Application", RFC 4005, 697 August 2005. 699 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 700 Authentication Protocol (EAP) Application", RFC 4072, 701 August 2005. 703 Authors' Addresses 705 Patrick Stupar (editor) 706 NEC 707 Kurfursten-Anlage 36 708 Heidelberg 69115 709 Germany 711 Phone: +49/(0)62214342215 712 Email: patrick.stupar@nw.neclab.eu 714 Subir Das 715 Telcordia 717 Phone: 718 Email: subir@research.telcordia.com 719 Jouni Korhonen 720 Teliasonera 721 Teollisuuskatu 13 722 Sonera FIN-00051 723 Finland 725 Email: jouni.korhonen@teliasonera.com 727 Telemaco Melia 728 Cisco 729 Avenue des Uttins 5 730 Rolle 1180 731 Switzerland (FR) 733 Email: tmelia@cisco.com 735 Full Copyright Statement 737 Copyright (C) The IETF Trust (2008). 739 This document is subject to the rights, licenses and restrictions 740 contained in BCP 78, and except as set forth therein, the authors 741 retain all their rights. 743 This document and the information contained herein are provided on an 744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 746 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 747 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 748 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 751 Intellectual Property 753 The IETF takes no position regarding the validity or scope of any 754 Intellectual Property Rights or other rights that might be claimed to 755 pertain to the implementation or use of the technology described in 756 this document or the extent to which any license under such rights 757 might or might not be available; nor does it represent that it has 758 made any independent effort to identify any such rights. Information 759 on the procedures with respect to rights in RFC documents can be 760 found in BCP 78 and BCP 79. 762 Copies of IPR disclosures made to the IETF Secretariat and any 763 assurances of licenses to be made available, or the result of an 764 attempt made to obtain a general license or permission for the use of 765 such proprietary rights by implementers or users of this 766 specification can be obtained from the IETF on-line IPR repository at 767 http://www.ietf.org/ipr. 769 The IETF invites any interested party to bring to its attention any 770 copyrights, patents or patent applications, or other proprietary 771 rights that may cover technology that may be required to implement 772 this standard. Please address the information to the IETF at 773 ietf-ipr@ietf.org. 775 Acknowledgment 777 Funding for the RFC Editor function is provided by the IETF 778 Administrative Support Activity (IASA).