idnits 2.17.1 draft-michaelson-4byte-as-representation-01.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. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 2006) is 6342 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Michaelson 3 Request for Comments: DRAFT APNIC 4 Expires December 2006 6 Canonical representation of 4-byte AS numbers 8 draft-michaelson-4byte-as-representation-01.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 Proposed canonical 4-byte AS representation 35 Abstract 37 A single representation for 4-byte AS numbers is proposed, to avoid 38 any confusion in interpreting the two 2-byte quantities that make 39 them. The syntax chosen avoids collision with BGP community string 40 parsing of AS numbers. 42 It is recommended that only this representation be used by all 43 documents and systems referring to 4-byte AS numbers. 45 Nomenclature 47 4 Byte AS numbers are defined in [1]. 49 It is proposed that 4-byte AS Numbers are represented using a syntax 50 of 52 .. 54 Accordingly, a 4-byte AS Number of value 65546 (decimal) would be 55 represented as the string "1.10". 57 Terminology 59 "2-byte only AS Numbers" refers to AS Numbers in the range 0 - 65535 61 "4-byte only AS Numbers" refers to AS Numbers in the range 1.0 - 62 65535.65535 (decimal range 65,536 - 4,294,967,295) 64 "4-byte AS Numbers" refers to AS Numbers in the range 0.0 - 65 65535.65535 (decimal range 0 - 4,294,967,295) 67 Discussion 69 To avoid confusion, a single notation to represent a 4-byte AS value 70 is required. This is for use in documentation, configuration systems, 71 and external tools and information repositories. 73 Initially, the ":" was proposed to separate the 2-byte components. 74 However this clashes with use of the ":" character in community 75 attribute syntax in BGP and this would have required changes to the 76 routing systems code base in ways which are not acceptable. 78 It is believed that the ":" character would also interfere with the 79 parsing of RPSL objects. This also is not acceptable. 81 The "." denoted representation does not present these problems. 83 This notation has been informally adopted by at least one vendor, and 84 used consistently in presentations in the RIR community towards the 85 deployment of 4-byte AS. Therefore it seems sensible to formalize its 86 use as the preferred representation of a 4-byte AS across the board. 88 Author's Note: 90 This proposal was motivated by a discussion with Geoff Huston. The 91 text of the definition of a 4-byte AS is taken from [2]. 93 The author thanks R�diger Volk and Joao Damas for feedback and 94 comments on this draft. 96 Security Considerations 98 Many systems treat xxx.yyy numeric strings as real number values on 99 input, and convert internally to a canonical floating point 100 representation. Since the precision cannot be guaranteed to be 101 preserved, this risks changing the value of the 32-bit quantity on 102 output, or by mis-placed mathematical calculation. 104 Care must be taken that 4-byte AS are treated as special-purpose 105 strings on input and output, and parsed correctly to a 32 bit 106 quantity. It would be sensible to draft suitable function definitions 107 to define the transform from presentation to internal value, as was 108 done for IPv4 and IPv6 addresses with the inet_pton() and inet_ntop() 109 functions. 111 RPSL needs to be reviewed for conformance with 4-byte AS 112 deployment, and for the syntactic implications of this 113 representation. 115 Author's Address: 117 George Michaelson 118 APNIC 119 Level 1, 33 Park Road, Milton, Q4064 Australia 121 References 123 [1] http://www1.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt 124 [2] http://www.ripe.net/ripe/policies/proposals/2005-12.html 126 Comments & Feedback 128 Comments are solicited and should be addressed to the working group's 129 mailing list at idr@ietf.org and/or the author. 131 Authors email address 133 ggm@apnic.net 135 Copyright Declaration 137 Copyright (C) The Internet Society (2006). 139 This document is subject to the rights, licenses and restrictions 140 contained in BCP 78, and except as set forth therein, the authors retain 141 all their rights." 143 "This document and the information contained herein are provided on an 144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 146 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 147 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 148 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 149 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.