idnits 2.17.1 draft-bo-behave-ref-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 5267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group B. Zhou 3 Internet-Draft H. Deng 4 Intended status: Informational China Mobile 5 Expires: April 29, 2010 October 26, 2009 7 Requirements for Referral in Mobile Network, input to GROBJ BoF 8 draft-bo-behave-ref-req-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document lays out the requirements that need to be met by the 47 potential referral modifications for the mobile network. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions used in this document . . . . . . . . . . . . . 3 53 2. Requirements of referral design . . . . . . . . . . . . . . . . 4 54 2.1. R1 Standard referral format . . . . . . . . . . . . . . . . 4 55 2.2. R2 Simplify ALG during NAT traversal . . . . . . . . . . . 4 56 2.3. R3 Network inspection consideration . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 Mobile operators are using referrals in their network to make 65 entities reachable straightforward. However, this simple approach is 66 failed by deployment of firewall and translator (like NAT) in the 67 network, in which causes the translation function happened during the 68 communication. This document is intended to discuss about the 69 requirements that need to be met by the potential referral 70 modifications in the mobile network. 72 1.1. Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Requirements of referral design 80 2.1. R1 Standard referral format 82 The referral formats need to be standardized. Applications can 83 understand the meaning of referral informed, such as IP address, 84 possibly protocol and port numbers. However, there is an open 85 question whether this standard referral design should be use for new 86 applications only, or including all existing applications. 88 2.2. R2 Simplify ALG during NAT traversal 90 There are middle boxes, like firewalls and translators, exist in the 91 mobile network, which cause applications need to do translations, 92 especially ALG. The cost of translation functions included ALG is 93 huge for the mobile operator in terms of implementation, performance. 94 Standard referral could simplify ALG implementation during NAT 95 traversal in the mobile network. 97 2.3. R3 Network inspection consideration 99 Operators sometimes need to inspect information or details during 100 communication for administration motivations. If referral format is 101 standardized, it is easy for operator to capture and investigate the 102 communication information they required. 104 3. Security Considerations 106 This document does not create any new security considerations. 108 4. IANA Considerations 110 This document does not require any IANA actions. 112 5. Normative References 114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 115 Requirement Levels", BCP 14, RFC 2119, March 1997. 117 Authors' Addresses 119 Bo Zhou 120 China Mobile 121 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 122 Beijing 100053 123 China 125 Email: zhouboyj@gmail.com 127 Hui Deng 128 China Mobile 129 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 130 Beijing 100053 131 China 133 Email: denghui02@gmail.com