<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-jilongwang-opsawg-cybersmap-03" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="the native Cyberspace Map">Design of the native Cyberspace Map</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Jilong Wang" initials="WJL" role="editor"
           surname="Wang">
     <organization>Tsinghua University</organization>

     <address>
       <postal>
         <street></street>

         <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>

         <region></region>

         <code>100084</code>

         <country>China</country>
       </postal>
       
       <phone></phone>
       
       <email>wjl@tsinghua.edu.cn</email>
       
       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>
  
       
   <author fullname="Congcong Miao" initials="MCC" role="editor"
     surname="Miao">
     <organization>Tsinghua University </organization>
     
     <address>
       <postal>
         <street></street>
         
         <!-- Reorder these if your country does things differently -->
         
         <city>Beijing</city>
         
         <region></region>
         
         <code>100084</code>
         
         <country>China</country>
       </postal>
       
       <phone></phone>
       
       <email>1010988944@qq.com</email>
       
       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>
  
  <author fullname="Changqing An" initials="ACQ" role="editor"
     surname="An">
     <organization>Tsinghua University </organization>
     
     <address>
       <postal>
         <street></street>
         
         <!-- Reorder these if your country does things differently -->
         
         <city>Beijing</city>
         
         <region></region>
         
         <code>100084</code>
         
         <country>China</country>
       </postal>
       
       <phone></phone>
       
       <email>acq@tsinghua.edu.cn</email>
       
       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>


 <author fullname="Shuying Zhuang" initials="ZSY" role="editor"
     surname="Zhuang">
     <organization>Tsinghua University </organization>
     
     <address>
       <postal>
         <street></street>
         
         <!-- Reorder these if your country does things differently -->
         
         <city>Beijing</city>
         
         <region></region>
         
         <code>100084</code>
         
         <country>China</country>
       </postal>
       
       <phone></phone>
       
       <email>17751034616@163.com</email>
       
       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>
    

     
   <date year="2020" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Management</area>

   <workgroup>opsawg</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>Internet-Draft</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>This memo discusses the design of the native cyberspace map which is stable and flexible to describe cyberspace. Although we have accepted the cyberspace as a parallel new world, we even have not defined its basic coordinate system, which means cyberspace have no its basic space dimension till now. The objective of this draft is to illustrate the basic design methodology of the native coordinate system of cyberspace, and show how to design cyberspace map on this basis.
       </t>
  </abstract>
 </front>
 
 
<middle>

<section title="Introduction">
   <t>There is a new space created by Internet, together with computer networks, telecommunication networks, termed as cyberspace. It is an interactive domain that includes users, softwares, processes, information in storage or communication, applications, services .etc. Unfortunately, we even have not defined its basic coordinate system and even the native map. </t>
   
   <t>Traditional well known coordinate systems seem feasible to visualize and represent cyberspace. However, both coordinate systems have some drawbacks. Although geographic coordinate system(GCS) vividly shows geographic information of cyberspace in geographic map, it only visualizes a tip of iceberg of cyberspace and hardly describes the characteristics of cyberspace (e.g. host, service) all at the once from cyberspace point of view. Network coordinate system (NCS) focuses on visualizing network topology with node representing host (or IP address) and edge representing network distance between two hosts. NCS tries to represent and visualize cyberspace from network perspective. It is easy to hierarchically represent different parts of cyberspace in network topology map. However, NCS is a frequent change network due to distance changes and host connection status and it is difficult to visualize the whole cyberspace.  </t>
   
   
   <t>
   This demo discusses and defines a native cyberspace coordination model based on AS number and IP address following the principle of robustness, orthogonality and effectiveness. It can present cyberspace in a concise and intuitive manner and user can easily filter out the specific details of interest. Based on our cyberspace coordination model, we also propose a prototype system of native cyberspace map which can be used as the basic tool for network management, network security and network resources search .etc. The firstly proposed overall design methodology can help to establish the native cyberspace map as a unified backplane for visualization in the future.   </t>
         
     <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref
       target="RFC2119">RFC 2119</xref>.</t>
     </section>
</section>
  
   <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
   <?rfc needLines="8" ?>
   
   
  <section title="Terminology">
   
   <t>This document does not describe standard requirements. Therefore, key words from <xref target="RFC2119">RFC 2119</xref> are not used in the document.</t>
   <t>Manager:An entity that acts in a manager role, either a user or an application. The counterpart to an agent. A 'management client' in NETCONF terminology.</t>
   <t>IANA:Internet Assigned Numbers Authority, an organization that oversees global IP address allocation, autonomous system number allocation, media types, and other IP-related code point allocations.</t>

<t>Different granularities of cyberspace: representing the degree of visual cyberspace such as AS, Metropolitan area network, Local area network, IP blocks .etc.</t>
<t>Network resources: including physical resources such as traditional network facilities and access devices, as well as virtual resources such as application services and information resources, which can be detected using software or hardware tools based on certain methods, techniques and standards</t>

 </section>
   
 <section title="Use cases">
     <t>Our cyberspace map CAN provide a unified drawing backplane, and express the cyberspace in a multi-scale, multi-dimensional and multi-view way. Drawing the measured network data on the unified backplane CAN be skillfully applied to the expression of network resources, the monitoring and management <xref target="RFC1052">RFC 1052</xref> of network elements and the prevention of cyberspace security, etc. The following sections highlight some of the most common framework for native cyberspace map use case scenarios and are in no way exhaustive.</t>
   
<section title="Network Management">
       <t>Network resources management: The main concern of network managers is to have a direct and macroscopical visualization of network resources, so that they could manage network resources efficiently. In other words, based on the different sizes of network they manage, network managers have the demands to visualize network resources at different granularity. For example, network carriers mainly focus on the AS-level network and consider the resources with IP blocks, while the campus network administrators take care of the local area network and manage the resources at the specific IP addresses. Fortunately, our following Cyberspace map provides the ability to show the different granularities of cyberspace by setting the order n of Hilbert curve mapping algorithm.     </t>
    <t>Network traffic monitoring:Network traffic contains the information of IP addresses <xref target="RFC791">RFC 791</xref> and port. Therefore, the representing of network traffic in our cyberspace map is helpful for network managers to monitor the current network traffic status and realize network anomaly detection concisely and intuitively. At the large network level, monitoring traffic exchange between ISP networks is helpful to understand network traffic status, to realize quality of service analysis and congestion prediction, and to achieve reasonable bandwidth allocation between large networks. At the LAN level, regional traffic analysis is helpful to extract user network behavior characteristics. For example, monitoring TCP135 port traffic activity of target IP and discovering potential infection mode of Blaster worm CAN prompt closing abnormal host port to repair vulnerabilities for security management.
    </t>
   </section>
   
   
<section title="Network Security">
       <t>At present, network security problems are emerging one after another  <xref target="RFC3631">RFC 3631</xref>, how to detect and visualize these phenomena has always been the focus and difficulty of the network security and management field. Instead of physically attacking the physical host of geospatial, the security attacks usually involve virus infection against IP addresses and the vulnerabilities of corresponding hosts or perform DDoS attacks on specific IPs. Therefore, the traditional geographic coordinate system is difficult to reveal the original attack form of network. </t>
       <t> Our cyberspace map based on IP addresses CAN reveal security issues from a higher level. In detail, it CAN intuitively express the distribution of DDoS attackers and attacked IP addresses, and further express the spread of infected IP addresses. To Assist security analysts to better understand and prevent attacks, effectively cut off the infection transmission path, and implement attack shielding and prevention.
In addition, by telescopically displaying more specific information such as the AS, Network, and Organization to which the attacker IP belongs, it CAN help the corresponding network security administrators carry out effective vulnerability repair. </t>  
     </section>
             
 </section>
 
 <section title="Selection on Basic Coordinate Vectors"> 
<t>It is still suffering a big challenge to construct a native coordinate system, given the large amounts of network data and the ability to represent sufficient level of detail of interest to the different level of administrators. To tackle these problems, we look for the stable numbering system (coordination) in cyberspace as the basic coordinate vectors to construct the cyberspace coordinate system. With deep understanding of cyberspace, we observes a number of alternative choices such as IP address space, Autonomous System (AS) number space  <xref target="RFC4983">RFC 4983</xref> , MAC address space, Domain name space <xref target="RFC1034">RFC 1034</xref> and port number space <xref target="RFC6056">RFC 6056</xref>. These coordinates are stable and widely adopted that almost all objects in cyberspace possess them as identifiers so that they are able to project the cyberspace in its own space. We are discussing each coordination in the following:
</t>
   
    <section title="IP address">
     <t>An IP address is a unique fingerprint assigned to each host when connecting to network. It serves two primary functions. It is used as a network interface identification of host and it also provides the location of that host in cyberspace, similar to a physical address(longitude and latitude) in geographic space. An IP address is a unique address that makes it very suitable as a base vector in cyberspace. It locates host and allows host to send and receive information and communicate with a specific host in cyberspace. An IP address is composed of a fixed bit number, the total number of IP address is constant. Since the total number of IP address doesn't change with network status, it is a robust vector in cyberspace, defined as Address Space. </t>
   </section>
   
    <section title="Port">
     <t>An port number is composed of a 16-bit binary number with the fixed total number. An port number is often come up with an IP address when establishing a connection and is orthogonal to IP address. An IP address is the network address of a host in address space, while port number is the logic address of a specific service in that host. For instance, an address may be "IP address:216.38.1.15,port number:80", written as 216.38.1.15:80 which represents a web service on a specific host. An port number combining with an IP address locates relevant information in cyberspace at a finer granularity. While the total number of port also doesn't change with network status and it is orthogonal to address space, it is a suitable and robust vector for representing and visualizing cyberspace, defined as Logic Space. </t>
     
     </section>
   <section title="AS number">
     <t>ASN, defined for routing policy on the internet, is a collection of connected IP under the control of network operators. The AS number is composed of a 16-bit binary number with the fixed total number and the AS number is also a stable numbering system. Each AS contains a set of IP addresses and the relationship between IP address and AS are operated by RIRs. Therefore, AS is also regarded as the location of aggregated objects in cyberspace. Projecting the cyberspace into AS space provide the aggregated characteristics of IP address space. It is also an effective way to demonstrate cyberspace if the viewer want to visualize the AS level information of cyberspace such as the AS topology.</t>
     
    </section>
    <section title="MAC Address">
     <t>MAC address, defined as Media Access Control Address, is a unique identifier of network interfaces through a physical network segment. In other words, it's an identifier of hardware that uses Ethernet, which can also be referred as physical address or hardware address. Since the MAC address is the stable numbering system that is composed of 12 characters, so it could be used for the coordination of cyberspace. Furthermore, the cyberspace is created by the physical network resource with MAC address, so that we can project the cyberspace into MAC address space which is traced into each physical host. </t>
     
    </section>
    <section title="Domain Name">
     <t>Domain name is alphabetic which is easier to remember. For example, the domain name has a formed name e.g. www.apple.com, which is the identification of Apple company. Domain name is a stable numbering system which is not change with network status, however, it is impossible to enumerate because the length of domain name can be variable. Projecting the cyberspace into domain name space only provide the detailed web information of cyberspace. </t>
     
   </section>
   
  <section title='Conclusion'>
  <t>We discuss some alternatives that can be used as network space coordinates. Each coordinate is a candidate for constructing a cyberspace coordinate system. Obviously, projecting network space to MAC address space and domain name space is not very effective, which may lead to poor visualization of cyberspace. The former may lead to sparse visualization, because most MAC addresses are not connected to the Internet, while the latter only provides detailed network information considered as a small part of the cyberspace. As for IP address space, port space and AS space which can be regarded as the location of object in cyberspace, they can be selected as the basic coordinate vectors to demonstrate cyberspace. </t>
</section>
   
 </section>

   
  <section title="Construction of native Cyberspace Map">
   <t>After determining the basic coordinate vectors, i.e. IP address, port and AS, the specifications for the design of cyberspace maps based on these coordinates will be described in detail. Similar to ground military systems with 2-D horizontal coordinates or 3-D Cartesian coordinates, we define three types of map suitable for different scenarios.</t>
    <section title="IP Map">
    <t>Effectively presenting the IP address in our IP map is an extremely challenging problem for decades. One of the primary causes of this problem is that the total unique IP addresses is about 4 billion (IPv4), each of which needs to be visualized in the map. We have to make creative use of various techniques, and it is also significant to visualize IP addresses with meaningful aggregations where possible. The one-dimensional IP map expresses the network elements in the form of lines and points discretely and unintuitively. Therefore, we introduce the space filling curves to design a unified drawing backplane, and realize the association mapping between one-dimensional IP address space and two-dimensional IP address space. That is, the network is gathered to two-dimensional space plane with length and width are both the n-th power of 2, where n represents two-dimensional space order. The space filling curves mainly include Z curve, C curve, Gray curve, Hilbert curve.</t>
    <t>Hilbert space algorithm is optimal for the continuity and regional of space filling. It can shows a two-dimensional visualization of an IP block of 10.0.0.0.0/24, where the IP sub-blocks of 10.0.0.0/26,10.0.0.64/26,10.0.0.128/26 and 10.0.0.192/26 are adjacent. The Hilbert curves CAN provide people the ability to view cyberspace elements in aggregated or non-aggregated mode. For non-aggregated mode, the IPv4 address space REQUIRED the order n equals 32, which is preferable when detailed IP addresses need to be examined. While for aggregation mode, the order n needs changing for visualizing different granularities of cyberspace elements, which is beneficial when viewing data from an AS or a network backbone. For example, prefix 10.0.0.0/16 CAN be aggregated to a grid with setting the order equal to 8. Based on the Hilbert curve, the IP address could be extrapolated from one dimension into two dimension to generate the 2-D IP Map with coordinate(X,Y). </t>
  <t>It CAN be used in various security-related applications, such as network resources management, Internet interruption and secret scanning of Botnet coordination. compared to the geographic coordinate system ,it CAN realize the search, positioning and description of managed elements at different network levels (AS, Network, Organization, IP address)  instead of continuously zooming in geographic locations without a clear network hierarchy. It CAN represent multi-aspect information of cyberspace all at the once. In additional, benefit from the regionality and aggregation of our coordinate system, the administrator CAN perform unified management and configuration and operates on IP address blocks of key resources such as links and backbone networks.</t>
   </section>
   
   
   <section title="IP-Port Map">
    <t>In order to represent the detail information for cyberspace, it can extent the basic two-dimensional spatial plane drawn by the Hilbert curve mapping algorithm into the three-dimensional map by adding the logical port orthogonal to the IP address. Although the basic coordinate system constructed by the IP address can better locate the cyberspace elements to the corresponding hosts and visualize the IP attribute of the them, it would be difficult to describe cyberspace from different cognitive perspectives such as services, which are of great interest to people. Therefore, aside from the IP address, the logical port is RECOMMENDED to be used effectively to visualize cyberspace by constructing the 3-D IP-Port map.</t>
  <t>Specifically, the port numbers from 1 to 65536 CAN be represented on the z-axis and the height of each item CAN be used to visualize the traffic data of this port. In this three-dimensional IP-Port map, the traffic volume data that people concern about can be easily represented to perform diagnosis of flow anomaly. In addition, the different network aggregation of traffic data can be simply realized by zooming in/out. It CAN reflect the cyberspace elements more accurately and comprehensively compared to the two-dimensional IP map. It also CAN be used for application layer management, such as abnormal application monitoring and application layer traffic monitoring. </t>

   </section>
   <section title="AS Map">
    <t>The above IP map and IP-Port map constructed based on the IP address can better express cyberspace in most scenarios. They visualize the essential characteristics of the cyberspace (IP dimension space) compared to the geographic map, and retain the adjacent attributes between the IP addresses,express different granularities of cyberspace IP address prefixes, services, traffic .etc in aggregated or non-aggregated mode. In additional, the inherent existence of the IP address makes them more stable than the topological map. However, in some scenarios, such as representing the network traffic and attack characteristics of an AS in cyberspace, the assignment of IP address segments under an AS MAY be discontinuous, resulting in poor visualization of the IP address-based map, although continuous IP addresses remain adjacent through the Hilbert curve.</t>
    <t>Here we define a native AS map model to represent cyberspace. Similar to the IP map, we use the Hilbert mapping algorithm to visualize the one-dimensional ASN, and construct the two-dimensional coordinate plane(2-D AS Map) to represent the AS information, which is similar to the expression of national information by latitude and longitude in the geospatial model. </t>
    <t>Next, considering the IP address is a critical element of cyberspace, we also construct the 3-D IP-AS map model. The allocation time sequence of the IP address under the AS is RECOMMENDED to be a third-dimensional basic vector, which is orthogonal to the AS address, and its positive direction indicates the sequence is increasing, realizing the analysis and mapping of the IP address in cyberspace. Specifically, the Z-axis mapping algorithm is defined as follows:</t>
    <t>Input : an IP address P </t>
    <t>Output : the coordinate of Z-axis</t>
    <t>1. Get the AS where the address P is located based on the IP database.</t>
    <t>2. There are n IP addresses IPs=[IP1,IP2,IP3,IP4,IP5,IP6,...,IPn ] under this AS, and their corresponding allocation time is T=[T1,T2,T3,T4,T5,T6,...,Tn ], where the unallocated IP address allocation time is defined as MAXINT > max Allocated time[T1,T2,T3,T4,T5,T6,...,Tm], accurate to the second.</t>
    <t>3.	for i from 1 to n:</t>
    <t>4.     dict[IPs[i]]=T[i]</t>
    <t>5.     dictnew=sort(dict)</t>
    <t>6.     z= dictnew.index(P)</t>
    <t>7. return z</t>
 
    <t>z=10000 indicates that an IP address is located at the 10000th position after being sorted according to the allocation time. According to the Hilbert algorithm and the Z-axis mapping algorithm, the positioning coordinate (X, Y, Z) are used to analyze and map an IP address, and many cyberspace resource elements can be located based on the key identification IP address of communication.</t> 
<t>Instead of representing the topological relationship using abstract points and lines, it provides the ability to describe and express in a detail and native manner compared to the map of Internet topology. At the same time, the AS backplane is fixed so that some changes in links will not affect the entire map, which also reflects the superiority of AS Map.  </t>
    
  
   </section>
   
   
   
  </section>
   

   <section anchor="Acknowledgements" title="Acknowledgements">
   <t>The authors would like to thank the support of Tsinghua University and National Key Research and Development Program of China under Grant No.2016YFB0801301 and 2016QY12Z2103. 

   </t>

    
   </section>
    
   <!-- Possibly a 'Contributors' section ... -->

   <section anchor="IANA" title="IANA Considerations">
     <t>This memo includes no request to IANA.</t>
   </section>

   <section anchor="Security" title="Security Considerations">
     <t>This document only defines a framework for network resources categorization. 
        This document itself does not directly introduce security issues. </t>
   </section>
   



  </middle>
  

 <!--  *****BACK MATTER ***** -->

 <back>
   <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
    

     <reference anchor="RFC2119">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title>Key words for use in RFCs to Indicate
           Requirement Levels</title>

         <author initials="S." surname="Bradner">
           <organization>Harvard University</organization>
         </author>

         <date month="March" year="1997" />
       </front>
       <seriesInfo name="RFC" value="2119" />
     </reference>
   
   
   
    
    <reference anchor="RFC1052">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title>IAB Recommendations for the Development of
       Internet Network Management Standards</title>

         <author initials="V." surname="Cerf">
           <organization>IAB</organization>
         </author>

         <date month="April" year="1988" />
       </front>
       <seriesInfo name="RFC" value="1052" />
     </reference>

   
      <reference anchor="RFC791">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title>Internet protocol</title>

         <author initials="JB." surname="Postel">
                    </author>

         <date month="September" year="1981" />
       </front>
       <seriesInfo name="RFC" value="791" />
   </reference>
   
       <reference anchor="RFC3631">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title> Security Mechanisms for the Internet</title>

         <author initials="S." surname="Bellovin">
           <organization>Internet Architecture Board</organization>
         </author>

         <date month="December" year="2003" />
       </front>
       <seriesInfo name="RFC" value="3631" />
   </reference>
   
       <reference anchor="RFC4983">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title> BGP Support for Four-octet AS Number Space</title>

         <author initials="Q." surname="Vohra">
           <organization> Cisco Systems</organization>
         </author>

         <date month="May" year="2007" />
       </front>
       <seriesInfo name="RFC" value="4983" />
     </reference>


  <reference anchor="RFC1034">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title>DOMAIN NAMES - CONCEPTS AND FACILITIE</title>

         <author initials="P." surname="Mockapetris">
           <organization>ISI</organization>
         </author>

         <date month="November" year="1987" />
       </front>
       <seriesInfo name="RFC" value="1034" />
     </reference>
      
   
   
 
   
     <reference anchor="RFC6056">
       <!-- the following is the minimum to make xml2rfc happy -->
       <front>
         <title>Recommendations for Transport-Protocol Port Randomization</title>

         <author initials="M." surname="Larsen">
           <organization>UTN/FRH</organization>
         </author>

         <date month="January" year="2011" />
       </front>
       <seriesInfo name="RFC" value="6056" />
     </reference>
      
</references>
     
    
    
   


   

   <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                     year only, to be consistent with the comments. Updated the 
                     IANA guidelines reference from the I-D to the finished RFC.  -->
 </back>
</rfc>