CINXE.COM

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr" dir="ltr"><head> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1">  <base href="http://afrinic.net/fr/cpm-1-3"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta name="keywords" content="Manuel de politique consolid茅e, manuel de politique, politique, mise en 艙uvre, afrinic"> <meta name="author" content="Webmaster"> <meta name="description" content="CPM v1.3 - le Consolidated Policy Manual (CPM) est le document de r茅f茅rence contenant les politiques de gestion et de distribution des ressources de num茅ros IP dans la r茅gion de service AFRINIC. Les politiques sont cr茅茅es gr芒ce 脿 un processus ascendant d'茅laboration des politiques (PDP) de consultation, de discussion et de consensus 脿 travers lequel les propositions de politiques sont soumises, d茅battues (par la communaut茅) et adopt茅es (par AFRINIC). Toutes les politiques ratifi茅es et mises en 艙uvre qui sont pass茅es par le PDP sont int茅gr茅es au CPM."> <title>Manuel de politique consolid茅e (v1.3) - AFRINIC - Registre Internet r茅gional pour l'Afrique</title> <link href="http://afrinic.net/fr/cpm-1-3/amp?view=article&id=1606&lang=en" rel="amphtml"> <link href="http://afrinic.net/ast/img/afrinic-logo/afrinic-logo-a-favicon.png" rel="shortcut icon" type="image/vnd.microsoft.icon"> <link href="http://afrinic.net/templates/shaper_spectrum/favicon.ico" rel="shortcut icon" type="image/vnd.microsoft.icon"> <link href="http://afrinic.net/plugins/system/jcemediabox/css/jcemediabox.min.css?0072da39200af2a5f0dbaf1a155242cd" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/media/tabs/css/style.min.css?v=7.8.0" rel="stylesheet" type="text/css"> <link href="http://fonts.googleapis.com/css?family=Quicksand:300,regular,500,700&subset=latin" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/bootstrap.min.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/font-awesome.min.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/legacy.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/template.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/presets/preset3.css" rel="stylesheet" type="text/css" class="preset"> <link href="http://afrinic.net/templates/shaper_spectrum/css/custom.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/templates/shaper_spectrum/css/frontend-edit.css" rel="stylesheet" type="text/css"> <link href="http://afrinic.net/modules/mod_datetime/tmpl/default.css" rel="stylesheet" type="text/css"> <style type="text/css"> body{font-family:Quicksand, sans-serif; font-size:16px; font-weight:500; } h1{font-family:Quicksand, sans-serif; font-size:23px; font-weight:700; } h2{font-family:Quicksand, sans-serif; font-size:17px; font-weight:700; } h3{font-family:Quicksand, sans-serif; font-size:15px; font-weight:700; } h4{font-family:Quicksand, sans-serif; font-size:12px; font-weight:500; } h5{font-family:Quicksand, sans-serif; font-size:14px; font-weight:500; } h6{font-family:Quicksand, sans-serif; font-size:10px; font-weight:500; } .sp-megamenu-parent{font-family:Quicksand, sans-serif; font-size:15px; font-weight:500; } .card-cs { /* Add shadows to create the "card" effect */ box-shadow: 0 4px 8px 0 rgba(0,0,0,0.2); transition: 0.3s; width: 90%; } /* On mouse-over, add a deeper shadow */ .card-cs:hover { box-shadow: 0 8px 16px 0 rgba(0,0,0,0.2); } /* Add some padding inside the card container */ .container-cs { padding: 2px 16px; } .fa-bars:before { content: "\f0c9"; color: #d15e14; } CSS for Stats iframe on https://afrinic.net/ipv6-v2 .iframe-container { width: 100%; position: relative; overflow: hidden; padding-top: 100%; } .iframe-responsive { position: absolute; width: 100%; height: 100%; top: 0; right: 0; bottom: 0; left: 0; border: none; margin: 0px; padding: 0px; } .font9 { font-size: 12px; } .time { display: flex; justify-content: center; align-items: center; } #sp-utils-bar{ background-color:#000000;color:#ffffff;padding:0px 1.2em 0px 1.2em; } #sp-utils-bar a{color:#d15e14;} #sp-utils-bar a:hover{color:#ffffff;} #sp-header{ padding:0px auto 0px auto;margin:0px auto 5px auto; } #sp-main-body{ padding:0px 0px 10px 0px; } #sp-footer-menu{ background-color:#242e39;color:#ffffff;padding:20px 0px 5px 0px; } #sp-footer-menu a{color:#ffffff;} #sp-footer-menu a:hover{color:#d15e14;} #sp-bottom{ background-color:#242e39;color:#ffffff;padding:0px 0px 0px 0px;margin:0px; } #sp-bottom a{color:#ffffff;} #sp-bottom a:hover{color:#ffffff;} #sp-footer{ background-color:#242e39;color:#ffffff; } #sp-footer a{color:#d15e14;} .time { display: flex; justify-content: center; align-items: center; } </style> <script type="application/json" class="joomla-script-options new">{"csrf.token":"efaa6f5eda51c068a9dda954cd3e57bc","system.paths":{"root":"","base":""},"rl_tabs":{"use_hash":1,"reload_iframes":0,"init_timeout":0,"urlscroll":0}}</script> <script src="http://afrinic.net/media/jui/js/jquery.min.js?f5edda9a39a83880973f150b7d6459d2" type="text/javascript"></script> <script src="http://afrinic.net/media/jui/js/jquery-noconflict.js?f5edda9a39a83880973f150b7d6459d2" type="text/javascript"></script> <script src="http://afrinic.net/media/jui/js/jquery-migrate.min.js?f5edda9a39a83880973f150b7d6459d2" type="text/javascript"></script> <script src="https://cdn.printfriendly.com/printfriendly.js" type="text/javascript"></script> <script src="http://afrinic.net/media/system/js/caption.js?f5edda9a39a83880973f150b7d6459d2" type="text/javascript"></script> <script src="http://afrinic.net/plugins/system/jcemediabox/js/jcemediabox.min.js?d67233ea942db0e502a9d3ca48545fb9" type="text/javascript"></script> <script src="http://afrinic.net/media/system/js/core.js?f5edda9a39a83880973f150b7d6459d2" type="text/javascript"></script> <script src="http://afrinic.net/media/tabs/js/script.min.js?v=7.8.0" type="text/javascript"></script> <script src="http://afrinic.net/templates/shaper_spectrum/js/bootstrap.min.js" type="text/javascript"></script> <script src="http://afrinic.net/templates/shaper_spectrum/js/jquery.sticky.js" type="text/javascript"></script> <script src="http://afrinic.net/templates/shaper_spectrum/js/main.js" type="text/javascript"></script> <script src="http://afrinic.net/templates/shaper_spectrum/js/frontend-edit.js" type="text/javascript"></script> <script type="text/javascript"> var pfCustomCSS = ""; jQuery(window).on('load', function() { new JCaption('img.caption'); }); jQuery(document).ready(function(){WfMediabox.init({"base":"\/","theme":"standard","width":"","height":"","lightbox":0,"shadowbox":0,"icons":1,"overlay":1,"overlay_opacity":0.8,"overlay_color":"#000000","transition_speed":500,"close":2,"scrolling":"fixed","labels":{"close":"Close","next":"Next","previous":"Previous","cancel":"Cancel","numbers":"{{numbers}}","numbers_count":"{{current}} of {{total}}","download":"Download"}});}); jQuery(document).ready(function() { jQuery('#sp-left .nav.menu li.active.current > a ').css({"text-decoration":"underline","color":"black","background":"#cccccc"}); }); var sp_preloader = '0'; var sp_gotop = '1'; var sp_offanimation = 'slidetop'; </script> <meta property="og:url" content="http://afrinic.net/fr/cpm-1-3"> <meta property="og:type" content="article"> <meta property="og:title" content="Le guide collectif des politiques (v1.3)"> <meta property="og:description" content="Cette version CPM est remplac茅e par cette version CPM 脌 propos de l'historique des r茅visions CPM Abr茅viations 脌 propos de la version CPM 1.3 Cliquez ici pour afficher la liste des indivi ...">  <script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"WebSite","url":"https:\/\/afrinic.net/fr","potentialAction":{"@type":"SearchAction","target":"http:\/\/afrinic.net\/index.php?option=com_finder&q={search_term}","query-input":"required name=search_term"}}</script> <script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"Organization","url":"https:\/\/afrinic.net","logo":"http:\/\/afrinic.net\/ast\/img\/afrinic-logo\/afrinic_logo_mbl.png"}</script> <script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"Organization","name":"AFRINIC","url":"https:\/\/afrinic.net","sameAs":["https:\/\/www.facebook.com\/afrinic","https:\/\/twitter.com\/afrinic","https:\/\/www.instagram.com\/afrinic","https:\/\/www.youtube.com\/c\/AFRINIC","https:\/\/www.linkedin.com\/company\/afrinic","https:\/\/www.pinterest.com\/afrinic"]}</script> <script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"http:\/\/afrinic.net\/","name":"AFRINIC"}},{"@type":"ListItem","position":2,"item":{"@id":"http:\/\/afrinic.net\/participate","name":"Participer"}},{"@type":"ListItem","position":3,"item":{"@id":"http:\/\/afrinic.net\/policy","name":"D茅veloppement de politiques:"}},{"@type":"ListItem","position":4,"item":{"@id":"http:\/\/afrinic.net\/policy\/manual","name":"Guide collectif des politiques"}},{"@type":"ListItem","position":5,"item":{"@id":"http:\/\/afrinic.net\/policy\/manual\/archive","name":"Archive CPM"}},{"@type":"ListItem","position":6,"item":{"@id":"http:\/\/afrinic.net\/cpm-1-3","name":"Le guide collectif des politiques (v1.3)"}}]}</script> <script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"Article","mainEntityOfPage":{"@type":"WebPage","@id":"http:\/\/afrinic.net\/cpm-1-3"},"headline":"AFRINIC - Manuel de politique consolid茅e (CPM - v1.3)","description":"Le Consolidated Policy Manual (CPM) est le document de r茅f茅rence contenant les politiques de gestion et de distribution des ressources de num茅ros IP dans la r茅gion de service AFRINIC. Les politiques sont cr茅茅es gr芒ce 脿 un processus ascendant d'茅laboration des politiques (PDP) de consultation, de discussion et de consensus","image":{"@type":"ImageObject","url":"http:\/\/afrinic.net\/","height":800,"width":800},"author":{"@type":"Person","name":"AFRINIC"},"publisher":{"@type":"Organization","name":"AFRINIC","logo":{"@type":"ImageObject","url":"http:\/\/afrinic.net\/ast\/img\/afrinic-logo\/afrinic_logo_mbl.png","width":600,"height":60}},"datePublished":"2018-11-23T14:41:34+04:00","dateCreated":"2018-11-01T11:10:53+04:00","dateModified":"2018-11-23T14:41:36+04:00"}</script>  <link rel="canonical" href="https://afrinic.net/fr/cpm-1-3">  <script type="text/javascript" src="https://cdn.cookielaw.org/consent/ebd7abec-671f-4042-8ccd-8155e3b22dcb/OtAutoBlock.js"></script> <script src="https://cdn.cookielaw.org/scripttemplates/otSDKStub.js" data-document-language="true" type="text/javascript" charset="UTF-8" data-domain-script="ebd7abec-671f-4042-8ccd-8155e3b22dcb"></script> <script type="text/javascript"> function OptanonWrapper() { } </script>   <script async="" src="https://www.googletagmanager.com/gtag/js?id=G-H0GMQFDPXY"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-H0GMQFDPXY'); </script>  <script async="" src="https://www.googletagmanager.com/gtag/js?id=UA-50123650-5"></script> <script> window.dataLayer = window.dataLayer || [];https://afrinic.net/fr/administrator/index.php?option=com_templates&view=style&layout=edit&id=9#attrib-custom_code function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-50123650-5'); </script> <script async="" src="https://www.googleoptimize.com/optimize.js?id=GTM-N8QGHBV"></script> <meta name="msvalidate.01" content="ACFB632BA93AC365F6D32DAD41ACB173">  <script type="text/javascript" src="http://widget.trustpilot.com/bootstrap/v5/tp.widget.bootstrap.min.js" async=""></script> <script> (function(w,d,s,r,n){w.TrustpilotObject=n;w[n]=w[n]||function(){(w[n].q=w[n].q||[]).push(arguments)}; a=d.createElement(s);a.async=1;a.src=r;a.type='text/java'+s;f=d.getElementsByTagName(s)[0]; f.parentNode.insertBefore(a,f)})(window,document,'script', 'https://invitejs.trustpilot.com/tp.min.js', 'tp'); tp('register', 'IfBqKpPqdeexJeZo'); </script>   <script id="mcjs">!function(c,h,i,m,p){m=c.createElement(h),p=c.getElementsByTagName(h)[0],m.async=1,m.src=i,p.parentNode.insertBefore(m,p)}(document,"script","https://chimpstatic.com/mcjs-connected/js/users/5c91ad679775a26d1a2515314/a2c2eac2bbf6515fe5fe29fa3.js");</script> <meta name="google-site-verification" content="QsahxC0Hqcdk6Q-bS24gFVtlveVJJCTkqXaoYeuL04s"> </head> <body class="site com-content view-article no-layout no-task itemid-503 en-gb ltr layout-fluid off-canvas-menu-init"> <div class="body-wrapper"> <div class="body-innerwrapper"> <section id="sp-utils-bar" class=" hidden-xs"><div class="row"><div id="sp-top1" class="col-sm-1 col-md-4 hidden-sm hidden-xs"><div class="sp-column time"><div class="sp-module "><div class="sp-module-content"> <script type="text/javascript"> /* <![CDATA[ */ function doGTranslate(lang_pair) {if(lang_pair.value)lang_pair=lang_pair.value;if(lang_pair=='')return;var lang=lang_pair.split('|')[1];var plang=location.pathname.split('/')[1];if(plang.length !=2 && plang != 'zh-CN' && plang != 'zh-TW')plang='en';location.href=location.protocol+'//'+location.host+'/'+lang+'/cpm-1-3?view=article&id=1606&lang=en';} /* ]]> */ </script> <a href="http://afrinic.net/cpm-1-3?view=article&id=1606&lang=en" onclick="doGTranslate('en|en');return false;" title="English" class="flag nturl notranslate">English</a> <a href="http://afrinic.net/ar/cpm-1-3?view=article&id=1606&lang=en" onclick="doGTranslate('en|ar');return false;" title="丕賱毓乇亘賷丞" class="flag nturl notranslate">丕賱毓乇亘賷丞</a> <a href="http://afrinic.net/fr/cpm-1-3?view=article&id=1606&lang=en" onclick="doGTranslate('en|fr');return false;" title="Fran莽ais" class="flag nturl notranslate">Fran莽ais</a> <a href="http://afrinic.net/pt/cpm-1-3?view=article&id=1606&lang=en" onclick="doGTranslate('en|pt');return false;" title="Portugu锚s" class="flag nturl notranslate">Portugu锚s</a> </div></div></div></div><div id="sp-top-whois-faq" class="col-xs-6 col-sm-6 col-md-4"><div class="sp-column "><div class="sp-module "><div class="sp-module-content"> <div class="custom"> <p style="text-align: left;" class="gt-block"><span style="color: #;"> <strong> <a class="jcepopup noicon" style="color: #;" title="Web AFRINIC WHOIS Interface" href="/fr/whois?lang=en" data-mediabox="1" data-mediabox-title="AFRINIC Web WHOIS Interface">WHOIS Rechercher</a>              <a class="jcepopup noicon" style="color: #;" title="PORTAIL MEMBRES" href="https://my.afrinic.net/login" target="_blank" rel="noopener noreferrer" data-mediabox="1" data-mediabox-title="AFRINIC Web WHOIS Interface">SE CONNECTER 脌 MYAFRINIC</a></strong></span></p></div> </div></div></div></div><div id="sp-top3" class="col-xs-3 col-sm-3 col-md-4"><div class="sp-column time"><div class="sp-module "><div class="sp-module-content"><div class="itp-gs"> <form action="/fr/component/itpgooglesearch/search" method="get" accept-charset="utf-8"> <input name="gsquery" type="text" class="inputbox" placeholder="Rechercher..." value=""> </form> </div></div></div></div></div></div></section><header id="sp-header"><div class="container"><div class="row"><div id="sp-logo" class="col-xs-4 col-sm-4 col-md-3"><div class="sp-column "><div class="logo"><a href="/fr/"><img class="sp-default-logo hidden-xs" src="http://afrinic.net/ast/img/afrinic-logo/afrinic_logo.png" alt="AFRINIC - Registre Internet r茅gional pour l'Afrique"><img class="sp-retina-logo hidden-xs" src="http://afrinic.net/ast/img/afrinic-logo/afrinic_logo.png" alt="AFRINIC - Registre Internet r茅gional pour l'Afrique" width="202" height="85"><img class="sp-default-logo visible-xs" src="http://afrinic.net/ast/img/afrinic-logo/afrinic_logo.png" alt="AFRINIC - Registre Internet r茅gional pour l'Afrique"></a></div></div></div><div id="sp-menu" class="col-xs-8 col-sm-8 col-md-9"><div class="sp-column "> <div class="sp-megamenu-wrapper"> <a id="offcanvas-toggler" class="visible-sm visible-xs" href="#"><i class="fa fa-bars"></i></a> <ul class="sp-megamenu-parent menu-fade hidden-sm hidden-xs"><li class="sp-menu-item"></li><li class="sp-menu-item"></li><li class="sp-menu-item sp-has-child"><a href="/fr/about">脌 Propos</a><div class="sp-dropdown sp-dropdown-main sp-menu-right" style="width: 240px;"><div class="sp-dropdown-inner"><ul class="sp-dropdown-items"><li class="sp-menu-item"><a href="/fr/history">Notre Histoire</a></li><li class="sp-menu-item"><a href="/fr/partners">Nos partenaires</a></li><li class="sp-menu-item"><a href="/fr/membership">Adh茅sion</a></li><li class="sp-menu-item"><a href="/fr/service-region">Notre r茅gion de service</a></li><li class="sp-menu-item"><a href="/fr/agmm">AGMM</a></li><li class="sp-menu-item"><a href="/fr/membership/cost">Les Tarifs</a></li><li class="sp-menu-item"><a href="/fr/governance">Gouvernance</a></li><li class="sp-menu-item"><a href="/fr/stats">Statistique</a></li><li class="sp-menu-item"><a href="/fr/corporate-documents">Documents d'entreprise</a></li><li class="sp-menu-item"><a href="/fr/team">Notre 茅quipe </a></li><li class="sp-menu-item"><a href="/fr/contact">Contactez-nous</a></li></ul></div></div></li><li class="sp-menu-item sp-has-child"><a href="/fr/our-work">Notre Travail</a><div class="sp-dropdown sp-dropdown-main sp-menu-right" style="width: 240px;"><div class="sp-dropdown-inner"><ul class="sp-dropdown-items"><li class="sp-menu-item"><a href="/fr/membership">Services aux membres</a></li><li class="sp-menu-item"><a href="/fr/resources">Gestion des ressources des num茅ros Internet</a></li><li class="sp-menu-item"><a href="/fr/reverse-dns">DNS inverse</a></li><li class="sp-menu-item"><a href="/fr/whois">WHOIS</a></li><li class="sp-menu-item"><a href="/fr/membership/cost">Les Tarifs</a></li><li class="sp-menu-item"><a href="/fr/internet-routing-registry">Registre de routage Internet (IRR)</a></li><li class="sp-menu-item"><a href="/fr/dnssec">Programme DNSSEC</a></li><li class="sp-menu-item"><a href="/fr/resource-certification">Programme de certification des ressources (RPKI)</a></li><li class="sp-menu-item"><a href="/fr/corporate-documents">Documents d'entreprise</a></li><li class="sp-menu-item"><a href="http://learn.afrinic.net/" rel="noopener noreferrer" target="_blank">Services de formation</a></li><li class="sp-menu-item"><a href="/fr/support">Support et FAQ</a></li><li class="sp-menu-item"><a href="/fr/changelog">Changelog des services en ligne</a></li><li class="sp-menu-item"><a href="/fr/dns-support">Programme de support DNS</a></li><li class="sp-menu-item"><a href="/fr/root-server-copy">Programme de copie de serveur racine</a></li><li class="sp-menu-item"><a href="/fr/internet-development-programs">Programmes de d茅veloppement Internet</a></li></ul></div></div></li><li class="sp-menu-item sp-has-child alias-parent-active"><a href="/fr/participate">Participer</a><div class="sp-dropdown sp-dropdown-main sp-menu-right" style="width: 240px;"><div class="sp-dropdown-inner"><ul class="sp-dropdown-items"><li class="sp-menu-item"><a href="/fr/code">Code de Conduite </a></li><li class="sp-menu-item"><a href="/fr/email">E-mails et listes de diffusion</a></li><li class="sp-menu-item alias-parent-active"><a href="/fr/policy">D茅veloppement de politiques:</a></li><li class="sp-menu-item"><a href="/fr/committees/afgwg">Gouvernements</a></li><li class="sp-menu-item"><a href="/fr/committees">Comit茅s</a></li><li class="sp-menu-item"><a href="/fr/election-process">脡lections</a></li><li class="sp-menu-item"><a href="/fr/exhaustion"> 脡puisement IPv4 </a></li><li class="sp-menu-item"><a href="/fr/internet-governance">Gouvernance Internet</a></li><li class="sp-menu-item"><a href="/fr/privacy">politique de confidentialit茅</a></li><li class="sp-menu-item"><a href="/fr/participate-kpt/global-policies">Politiques globales</a></li></ul></div></div></li><li class="sp-menu-item sp-has-child"><a href="/fr/events">Ev猫nments</a><div class="sp-dropdown sp-dropdown-main sp-menu-left" style="width: 240px;"><div class="sp-dropdown-inner"><ul class="sp-dropdown-items"><li class="sp-menu-item"><a href="https://meeting.afrinic.net" rel="noopener noreferrer" target="_blank">R茅unions</a></li><li class="sp-menu-item"><a href="/fr/events/sponsorship">Possibilit茅s de sponsoring</a></li><li class="sp-menu-item"><a href="/fr/events/hosting-guide">Guide pour organiser une R茅union d'AFRINIC</a></li><li class="sp-menu-item"><a href="http://learn.afrinic.net/events" rel="noopener noreferrer" target="_blank">Ateliers de formation</a></li><li class="sp-menu-item"><a href="/fr/outreach">Outreach</a></li><li class="sp-menu-item"><a href="/fr/events/webinar-series">S茅rie de webinaires</a></li></ul></div></div></li><li class="sp-menu-item sp-has-child"><a href="/fr/news">M茅dias</a><div class="sp-dropdown sp-dropdown-main sp-menu-left" style="width: 240px;"><div class="sp-dropdown-inner"><ul class="sp-dropdown-items"><li class="sp-menu-item"><a href="/fr/news">Actualit茅s</a></li><li class="sp-menu-item"><a href="/fr/press">Communiqu茅s de presse</a></li><li class="sp-menu-item"><a href="/fr/presentations">Pr茅sentations</a></li><li class="sp-menu-item"><a href="/fr/factsheets">Fiches d'information</a></li><li class="sp-menu-item"><a href="/fr/newsletter">Infolettre</a></li><li class="sp-menu-item"><a href="/fr/branding">personnalis茅</a></li><li class="sp-menu-item"><a href="/fr/post-guidelines">Directives de contribution</a></li></ul></div></div></li><li class="sp-menu-item"><a href="https://blog.iso.afrinic.net/">Blog</a></li><li class="sp-menu-item"></li><li class="sp-menu-item"></li><li class="sp-menu-item"></li></ul> </div> </div></div></div></div></header><section id="sp-localisation-notice"><div class="row"><div id="sp-localisation-notice" class="col-sm-12 col-md-12"><div class="sp-column "><div class="sp-module "><div class="sp-module-content"> <div class="custom"> <div id="English-Notice" class="notranslate"> <div class="alert alert-info" style="text-align: center;"><i class="fa fa-exclamation-triangle" aria-hidden="true"></i> <strong>Info!</strong> Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.</div> </div></div> </div></div></div></div></div></section><section id="sp-main-body"><div class="row"><div id="sp-left" class="col-sm-2 col-md-3 hidden-sm hidden-xs"><div class="sp-column "><div class="sp-module "><h3 class="sp-module-title">Participer</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3757"><a href="/fr/global-policies"> Politiques globales</a></li><li class="item-547 active deeper parent"><a href="/fr/participate"> Participer</a><ul><li class="item-541"><a href="/fr/code"> Code de Conduite </a></li><li class="item-544"><a href="/fr/email"> E-mails et listes de diffusion</a></li><li class="item-549 active deeper parent"><a href="/fr/policy"> D茅veloppement de politiques:</a><ul><li class="item-501 active deeper parent"><a href="/fr/policy/manual"> Guide collectif des politiques</a><ul><li class="item-503 current active"><a href="/fr/policy/manual/archive"> Archive CPM</a></li><li class="item-724"><a href="/fr/cpm-pre"> Politiques pr茅-CPM</a></li></ul></li><li class="item-3494"><a href="/fr/policy/implementation-reports"> Rapports sur l'exp茅rience de mise en 艙uvre des politiques</a></li><li class="item-559"><a href="/fr/policy/proposals"> Propositions en discussion</a></li><li class="item-726"><a href="/fr/policy/discussion"> Discussion sur les politiques</a></li><li class="item-555"><a href="/fr/policy/appeal-committee"> Comit茅 d'appel</a></li><li class="item-552 deeper parent"><a href="/fr/policy/development-working-group"> PDWG</a><ul><li class="item-3747"><a href="/fr/policy/development-working-group/selection-process"> Processus de s茅lection</a></li></ul></li><li class="item-1474"><a href="/fr/policy/archive"> Archives de politique</a></li><li class="item-3748"><a href="/fr/policy/ppm-minutes"> Proc猫s-verbal de la r茅union des politiques publiques (PPM)</a></li></ul></li><li class="item-551 deeper parent"><a href="/fr/committees"> Comit茅s / GT</a><ul><li class="item-576"><a href="/fr/board/committees"> Comit茅s du conseil d'administration</a></li><li class="item-567"><a href="/fr/committees/election"> Comit茅 des 茅lections</a></li><li class="item-2390"><a href="/fr/committees/governance-committee"> Comit茅 pour la gouvernance</a></li><li class="item-564"><a href="/fr/committees/nomcom"> Comit茅 de nomination (NomCom)</a></li><li class="item-569"><a href="/fr/committees/aso-ac-nro-nc"> ASO-AC / NRO-NC</a></li><li class="item-574"><a href="/fr/committees/iana-review"> Transition IANA</a></li><li class="item-579"><a href="/fr/committees/afgwg"> GT des gouvernements AFRINIC (AfGWG)</a></li><li class="item-571"><a href="/fr/committees/database-wg"> GT de la base de donn茅es</a></li><li class="item-2960"><a href="/fr/committees/measurement-wg"> Groupe de travail sur la mesure d'Internet</a></li><li class="item-3411"><a href="/fr/committees/open-internet-standards-wg"> Groupe de travail sur les normes Internet ouvertes</a></li><li class="item-578"><a href="/fr/committees/archive"> Archive</a></li></ul></li><li class="item-585 deeper parent"><a href="/fr/election-process"> Processus 茅lectoraux</a><ul><li class="item-601"><a href="/fr/election-process/voting"> Vote</a></li><li class="item-2254"><a href="/fr/election-process/timeline"> Chronologie des 茅lections</a></li><li class="item-593 deeper parent"><a href="/fr/election-process/board"> 脡lection du conseil</a><ul><li class="item-3450"><a href="/fr/election-process/board/2022"> Processus d'茅lection du conseil d'administration (2022)</a></li></ul></li><li class="item-597"><a href="/fr/election-process/aso-nro"> 脡lection ASO AC</a></li><li class="item-599"><a href="/fr/election-process/nomcom"> NomCom</a></li></ul></li><li class="item-587"><a href="/fr/exhaustion"> 脡puisement IPv4 </a></li><li class="item-589"><a href="/fr/internet-governance"> Gouvernance Internet</a></li><li class="item-1515"><a href="/fr/privacy"> Politique de confidentialit茅</a></li></ul></li></ul> </div></div></div></div><div id="sp-component" class="col-xs-12 col-sm-12 col-md-9"><div class="sp-column "><div id="system-message-container"> </div> <article class="item item-page" itemscope="" itemtype="http://schema.org/Article"> <meta itemprop="inLanguage" content="en-GB"> <div class="gt-block entry-header" data-gt-block=""> <h1 itemprop="name"> Le guide collectif des politiques (v1.3) </h1> </div> <div itemprop="articleBody"> <p style="text-align: center;" class="gt-block"><strong><a href="/fr/policy/manual" rev="contents"><span style="color: #ff6600;">Cette version CPM est remplac茅e par cette version CPM</span></a></strong></p> <p style="text-align: center;"><span style="color: #ff6600;"><strong> </strong></span></p>  <div class="rl_tabs nn_tabs outline_handles outline_content top align_left" role="presentation">  <a id="rl_tabs-scrollto_1" class="anchor rl_tabs-scroll nn_tabs-scroll"></a> <ul class="nav nav-tabs" id="set-rl_tabs-1" role="tablist"> <li class="rl_tabs-tab nn_tabs-tab nav-item active"><a href="#about-cpm" title="脌 propos du CPM" class="rl_tabs-toggle nn_tabs-toggle nav-link" id="tab-about-cpm" data-toggle="tab" data-id="about-cpm" role="tab" aria-controls="about-cpm" aria-selected="true"><span class="rl_tabs-toggle-inner nn_tabs-toggle-inner">脌 propos du CPM</span></a></li> <li class="rl_tabs-tab nn_tabs-tab nav-item"><a href="#history" title="Historique des r茅visions" class="rl_tabs-toggle nn_tabs-toggle nav-link" id="tab-history" data-toggle="tab" data-id="history" role="tab" aria-controls="history" aria-selected="false"><span class="rl_tabs-toggle-inner nn_tabs-toggle-inner">Historique des r茅visions</span></a></li> <li class="rl_tabs-tab nn_tabs-tab nav-item"><a href="#abbreviations" title="Abr茅viations" class="rl_tabs-toggle nn_tabs-toggle nav-link" id="tab-abbreviations" data-toggle="tab" data-id="abbreviations" role="tab" aria-controls="abbreviations" aria-selected="false"><span class="rl_tabs-toggle-inner nn_tabs-toggle-inner">Abr茅viations</span></a></li> </ul>  <div class="tab-content"> <div class="tab-pane rl_tabs-pane nn_tabs-pane active" id="about-cpm" role="tabpanel" aria-labelledby="tab-about-cpm" aria-hidden="false"> <a id="anchor-about-cpm" class="anchor"></a> <h2 class="rl_tabs-title nn_tabs-title">脌 propos du CPM</h2> <div class="well"> <p class="gt-block"><span class="pull-left"><strong>Version 1.3 </strong></span> <span class="pull-right"><a href="/fr/cpm-pre?lang=en"><strong>Cliquez ici pour afficher la liste des politiques individuelles (pr茅-CPM)</strong></a></span></p> </div> <p class="well">Le guide collectif des politiques ou Consolidated Policy Manual (CPM) est le document de r茅f茅rence contenant les politiques de gestion et de distribution des ressources de num茅ros IP dans la r茅gion de service AFRINIC. Les politiques sont cr茅茅es gr芒ce 脿 un processus ascendant d'茅laboration des politiques (PDP) de consultation, de discussion et de consensus 脿 travers lequel les propositions de politiques sont soumises, d茅battues (par la communaut茅) et adopt茅es (par AFRINIC). Toutes les politiques ratifi茅es et mises en 艙uvre qui sont pass茅es par le PDP sont int茅gr茅es au CPM.</p> </div> <div class="tab-pane rl_tabs-pane nn_tabs-pane" id="history" role="tabpanel" aria-labelledby="tab-history" aria-hidden="true"> <a id="anchor-history" class="anchor"></a> <h2 class="rl_tabs-title nn_tabs-title">Historique des r茅visions</h2> <table class="table table-striped table-bordered table-hover table-responsive"> <tbody> <tr> <th>Date</th> <th>Version</th> <th>Commentaires en direct</th> </tr> <tr> <td> 01 novembre 2018</td> <td> CPM v1.3</td> <td> <p> Mise 脿 jour des sections suivantes 脿 partir des propositions politiques ratifi茅es respectives:</p> <ul> <li>IPv6 Mise 脿 jour de la politique et des r茅f茅rences (v 1.0): sections 6.0, 6.1 et 6.6.4.1. Supprim茅 le 6.5.4.2 pr茅c茅dent (qui est maintenant remplac茅 par le 6.5.4.3 pr茅c茅dent)</li> <li>IPv6 Mise 脿 jour de l'allocation initiale (v 2.0): sections 6.5.1.1, 6.5.1.2, 6.5.1.3 et 6.5.2.3</li> <li>IPv6 PI Update (v 1.0): Sections 6.8, 6.8.1, 6.8.2, 6.8.3 et nouvelle section 6.8.4</li> </ul> <p> </p> <p class="gt-block">Ajout d'une puce 脿 7.3 (b) - pour r茅pondre aux 4 octets ASN (politique globale) - <a href="/fr/policy/archive/amended-iana-policy-for-allocation-of-asn-blocks-to-rirs">https://afrinic.net/policy/archive/amended-iana-policy-for-allocation-of-asn-blocks-to-rirs</a></p> </td> </tr> <tr> <td>22 ao没t 2018</td> <td><a href="/fr/cpm-1-2?lang=en-GB">CPM v.1.2</a></td> <td> <ul> <li>Ajout de "10.7 Suppression de la d茅lagation" Lame "" pour la politique ratifi茅e "D茅l茅gations Lame dans AFRINIC reverse DNS (v02)"</li> </ul> </td> </tr> <tr> <td>01 Jul 2017 </td> <td><a href="/fr/cpm-1-1">CPM v1.1</a></td> <td> <ul> <li>Derni猫re mise 脿 jour: 26 July 2017</li> <li>Ajout de l'article 5.7 pour la politique ratifi茅e <a href="/fr/policy/archive/ipv4-resources-transfer-within-the-afrinic-region-v3" target="_blank" rel="noopener noreferrer">IPv4 Transferts au sein de la r茅gion AFRINIC.</a></li> <li>Ajout茅 <a href="/en/library/news/1211-implementation-of-the-no-reverse-unless-assigned-policy">Pas de marche arri猫re sauf si attribu茅</a> 脿 10.5 (pr茅c茅demment omis).</li> <li>R茅f茅rences mises 脿 jour pointant vers un contenu incorrect dans le CPM.</li> <li>Remplac茅 toutes les puces par des articles num茅rot茅s.</li> </ul> </td> </tr> <tr> <td>23 Jul 2016 </td> <td><a href="/fr/policy/manual/archive?lang=en" target="_blank" rel="prev noopener noreferrer">CPM v1.0</a></td> <td>R茅vis茅 pour inclure les politiques mises en 艙uvre depuis <a href="/fr/ast/pdf/services/CPM-v0-archived.pdf" target="_blank" rel="noopener noreferrer">initiale draft</a></td> </tr> <tr> <td>01 oct 2014</td> <td><a href="/fr/ast/pdf/services/CPM-v0-archived.pdf" target="_blank" rel="alternate noopener noreferrer">Initiales Draft</a></td> <td>Pr茅nom draft du CPM</td> </tr> </tbody> </table> </div> <div class="tab-pane rl_tabs-pane nn_tabs-pane" id="abbreviations" role="tabpanel" aria-labelledby="tab-abbreviations" aria-hidden="true"> <a id="anchor-abbreviations" class="anchor"></a> <h2 class="rl_tabs-title nn_tabs-title">Abr茅viations</h2> <ul> <li><strong>AFRINIC</strong>: Le Centre d'Information du R茅seau Africain</li> <li><strong>APNIC</strong>: Centre d'information du r茅seau Asie-Pacifique</li> <li><strong>ARIN</strong>: Registre am茅ricain des num茅ros Internet</li> <li><strong>SAW</strong>: Fen锚tre de sous-allocation</li> <li><strong>IANA</strong>: L'autorit茅 d'assignation des num茅ros internet</li> <li><strong>L'ICANN</strong>: Communaut茅 Internet pour les noms et num茅ros attribu茅s</li> <li><strong>IP</strong>: Protocole Internet</li> <li><strong>LACNIQUE</strong>: Centre d'information du r茅seau latino-am茅ricain et carib茅en</li> <li><strong>LIR</strong>: Registre Internet local</li> <li><strong>PA</strong>: Fournisseur agr茅geable</li> <li><strong>PI</strong>: Ind茅pendant du fournisseur</li> <li><strong>RIR</strong>: Registre Internet r茅gional</li> </ul> <p> </p> </div></div></div> <div> <table class="table table-responsive"> <tbody> <tr> <td> <div class="btn-group"><button class="btn btn-primary" type="button">Table des mati猫res</button> <button class="btn btn-primary dropdown-toggle" type="button" data-toggle="dropdown"> </button> <ul class="dropdown-menu"> <li><a href="#Introduction">1.0 Introduction</a></li> <li><a href="#General-Definitions">2.0 D茅finitions g茅n茅rales</a></li> <li><a href="#PDP">3.0 Le processus d'茅laboration des politiques (PDP)</a></li> <li><a href="#Scope-PDP">    3.1 Port茅e du PDP</a></li> <li><a href="#PDP-Principles">    3.2 Principes d'茅laboration des politiques</a></li> <li><a href="#PDWG">    3.3 Groupe de travail sur l'茅laboration des politiques (PDWG)</a></li> <li><a href="#PDP-Process">    3.4 Processus d'茅laboration des politiques</a></li> <li><a href="#Conflict-Resolutions">    3.5 R茅solution des conflits</a></li> <li><a href="#Varying-Process">    3.6 Varier le processus</a></li> <li><a href="#template">    Mod猫le 3.7</a></li> <li><a href="#Hierarchy">4.0 Hi茅rarchie de la r茅partition des ressources num茅riques</a></li> <li><a href="#IPv4">5.0 IPv4</a></li> <li><a href="#IPv4-Address-Space">    5.1 IPv4 Espace d'adressage</a></li> <li><a href="#Goals-Internet-Registry-System">    5.2 Objectifs du syst猫me de registre Internet</a></li> <li><a href="#Registration-Requirements">    5.3 Conditions d'inscription</a></li> <li><a href="#Soft-Landing">    5.4 Atterrissage en douceur</a></li> <li><a href="#lir-isp-allocation">    5.5 Attributions d鈥檃dresses IPv4 aux LIR et aux FAI</a></li> <li><a href="#IPv4-En-User-PI-Assignments">    5.6 IPv4 Affectations d'utilisateur final (PI)</a></li> <li><a href="#IPv4-Resource-Transfers-within-AFRINIC-Region">    5.7 IPv4 Transferts de ressources dans la r茅gion AFRINIC</a></li> <li><a href="#IPv6">6.0 IPv6</a></li> <li><a href="#Utilisation">    6.1 Utilisation</a></li> <li><a href="#HD-Ratio">    6.2 Rapport HD</a></li> <li><a href="#IPv6-Goals">    6.3 Objectifs de IPv6 gestion de l'espace d'adressage</a></li> <li><a href="#IPv6-Policy-Priciples">    6.4 IPv6 Principes de la politique</a></li> <li><a href="#Allocations-Assignments-Policies">    6.5 Politiques d'allocations et d'affectations</a></li> <li><a href="#Assignments-Internet-Experiments">    6.6 Affectations pour les exp茅riences Internet</a></li> <li><a href="#HD-T">    6.7 Ratio HD (HD) et seuil d'utilisation (T)</a></li> <li><a href="#PI-A">    6.8 Affectations PI</a></li> <li><a href="#ASN">7.0 ASN</a></li> <li><a href="#ASN-Intro">    7.1 Introduction</a></li> <li><a href="#ASN-Scope">    7.2 Scope</a></li> <li><a href="#ASN-Definition">    7.3 D茅finitions</a></li> <li><a href="#ASN-Eligibility">    7.4 Admissibilit茅脿 l'attribution d'un num茅ro AS</a></li> <li><a href="#Ownership-Routing">    7.5 Consid茅rations relatives 脿 la propri茅t茅 et au routage</a></li> <li><a href="#Assignment-Procedures">    7.6 Proc茅dures d'affectation</a></li> <li><a href="#Registration-Requirements-7-7">    7.7 Conditions d'inscription</a></li> <li><a href="#Returning-unused-ASNs">    7.8 Retour inutilis茅 ASNs</a></li> <li><a href="#Misc">    7.9 Divers</a></li> <li><a href="#Abuse-Contact">8.0 Coordonn茅es de l'abus</a></li> <li><a href="#Abuse-Contact-Intro">    8.1 Introduction</a></li> <li><a href="#AC-Policy">    8.2 D茅tails de la politique</a></li> <li><a href="#AD-Policy-Advantages-Disadvantages">    8.3 Avantages et inconv茅nients de la politique</a></li> <li><a href="#Temporary-Resource-Allocation">9.0 Allocation et affectation temporaires des ressources</a></li> <li><a href="#Temp-Doc">    9.1 Documenter l'activit茅 temporaire</a></li> <li><a href="#Assignments-IP-Resources">    9.2 Attribution des ressources IP</a></li> <li><a href="#Admin-Fees">    9.3 Frais administratifs</a></li> <li><a href="#Reverse-Delegation">10.0 D茅l茅gation invers茅e</a></li> <li><a href="#RD-Intro">    10.1 Introduction</a></li> <li><a href="#Obtaining-Delegation">    10.2 Obtention de la d茅l茅gation d'une sous-zone in-addr.arpa</a></li> <li><a href="#RD-PA">    10.3 D茅l茅gation invers茅e pour l'espace d'adressage d'agr茅gation de fournisseur (PA)</a></li> <li><a href="#RD-PI">    10.4 D茅l茅gation invers茅e pour l'espace adresse ind茅pendant du fournisseur (PI)</a></li> <li><a href="#RD-Validity">    10.5 Validit茅 de la d茅l茅gation invers茅e</a></li> <li><a href="#IPv6-RD">    10.6 IPv6 D茅l茅gation invers茅e</a></li> <li><a href="#lame">    10.7 Suppression des d茅l茅gations 'Lame'</a></li> <li><a href="#Resource-Reservations-IXPa">11.0 R茅servations de ressources pour les points d'茅change Internet</a></li> <li><a href="#Anycast">12.0 Affectations de ressources Anycast</a></li> </ul> </div> </td> <td> </td> </tr> </tbody> </table> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>1.0 <a id="Introduction"></a>Introduction</h2> </div> <div class="panel-body"> <p>Les politiques de gestion des ressources de num茅ros IP dans la r茅gion de service AFRINIC sont cr茅茅es 脿 travers un processus d'茅laboration des politiques (PDP) qui d茅crit les 茅tapes par lesquelles les propositions de politiques sont soumises, examin茅es, d茅battues (par la communaut茅) et adopt茅es (par AFRINIC). Ce document contient les politiques ratifi茅es et mises en 艙uvre qui sont pass茅es par le PDP.</p> <p>AFRINIC est une organisation ind茅pendante 脿 but non lucratif qui fait partie des cinq registres Internet r茅gionaux (RIRs). Sa r茅gion de service comprend le continent africain et une partie de l'oc茅an Indien (Seychelles, Maurice, Madagascar, Comores et R茅union).  </p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>2.0  <a id="General-Definitions"></a>D茅finitions g茅n茅rales</h2> </div> <div class="panel-body"> <p>Les termes suivants et leurs d茅finitions sont particuli猫rement importants pour la compr茅hension des objectifs, de l'environnement et des politiques d茅crits dans ce document.</p> <hr> <h3>2.1 Registre Internet (IR)</h3> <p>Un registre Internet (IR) est une organisation charg茅e de distribuer l'espace d'adressage IP 脿 ses clients et d'enregistrer ces adresses. Les RI sont class茅s selon leur fonction principale et leur port茅e territoriale dans la structure hi茅rarchique.</p> <hr> <h3>2.2 Registre Internet r茅gional (RIR)</h3> <p>Auparavant, les registres Internet r茅gionaux (RIR) 茅taient 茅tablis sous l'autorit茅 et les initiatives des communaut茅s Internet dans leurs r茅gions respectives. Actuellement, l'ICANN autorise l'茅tablissement de RIR pour servir et repr茅senter de grandes r茅gions g茅ographiques. Le r么le principal des RIR consiste 脿 g茅rer et distribuer l'espace d'adressage public dans leurs r茅gions respectives.</p> <p class="gt-block">Actuellement, il y a cinq RIRs: <a href="http://www.apnic.net/">APNIC</a>, <a href="http://www.arin.net/">ARIN</a>,<a href="http://www.lacnic.net/"> LACNIQUE</a>, <a href="http://www.ripe.net/">RIPE NCC</a> et AFRINIC.</p> <hr> <h3>2.3 Registre Internet local (LIR)</h3> <p>Un registre Internet local (LIR) est un RI qui re莽oit des attributions d'un RIR et qui alloue principalement l'espace d'adressage aux 芦 utilisateurs finaux 禄. Les LIR sont g茅n茅ralement des FAI. Leurs clients sont d'autres FAI et 茅ventuellement des utilisateurs finaux. Les LIR doivent 锚tre membres d'AFRINIC.</p> <hr> <h3>2.4 Attribution</h3> <p>芦 Attribuer 禄 signifie distribuer l'espace d'adressage aux LIR pour qu鈥檈ux-m锚mes les distribuent par la suite.</p> <hr> <h3>2.5 Sous-allocation</h3> <p>芦 Sous-attribuer 禄 signifie distribuer l'espace d'adressage (par les LIR) aux FAI pour qu鈥檈ux-m锚mes les distribuent par la suite.</p> <hr> <h3>2.6 Cession</h3> <p>Une assignation est un bloc d'adresses IP donn茅 par un LIR 脿 ses utilisateurs finaux pour leur propre usage. 芦 Assigner 禄 signifie d茅l茅guer un espace d'adressage 脿 un FAI ou 脿 un utilisateur final pour une utilisation sp茅cifique dans l'infrastructure Internet qu'ils op猫rent. Les assignations doivent uniquement 锚tre effectu茅es 脿 des fins sp茅cifiques document茅es par des organisations sp茅cifiques et ne peuvent 锚tre sous-attribu茅es 脿 d'autres parties.</p> <hr> <h3>2.7 Espace IP PA (Provider Aggregatable)</h3> <p>L'espace PA est ce qui a 茅t茅 allou茅 aux LIR 脿 partir duquel ils peuvent attribuer ou sous-allouer aux utilisateurs finaux / r茅seaux en aval en tant que bloc non portable. Si l'utilisateur final / le r茅seau en aval change de fournisseur, l'espace adresse attribu茅 ou sous-allou茅 par le fournisseur de services pr茅c茅dent (LIR) doit 锚tre renvoy茅 et le r茅seau renum茅rot茅.</p> <hr> <h3>2.8 Espace IP PI (ind茅pendant du fournisseur)</h3> <p>L'espace PI (ou portable) ne peut pas 锚tre agr茅g茅 et ne peut 锚tre attribu茅 que par RIR via un LIR. L'espace PI est co没teux 脿 acheminer et peut ne pas 锚tre routable 脿 l'茅chelle mondiale. Les sous-allocations ne peuvent pas 锚tre effectu茅es 脿 partir de ce type d'espace d'adressage par l'utilisateur final ou le LIR.</p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>3.0  <a id="PDP"></a>Le processus d'茅laboration des politiques (PDP)</h2> </div> <div class="panel-body"> <p>Cette section d茅crit le processus de d茅veloppement des politiques AFRINIC (PDP). Les politiques sont des d茅cisions document茅es de la communaut茅 AFRINIC qui d茅terminent directement les r猫gles selon lesquelles AFRINIC g猫re et administre les ressources de num茅ros Internet.</p> <p>Les proc茅dures d茅crites ici sont con莽ues pour 锚tre 茅quitables, ouvertes et objectives et visent 脿:</p> <p>a. Offrir 脿 toutes les parties int茅ress茅es de nombreuses possibilit茅s de participation et de commentaires;</p> <p>b. 脡tablir un large consensus sur la communaut茅 Internet.</p> <p>Ces proc茅dures adoptent des pratiques g茅n茅ralement accept茅es et offrent la souplesse n茅cessaire pour s'adapter 脿 diverses circonstances pouvant survenir dans un processus.</p> <hr> <h3>3.1  <a id="Scope-PDP"></a>Champ d鈥檃pplication du PDP</h3> <p>Le processus d'茅laboration des politiques couvre l'茅laboration et la modification des politiques de gestion des ressources de num茅ros Internet dans la r茅gion de service AFRINIC. Les modifications apport茅es au processus d'茅laboration des politiques lui-m锚me suivront 茅galement le processus.</p> <p>Les politiques en mati猫re de ressources de num茅ros Internet se distinguent clairement des pratiques op茅rationnelles et des proc茅dures g茅n茅rales d'AFRINIC, qui ne sont pas du ressort du PDP. </p> <hr> <h3>3.2  <a id="PDP-Principles"></a>Principes d'茅laboration des politiques</h3> <p>Toutes les politiques sont 茅labor茅es par la communaut茅 Internet selon les trois principes d'ouverture, de transparence et d'茅quit茅. La communaut茅 Internet initie et examine les propositions. Si un consensus est atteint sur le projet de politique, ledit projet est recommand茅 au Conseil d'administration d'AFRINIC pour 锚tre adopt茅 en tant que politique.</p> <h3>3.2.1 Ouverture</h3> <p>Toutes les politiques sont 茅labor茅es dans un forum ouvert auquel n'importe qui peut participer. La participation ne fait l鈥檕bjet d鈥檃ucune condition.</p> <h3>3.2.2 Transparence</h3> <p>Tous les aspects relatifs au processus d'茅laboration des politiques sont document茅s et rendus accessibles au public sur le site web d'AfriNIC. Les discussions sont archiv茅es publiquement. Toutes les proc茅dures 茅labor茅es pour mettre en 艙uvre la politique sont document茅es par AfriNIC et rendues accessibles au public.</p> <h3>3.2.3 脡quit茅</h3> <p>Les politiques doivent assurer une distribution 茅quitable des ressources et faciliter le fonctionnement d'Internet. Les mesures sont prises dans un d茅lai raisonnable.</p> <hr> <h3>3.3  <a id="PDWG"></a>Groupe de travail sur l'茅laboration des politiques (PDWG)</h3> <p class="gt-block">Le Groupe de travail sur l'茅laboration des politiques (PDWG) discute des propositions. Tout le monde peut participer via Internet ou en personne. Le travail du PDWG s'effectue via la liste de diffusion Discussion sur la politique des ressources (<span id="cloak39d22ca80d9bb83b3a612f2521d69557">cette adresse e-mail qui est prot茅g茅e du spam. Vous devez activer JavaScript pour la voir.</span><script type="text/javascript"> document.getElementById('cloak39d22ca80d9bb83b3a612f2521d69557').innerHTML = ''; var prefix = 'ma' + 'il' + 'to'; var path = 'hr' + 'ef' + '='; var addy39d22ca80d9bb83b3a612f2521d69557 = 'rpd' + '@'; addy39d22ca80d9bb83b3a612f2521d69557 = addy39d22ca80d9bb83b3a612f2521d69557 + 'afrinic' + '.' + 'net'; var addy_text39d22ca80d9bb83b3a612f2521d69557 = 'rpd' + '@' + 'afrinic' + '.' + 'net';document.getElementById('cloak39d22ca80d9bb83b3a612f2521d69557').innerHTML += '<a ' + path + '\'' + prefix + ':' + addy39d22ca80d9bb83b3a612f2521d69557 + '\'>'+addy_text39d22ca80d9bb83b3a612f2521d69557+'<\/a>'; </script>) et au cours des r茅unions semestrielles d'AFRINIC sur les politiques de l鈥橧nternet (PPM). Tout individu y participant en personne ou 脿 distance est consid茅r茅 comme faisant partie du Groupe de travail sur l'茅laboration des politiques.</p> <p>Le Groupe de travail sur l'茅laboration des politiques a deux pr茅sidents pour s'acquitter de ses fonctions administratives. Lesdits pr茅sidents sont 茅lus par la communaut茅 d鈥橝FRINIC lors de la r茅union sur les politiques de l鈥橧nternet et servent des mandats 茅chelonn茅s de deux ans. Leur mandat s鈥檃ch猫ve au cours de la premi猫re r茅union sur les politiques de l鈥橧nternet, ce qui correspond 脿 la fin du mandat pour lequel ils ont 茅t茅 nomm茅s. Un mandat peut commencer ou se terminer au plus t么t le premier jour de la r茅union sur les politiques de l鈥橧nternet et au plus tard le dernier jour de ladite r茅union, selon ce qui est 茅tabli d鈥檜n commun accord par le pr茅sident actuel et le nouveau pr茅sident.</p> <p>Si le pr茅sident du groupe de travail n'est pas en mesure de remplir son mandat, le groupe de travail peut choisir un rempla莽ant pour le reste du mandat. Si les pr茅sidents des groupes de travail ne peuvent assister 脿 la r茅union sur les politiques publiques, le groupe de travail nomme un pr茅sident pour la session. Toute personne pr茅sente 脿 la r茅union, en personne ou par participation 脿 distance, peut participer au processus de s茅lection d'un pr茅sident temporaire.</p> <hr> <h3>3.4  <a id="PDP-Process"></a>Processus d'茅laboration des politiques</h3> <p class="gt-block">Tout le monde peut soumettre une proposition. Les propositions de politique sont soumises 脿 la liste de diffusion Discussion sur la politique des ressources (<span id="cloakfbf6f809a7e933b991a6132a27a958fc">cette adresse e-mail qui est prot茅g茅e du spam. Vous devez activer JavaScript pour la voir.</span><script type="text/javascript"> document.getElementById('cloakfbf6f809a7e933b991a6132a27a958fc').innerHTML = ''; var prefix = 'ma' + 'il' + 'to'; var path = 'hr' + 'ef' + '='; var addyfbf6f809a7e933b991a6132a27a958fc = 'rpd' + '@'; addyfbf6f809a7e933b991a6132a27a958fc = addyfbf6f809a7e933b991a6132a27a958fc + 'afrinic' + '.' + 'net'; var addy_textfbf6f809a7e933b991a6132a27a958fc = 'rpd' + '@' + 'afrinic' + '.' + 'net';document.getElementById('cloakfbf6f809a7e933b991a6132a27a958fc').innerHTML += '<a ' + path + '\'' + prefix + ':' + addyfbf6f809a7e933b991a6132a27a958fc + '\'>'+addy_textfbf6f809a7e933b991a6132a27a958fc+'<\/a>'; </script>) par l'auteur. AFRINIC fournira un soutien administratif et assistera le ou les auteurs dans draftla proposition, si demand茅. AFRINIC fournira 茅galement des faits et des statistiques pertinents si n茅cessaire au cours de la discussion.</p> <h3>3.4.1 Draft Proposition de politique</h3> <p class="gt-block">Lors de l'茅laboration d'une politique, draft les versions du document sont mises 脿 disposition pour examen et commentaires en les publiant sur le site Web d'AFRINIC et en les affichant sur le <span id="cloak457a35865a9d25c0c6afa3e1e2062e2b">cette adresse e-mail qui est prot茅g茅e du spam. Vous devez activer JavaScript pour la voir.</span><script type="text/javascript"> document.getElementById('cloak457a35865a9d25c0c6afa3e1e2062e2b').innerHTML = ''; var prefix = 'ma' + 'il' + 'to'; var path = 'hr' + 'ef' + '='; var addy457a35865a9d25c0c6afa3e1e2062e2b = 'rpd' + '@'; addy457a35865a9d25c0c6afa3e1e2062e2b = addy457a35865a9d25c0c6afa3e1e2062e2b + 'afrinic' + '.' + 'net'; var addy_text457a35865a9d25c0c6afa3e1e2062e2b = 'rpd' + '@' + 'afrinic' + '.' + 'net';document.getElementById('cloak457a35865a9d25c0c6afa3e1e2062e2b').innerHTML += '<a ' + path + '\'' + prefix + ':' + addy457a35865a9d25c0c6afa3e1e2062e2b + '\'>'+addy_text457a35865a9d25c0c6afa3e1e2062e2b+'<\/a>'; </script> liste de diffusion. Chaque draft La politique se voit attribuer un identifiant unique par AFRINIC et le site Internet d'AFRINIC doit 茅galement contenir l'historique des versions et le statut de toutes les propositions.</p> <p>Le draft de la politique doit 锚tre disponible pour examen pendant au moins quatre semaines avant la prochaine r茅union de politique publique. Le ou les auteurs doivent apporter les modifications n茅cessaires au draft politique en fonction des commentaires re莽us. Le (s) pr茅sident (s) du groupe de travail peut demander 脿 AFRINIC de fournir une analyse (technique, financi猫re, juridique ou autre) de l'impact de draft proposition de politique.</p> <p>A draft la politique expire apr猫s une ann茅e civile 脿 moins qu'elle ne soit approuv茅e par le conseil d'administration de l'AFRINIC en tant que politique. Le d茅lai d'expiration est red茅marr茅 lorsque le draft la politique est remplac茅e par une version plus r茅cente de la proposition. UNE draft la politique peut 锚tre retir茅e par le ou les auteurs en envoyant une notification 脿 la liste de diffusion Resource Policy Discussion.</p> <h3>3.4.2 R茅union de politique publique</h3> <p>Le draft de la politique est inscrit 脿 l'ordre du jour d'une r茅union publique de politique publique. L'ordre du jour de la r茅union doit 锚tre annonc茅 sur la liste de diffusion Discussion sur la politique des ressources au moins deux semaines avant la r茅union. Aucune modification ne peut 锚tre apport茅e 脿 un draft politique dans la semaine suivant la r茅union. Ceci afin qu'une version stable du draft la politique peut 锚tre examin茅e lors de la r茅union. Le (s) pr茅sident (s) d茅termine (nt) si un consensus approximatif a 茅t茅 atteint lors de la r茅union sur les politiques publiques.</p> <p>Le (s) pr茅sident (s) publiera le proc猫s-verbal de la r茅union de politique publique au plus tard trois semaines apr猫s la r茅union.</p> <h3>3.4.3 Dernier appel</h3> <p>Un dernier examen du draft de la politique est initi茅e par le (s) pr茅sident (s) du groupe de travail en envoyant une annonce 脿 la liste de diffusion Discussion sur la politique des ressources. La p茅riode du dernier appel doit 锚tre d'au moins deux semaines. Le (s) pr茅sident (s) du groupe de travail 茅valuera les commentaires re莽us lors de la r茅union sur les politiques publiques et pendant cette p茅riode et d茅cidera si un consensus a 茅t茅 atteint.</p> <h3>3.4.4 Agr茅ment</h3> <p>Le (s) pr茅sident (s) du groupe de travail recommandera le draft politique au conseil d'administration d'AFRINIC pour approbation si elle a le consensus du groupe de travail sur l'茅laboration des politiques. La recommandation comprend un rapport sur les discussions du draft politique et commentaires du dernier appel. le draft la politique sera ratifi茅e par le Conseil d'Administration d'AFRINIC.</p> <h3>3.4.5 Mise en 艙uvre</h3> <p>La date d'adoption et de mise en 艙uvre de la politique est annonc茅e sur la liste de diffusion Resource Policy Discussion. La date de mise en 艙uvre doit 锚tre inf茅rieure 脿 six mois apr猫s la fin du dernier appel, sauf si une d茅rogation est demand茅e.</p> <hr> <h3>3.5  <a id="Conflict-Resolutions"></a>R茅solution de conflit</h3> <ol> <li>Une personne qui n'est pas d'accord avec les mesures prises par le (s) pr茅sident (s) doit discuter de la question avec le (s) pr茅sident (s) du PDWG ou avec le PDWG. Si le d茅saccord ne peut 锚tre r茅solu de cette mani猫re, la personne peut d茅poser un recours aupr猫s d'un comit茅 d'appel nomm茅 par le conseil d'administration d'AFRINIC. Un appel ne peut 锚tre d茅pos茅 que s'il est soutenu par trois (3) personnes du groupe de travail qui ont particip茅 aux discussions.</li> <li>L'appel doit 锚tre d茅pos茅 dans les deux semaines suivant la connaissance publique de la d茅cision. Le comit茅 d'appel remet un rapport sur son examen de la plainte au groupe de travail. Le comit茅 d'appel peut ordonner que la d茅cision du pr茅sident soit annul茅e si le processus d'茅laboration des politiques n'a pas 茅t茅 suivi.</li> <li>Toute personne peut demander le rappel d'un pr茅sident de groupe de travail 脿 tout moment, sur demande 茅crite avec justification au conseil d'administration d'AFRINIC. La demande doit 锚tre appuy茅e par au moins cinq (5) autres personnes du groupe de travail. Le conseil d'administration d'AFRINIC nommera un comit茅 de rappel, 脿 l'exclusion des personnes demandant le rappel et des pr茅sidents des groupes de travail. Le comit茅 de rappel doit enqu锚ter sur les circonstances de la justification du rappel et d茅terminer le r茅sultat.</li> </ol> <hr> <h3>3.6  <a id="Varying-Process"></a>Variation du processus</h3> <p>Le processus d茅crit dans le pr茅sent document peut varier en cas d'urgence. Toute variation serait apport茅e lorsqu'une renonciation ponctuelle d'une disposition du pr茅sent Guide est requise.</p> <ol> <li>La d茅cision de modifier le processus est prise par un pr茅sident de groupe de travail.</li> <li>Il doit y avoir une explication de la raison pour laquelle la variance est n茅cessaire.</li> <li>La p茅riode d'examen, y compris le dernier appel, ne doit pas 锚tre inf茅rieure 脿 quatre semaines.</li> <li>S'il y a consensus, la politique est approuv茅e et doit 锚tre pr茅sent茅e 脿 la prochaine r茅union de politique publique.</li> </ol> <hr> <h3>3.7  <a id="template"></a>Mod猫le de projet de politique</h3> <p>Le draft Le texte de la proposition de politique doit 锚tre soumis sur le mod猫le suivant:</p> <table class="table table-striped table-bordered table-hover table-responsive"> <tbody> <tr> <td colspan="2"> <p>Nom de la proposition:</p> </td> </tr> <tr> <td> <p>ID: (attribu茅 par AFRINIC)</p> </td> <td> <p>Date de soumission:</p> </td> </tr> <tr> <td> <p>Auteur:</p> </td> <td> <p>Version:</p> </td> </tr> <tr> <td> <p>Obsol猫tes:</p> </td> <td> <p>Modifie:</p> </td> </tr> <tr> <td colspan="2"> <p>1. Le probl猫me trait茅 par cette proposition.</p> </td> </tr> <tr> <td colspan="2"> <p>2. Comment cette proposition r茅sout le probl猫me.</p> </td> </tr> <tr> <td colspan="2"> <p>3. Proposition</p> <ul> <li>Veuillez utiliser la sous-num茅rotation pour faciliter le r茅f茅rencement.</li> <li>La proposition doit montrer les sections exactes 脿 modifier et le contenu qui doit 锚tre ajout茅 ou supprim茅 du CPM.</li> </ul> </td> </tr> <tr> <td colspan="2"> <p>4. R茅f茅rences.</p> </td> </tr> <tr> <td colspan="2"> <p>5. Historique des r茅visions.</p> </td> </tr> </tbody> </table> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>4.0 <a id="Hierarchy"></a>Hi茅rarchie de la distribution des ressources num茅riques</h2> </div> <div class="panel-body"> <p>Les ressources de num茅ros Internet sont r茅parties dans une structure hi茅rarchique dans laquelle l'IANA (Internet Assigned Numbers Authority) alloue des blocs de ressources num茅riques 脿 AFRINIC, qui seront redistribu茅s dans toute la r茅gion africaine. AFRINIC redistribue 脿 ses membres et leur d茅l猫gue 茅galement le pouvoir d'effectuer des affectations et des sous-allocations aux clients le cas 茅ch茅ant et conform茅ment aux politiques et proc茅dures d茅crites dans ce document.</p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>5.0 <a id="IPv4"></a>IPv4</h2> </div> <div class="panel-body"> <p>Cette section d茅crit les directives pour une gestion responsable IPv4 espace d'adressage dans la r茅gion de service AFRINIC. Les lignes directrices sont 茅labor茅es dans le cadre d'un processus d'茅laboration des politiques ouvert et ascendant du Groupe de travail sur l'茅laboration des politiques.</p> <hr> <h3>5.1  <a id="IPv4-Address-Space"></a>Espace d'adressage IPv4 </h3> <p>Aux fins du pr茅sent document, les adresses IPv4 sont des nombres binaires 32 bits (utilis茅s comme identifiants de la protocole IPv4) et sont g茅n茅ralement de trois types:</p> <p>5.1.1 Adresses IP publiques / globales qui sont attribu茅es pour 锚tre globalement uniques selon les objectifs d茅crits dans la section 5.2 de ce document.</p> <p>5.1.2 Priv茅 IPv4 l'espace d'adressage est r茅serv茅 pour une utilisation en priv茅 IPv4 r茅seaux. Tout le monde peut utiliser ces adresses dans ses r茅seaux priv茅s sans inscription. H么tes avec priv茅 IPv4 les adresses ne peuvent pas 锚tre atteintes depuis Internet 脿 moins d'锚tre activ茅es via NAT (Network Address Translation). Notez que certains services Internet peuvent ne pas fonctionner correctement sous NAT. Voir RFC 2993 pour les implications techniques / d'ing茅nierie de l'utilisation de NAT. La RFC1918 d茅crit 茅galement les blocs r茅serv茅s 脿 un usage priv茅.</p> <p>5.1.3 Plages IP r茅serv茅es aux exp茅riences:</p> <p class="gt-block">Ils sont d茅crits dans la RFC3330 (<a href="http://www.ietf.org/rfc/rfc3330.txt">http://www.ietf.org/rfc/rfc3330.txt)</a>.</p> <p>Certaines plages sont 茅galement r茅serv茅es 脿 la multidiffusion.</p> <hr> <h3>5.2  <a id="Goals-Internet-Registry-System"></a>Objectifs du syst猫me de registre Internet</h3> <h3>5.2.1 Objectifs</h3> <p>Il est du devoir principal d'AFRINIC, en tant que gardien d'une ressource publique, de veiller 脿 ce que IPv4 allocations et affectations, les objectifs suivants sont atteints:</p> <p class="gt-block">5.2.1.1 <strong>Unicit茅</strong> - Afin que chaque h么te de l'Internet public puisse 锚tre identifi茅 de mani猫re unique, chaque monodiffusion publique IPv4 l'adresse doit 锚tre unique au monde.</p> <p class="gt-block">5.2.1.2 <strong>Enregistrement</strong> - Chaque affectation et allocation d'espace d'adressage Internet public doit 锚tre enregistr茅e dans l'AFRINIC whois base de donn茅es. Cela est n茅cessaire pour garantir l'unicit茅 et pour fournir des informations pour le d茅pannage Internet 脿 tous les niveaux.</p> <p class="gt-block">5.2.1.3 <strong>Agr茅gation</strong> - La distribution hi茅rarchique des adresses IPv4 permet l'agr茅gation des informations de routage. Cela permet d'assurer le bon fonctionnement du routage Internet et de limiter l'extension des tables de routage Internet (RFC2519).</p> <p class="gt-block">5.2.1.4 <strong>Conservation</strong> - Pour maximiser la dur茅e de vie de la ressource d'espace d'adressage Internet public, les adresses doivent 锚tre distribu茅es en fonction des besoins r茅els et sur la base d'une utilisation imm茅diate. Par cons茅quent, le stockage de l'espace d'adressage et le maintien des r茅servations doivent, en g茅n茅ral, 锚tre 茅vit茅s.</p> <h3>5.2.2 Conflit d'objectifs</h3> <p>Les objectifs de conservation et d'agr茅gation sont souvent en conflit les uns avec les autres. Certains ou tous les objectifs peuvent parfois 锚tre en conflit avec les int茅r锚ts des RI individuels ou des utilisateurs finaux. Par cons茅quent, les RI 茅valuant les demandes d'allocations et d'assignations doivent analyser soigneusement toutes les consid茅rations pertinentes et doivent chercher 脿茅quilibrer les besoins du demandeur avec les besoins de la communaut茅 Internet dans son ensemble. Ces politiques visent 脿 aider les RI 脿茅quilibrer 茅quitablement ces besoins. La documentation du processus d茅cisionnel pour chaque affectation ou mission permet de garantir la transparence et l'honn锚tet茅 du processus.</p> <h3>5.2.3 Documentation</h3> <p>Afin d'茅valuer correctement les demandes, un RIR doit examiner attentivement toute la documentation pertinente relative aux r茅seaux en question. Cette documentation peut comprendre des plans d'ing茅nierie de r茅seau, des plans de sous-r茅seautage, des descriptions de la topologie de r茅seau et des descriptions de plans de routage de r茅seau. Toute la documentation doit 锚tre conforme 脿 une norme coh茅rente et toutes les estimations et pr茅visions document茅es doivent 锚tre r茅alistes et justifiables.</p> <h3>5.2.4 脡quit茅</h3> <p>Toutes les politiques et pratiques relatives 脿 l'utilisation de l'espace de diffusion publique s'appliqueront de mani猫re juste et 茅quitable 脿 tous les membres actuels et potentiels d'AFRINIC, quels que soient leur emplacement, leur nationalit茅, leur taille ou tout autre facteur.</p> <hr> <h3>5.3  <a id="Registration-Requirements"></a>Exigences en mati猫re d鈥檈nregistrement</h3> <p>5.3.1 Toutes les communications avec AFRINIC se feront en anglais.</p> <p>5.3.2 Toutes les allocations, affectations PI, affectations PA, sous-allocations et autres types d'affectations de ressources seront enregistr茅es dans la base de donn茅es AFRINIC. Toutes les ressources non enregistr茅es seront consid茅r茅es comme non valides. Les donn茅es d'enregistrement (nom, bloc / plage IP, contacts, 茅tat, etc.) doivent 锚tre correctes 脿 tout moment. Cela est n茅cessaire pour prendre en charge les op茅rations r茅seau.</p> <hr> <h3>5.4  <a id="Soft-Landing"></a>Atterrissage en douceur</h3> <p>Cette section d茅crit comment AFRINIC doit attribuer, allouer et g茅rer IPv4 ressources pendant la "phase d'茅puisement" qui commence lorsque AFRINIC doit d'abord attribuer ou allouer des adresses IP 脿 partir du bloc final / 8 de IPv4 espace d'adressage.</p> <p>Afin d'assurer une transition en douceur vers IPv6, Le pool d'AFRINIC devrait 锚tre g茅r茅 de mani猫re 脿 fournir aux membres un espace d'adressage IPv4 la piscine est 茅puis茅e. Cela aidera 脿 maintenir IPv4 r茅seaux lors du d茅ploiement IPv6 r茅seaux - une pratique qui caract茅rise la p茅riode de transition. Cette section propose une strat茅gie d'allocation et d'affectation et de maintenance des AFRINIC IPv4 piscine apr猫s 茅puisement. L'application de la politique 芦d'atterrissage en douceur禄 commence lorsque AFRINIC commence 脿 allouer de l'espace 脿 partir du dernier IANA allou茅 / 8.</p> <p>Ce IPv4 La politique d'atterrissage en douceur s'applique 脿 la gestion de l'espace d'adressage qui sera disponible pour AFRINIC apr猫s la IPv4 la piscine est 茅puis茅e. Le but de ce document est de s'assurer que l'espace d'adressage est attribu茅 et / ou allou茅 d'une mani猫re acceptable pour la communaut茅 AFRINIC, en particulier pendant cette p茅riode de IPv4 茅puisement.</p> <p class="gt-block"><strong>5.4.1 D茅finitions sp茅cifiques 脿 la section Soft-Landing:</strong></p> <ol> <li><strong>LIR existants</strong> - Un LIR existant est un LIR qui attribue un espace d'adressage aux 芦utilisateurs finaux禄 et a d茅j脿茅t茅 attribu茅 ou allou茅 IPv4 espace d'adressage par AFRINIC.</li> <li><strong>Nouveau LIR</strong> - Un nouveau LIR, est un LIR qui attribue un espace d'adressage aux 芦utilisateurs finaux禄 et est membre d'AFRINIC mais n'a pas 茅t茅 affect茅 ou allou茅 IPv4 l'espace d'adressage avant la phase d'茅puisement.</li> <li><strong>Utilisateur</strong> - Un utilisateur final est une organisation qui re莽oit des attributions d'adresses IP exclusivement 脿 utiliser dans ses r茅seaux op茅rationnels</li> <li><strong>Blocs / 8 finaux de espace d'adressage IPv4 ou "Final / 8"</strong> - Le bloc Final / 8 de l'espace d'adressage IPv4 , ou "Final / 8", est le bloc / 8 de IPv4 espace d'adressage qui a 茅t茅 allou茅 par l'IANA 脿 AFRINIC en termes de la section 2.2 C du Global <a href="https://www.icann.org/resources/pages/remaining-ipv4-2012-02-25-en">Global Policy for the Allocation of the Remaining IPv4 Address Space </a> au moment de l'茅puisement du pool IANA de IPv4 espace d'adressage.</li> </ol> <p class="gt-block"><strong>5.4.2 Phase actuelle.</strong></p> <p>La 芦 Phase actuelle 禄 est le statu quo au moment de l'adoption de la politique d'atterrissage en douceur. Au cours de cette phase, AfriNIC continue d'allouer ou d'attribuer des adresses IPv4 aux LIR et aux utilisateurs finaux en ayant recours aux directives de politique d'attribution et d'affectation d茅j脿 en place.</p> <p>La phase actuelle se poursuivra jusqu'脿 ce qu'une demande de validit茅 IPv4 l'espace d'adressage de n'importe quel LIR ou utilisateur final 脿 AFRINIC soit:</p> <ol> <li>ne peut aboutir 脿 partir de l'espace d鈥檃dressage IPv4 disponible dans le pool d鈥檃dresses d鈥橝friNIC (脿 l'exception du dernier bloc /8), ou</li> <li>peut 锚tre satisfaite, mais viderait le pool d'adresses IPv4 d鈥橝friNIC (脿 l'exception du dernier bloc /8).</li> </ol> <p>La demande qui aboutit 脿 la satisfaction de l'une des conditions ci-dessus sera la derni猫re</p> <p>La demande qui remplit l'une des conditions ci-dessus sera la derni猫re demande d'espace adresse IPv4 qu'AfriNIC acceptera de tout LIR ou utilisateur final dans la phase en cours. Si la demande peut 锚tre trait茅e conform茅ment aux politiques de la phase en cours, elle sera trait茅e de la sorte ; sinon, elle sera trait茅e en fonction des politiques de la Phase d'茅puisement.</p> <p>AFRINIC annoncera publiquement que la phase d'茅puisement a commenc茅脿 ce stade. Pour 茅viter tout doute, toutes les demandes qui sont actuellement en cours 脿 ce stade seront 茅valu茅es conform茅ment 脿 la nouvelle politique.</p> <p class="gt-block"><strong>5.4.3 Phase d'茅puisement</strong></p> <p>Pendant la phase d'茅puisement, les directives d'allocation et d'affectation suivantes seront utilis茅es. Ils s'appliquent aux LIR et aux utilisateurs finaux, ainsi qu'脿 tous les IPv4 l'espace d'adressage allou茅, attribu茅 ou autrement g茅r茅 par AFRINIC pendant la transition vers et apr猫s le d茅but de la phase d'茅puisement, ind茅pendamment du fait IPv4 l'espace d'adressage fait partie de la finale / 8. La phase d'茅puisement sera divis茅e en deux parties:</p> <p class="gt-block"><strong>5.4.3.1 Phase d'茅puisement 1</strong></p> <p>Au cours de cette phase, l'allocation / l'attribution de l'espace d'adressage se poursuivra comme dans la phase actuelle (/ 24 pour une UE et / 22 pour une LIR) mais le maximum passera de / 10 脿 / 13.</p> <p>Les attributions et les affectations seront faites 脿 partir de la finale / 8 ou de tout autre IPv4 l'espace d'adressage disponible pour AFRINIC, jusqu'脿 ce qu'un maximum de / 11 d'espace non r茅serv茅 soit disponible dans la finale / 8. 脌 ce stade, la phase d'茅puisement 2 commencera. Pour 茅viter tout doute, toutes les demandes qui seront en cours 脿 ce stade seront 茅valu茅es conform茅ment 脿 la nouvelle politique.</p> <p class="gt-block"><strong>5.4.3.2 Phase d'茅puisement 2</strong></p> <p>Au cours de cette phase, la taille minimale d'allocation / affectation sera / 24, et le maximum sera / 22 par allocation / affectation.</p> <p class="gt-block"><strong>5.4.4 Pour tout LIR ou utilisateur final demandant IPv4 espace d'adressage pendant l'茅puisement: </strong></p> <p>Il n'y a pas de limite explicite au nombre de fois o霉 une organisation peut demander l'espace d'adressage IPv4 additionnel pendant la p茅riode d'茅puisement.</p> <p class="gt-block"><strong>5.4.5 La p茅riode d'allocation et d'affectation actuelle de 12 mois sera modifi茅e en 8 mois.</strong></p> <p>La p茅riode d'attribution et d'affectation actuelle de 12 mois est pass茅e 脿 8 mois. Cela contribuera 脿 garantir que les LIR ne demandent que les ressources dont ils ont besoin 脿 court et 脿 moyen terme, et favorisera l'茅quit茅 dans la r茅partition 茅quitable des derni猫res IPv4 pool d'adresses. Cette p茅riode d'affectation restera la m锚me pendant toute la dur茅e de vie de la pr茅sente police.</p> <p class="gt-block"><strong>5.4.6 Crit猫res d'allocation</strong></p> <p class="gt-block"><strong>5.4.6.1 Pour recevoir IPv4 attributions ou affectations pendant la phase d'茅puisement, le LIR ou l'utilisateur final doit avoir utilis茅 au moins 90% de toutes les allocations ou affectations pr茅c茅dentes (y compris celles effectu茅es pendant la phase en cours et la phase d'茅puisement).</strong></p> <p>Dans le cas de nouveaux LIR ou utilisateurs finaux sans attributions ou affectations pr茅c茅dentes, cette exigence ne s'applique pas 脿 leur premi猫re demande d'allocation ou d'attribution.</p> <p class="gt-block"><strong>5.4.6.2 Les ressources AFRINIC sont destin茅es 脿 la r茅gion de service AFRINIC et toute utilisation en dehors de la r茅gion devrait 锚tre uniquement 脿 l'appui de la connectivit茅 vers la r茅gion AFRINIC.</strong></p> <p class="gt-block"><strong>5.4.7 R茅serve d'espace d'adressage IPv4</strong></p> <p class="gt-block"><strong>5.4.7.1 Un bloc d'adresse / 12 d'IPv4 sera en r茅serve avec le / 8 final.</strong></p> <p>Ce bloc d'adresse / 12 d'IPv4 sera conserv茅 par AFRINIC pour certaines utilisations futures, encore impr茅vues. / 4 IPvXNUMX. Internet ne cesse d鈥檌nnover et nous ne pouvons pas pr茅dire avec certitude ce qui pourrait arriver. Par cons茅quent, il est prudent de mettre ce bloc en r茅serve, juste au cas o霉 une exigence future cr茅erait une demande pour des adresses IPvXNUMX. </p> <p class="gt-block"><strong>5.4.7.2 Lorsque AFRINIC, ne peut plus r茅pondre aux demandes d'espace d'adressage</strong> (脿 partir de la finale / 8 ou de tout autre espace d'adressage disponible), le Conseil peut 脿 sa discr茅tion et en tenant compte de la demande et d'autres facteurs au moment de reconstituer le pool d'茅puisement avec tout espace d'adressage (ou une partie de celui-ci) qui peut 锚tre disponible pour AFRINIC 脿 l'茅poque, d'une mani猫re qui est dans le meilleur int茅r锚t de la communaut茅.</p> <hr> <h3><a id="lir-isp-allocation"></a>5.5 IPv4 Allocations LIR / ISP</h3> <p class="gt-block"><strong>5.5.1 Politiques et directives d'allocation</strong></p> <p class="gt-block"><strong>5.5.1.1 Introduction</strong></p> <p class="gt-block"><strong>5.5.1.1.1 AFRINIC alloue des plages de IPv4 adresses aux registres Internet locaux (LIR).</strong></p> <p>Les LIR r茅affectent ou sous-allouent cet espace 脿 leurs clients. Il est 茅galement conseill茅脿 tous les espaces d'adressage LIR allou茅s par AFRINIC d'adopter un ensemble de politiques coh茅rentes avec les politiques d茅crites dans ce document.</p> <p class="gt-block"><strong>5.5.1.1.2 La d茅termination de la taille d'allocation de l'espace d'adresses IP rel猫ve de la responsabilit茅 du personnel d'AFRINIC. </strong></p> <p class="gt-block">Afin de garantir que le routage inter-domaines sans classe (CIDR) est mis en 艙uvre et utilis茅 aussi efficacement que possible, AFRINIC 茅mettra des blocs de IPv4 adresses sur les limites de bits appropri茅es "prises en charge par CIDR". (CIDR - "Classless Inter-Domain Routing", est expliqu茅 dans la RFC1517-1959, <a href="https://www.ietf.org/standards/rfcs/">https://www.ietf.org/standards/rfcs/</a>).</p> <p class="gt-block"><strong>5.5.1.1.3 Si un LIR envisage d'茅changer ou de transf茅rer un espace d'adressage, il doit contacter AFRINIC afin que les modifications soient correctement enregistr茅es. </strong></p> <p>Le LIR reste responsable de toutes les allocations enregistr茅es dans la base de donn茅es AFRINIC jusqu'脿 leur transfert vers un autre LIR ou leur restitution 脿 AFRINIC. Les LIR doivent s'assurer que toutes les politiques sont appliqu茅es.</p> <p class="gt-block"><strong>5.5.1.2 Premi猫rement IPv4 Allocation</strong></p> <p class="gt-block"><strong>5.5.1.2.1 L'allocation minimale d'AFRINIC est un bloc / 22 ou 1024 d'adresses IPv4</strong></p> <p class="gt-block"><strong>5.5.1.2.2 L'organisation doit 锚tre un membre AFRINIC en r猫gle et;</strong></p> <p class="gt-block"><strong>5.5.1.2.3 Doit montrer une utilisation efficace existante des adresses IP de leur fournisseur en amont. </strong></p> <p>La justification peut 锚tre fond茅e sur une combinaison de besoins imm茅diats et d'utilisation existante, auquel cas les assignations existantes doivent 锚tre renum茅rot茅es dans la nouvelle allocation du LIR. La v茅rification de l'utilisation efficace ant茅rieure est bas茅e sur les assignations (et sous-allocations) enregistr茅es dans les bases de donn茅es RIPE, ARIN, LACNIC et APNIC et seules ces assignations enregistr茅es seront consid茅r茅es comme valides.</p> <p class="gt-block"><strong>5.5.1.3 M茅canisme de d茅marrage lent pour les premi猫res allocations</strong></p> <p>AFRINIC appliquera un m茅canisme de d茅marrage lent 脿 tous les nouveaux LIR. En ce qui concerne les allocations faites par AFRINIC, la premi猫re allocation re莽ue par un LIR sera la taille de l'allocation pratique minimale, sauf justification contraire.</p> <p>La politique de d茅marrage lent est utilis茅e par tous RIRafin d'emp锚cher les allocations de grands blocs d'espace d'adressage qui peuvent alors rester sensiblement non attribu茅s. AFRINIC mettra en 艙uvre le m茅canisme de d茅marrage lent de mani猫re coh茅rente et 茅quitable pour chaque LIR et appliquera les m锚mes principes et normes 脿 chaque demandeur d'espace d'adressage.</p> <p class="gt-block"><strong>5.5.1.4 Allocation suppl茅mentaire</strong></p> <p class="gt-block"><strong>5.5.1.4.1 Un LIR peut recevoir une allocation suppl茅mentaire lorsqu'environ 80% de tout l'espace d'adressage qui lui est actuellement allou茅 a 茅t茅 utilis茅 dans des attributions et / ou des sous-allocations valides. </strong></p> <p>Une nouvelle attribution peut 茅galement 锚tre effectu茅e si une seule attribution ou sous-attribution n茅cessite plus d'adresses que celles actuellement d茅tenues par le LIR.</p> <p class="gt-block"><strong>5.5.1.4.2 Les r茅servations ne sont pas consid茅r茅es comme des assignations ou sous-attributions valides.</strong></p> <p>Il peut 锚tre utile pour l'agr茅gation interne de garder certains blocs IP libres pour une croissance future. Ces r茅servations internes ne sont toutefois pas consid茅r茅es comme une utilisation valide et doivent 锚tre attribu茅es ou sous-allou茅es avant de demander une allocation suppl茅mentaire.</p> <p class="gt-block"><strong>5.5.1.4.3 AFRINIC essaiera toujours d'attribuer des plages d'adresses contigu毛s, permettant au LIR de minimiser le nombre d'annonces d'itin茅raire qu'il fait. </strong></p> <p>Cependant, il ne sera pas toujours possible d'allouer une plage contigu毛脿 l'allocation pr茅c茅dente du LIR.</p> <p class="gt-block"><strong>5.5.1.5 Sous-allocations</strong></p> <p>La taille minimale d'une sous-allocation est de / 24. Il permet 脿 un FAI en aval d'effectuer un nombre raisonnable de petites affectations. Un LIR ne peut pas sous-allouer IPv4 espace au-dessus de sa fen锚tre de sous-allocation (voir 5.5.1.13 pour les fen锚tres de sous-allocation).</p> <p>Les LIR peuvent effectuer des sous-allocations 脿 plusieurs FAI en aval. (Les FAI en aval qui utilisent efficacement une sous-allocation peuvent se voir attribuer une allocation / 22 s'ils souhaitent devenir une LIR).</p> <p>Le LIR est charg茅 de veiller 脿 ce que l'espace d'adressage qui lui est allou茅, et par la suite, l'espace d'adressage qu'il sous-alloue, soit utilis茅 conform茅ment aux politiques et directives de la communaut茅.</p> <p>Il est conseill茅 aux LIR d'utiliser le m茅canisme de d茅marrage lent lors de la sous-allocation aux FSI en aval. Ici, le LIR garantit que l'espace sous-allou茅 est utilis茅 efficacement et le LIR peut 茅galement surveiller et d茅terminer la capacit茅 du FAI en aval 脿 fonctionner dans le cadre des politiques d茅finies par la communaut茅.</p> <p>Les sous-allocations font partie de l'espace agr茅geable d'un LIR. Par cons茅quent, un LIR devrait garantir que l'espace IP n'est pas conserv茅 par le FAI en aval si le revendeur cesse d'obtenir la connectivit茅 du r茅seau du LIR (les sous-allocations ne sont pas portables).</p> <p class="gt-block"><strong>5.5.1.6 Politiques et directives d'attribution des AP</strong></p> <p>Les LIR doivent demander l'approbation d'AFRINIC pour toutes les sous-allocations au-dessus de leur fen锚tre de sous-allocation.</p> <p>Les directives suivantes sont destin茅es 脿 aider les LIR et les utilisateurs finaux dans leur recherche de compromis 茅quitables:</p> <p class="gt-block"><strong>Documentation 5.5.1.7</strong></p> <p>Les informations requises par AFRINIC pour justifier les exigences d'adresse IP d'un utilisateur final incluent la r茅ponse aux besoins, l'infrastructure r茅seau et les plans futurs. Ces informations sont requises lorsqu'un LIR demande un espace IP pour ses utilisateurs finaux au moment de l'envoi de la demande. Afin de garantir que les sous-allocations pr茅c茅dentes ne sont pas dupliqu茅es, l'utilisation actuelle de l'espace d'adressage est 茅galement requise. Ces informations sont essentielles pour effectuer les approbations de sous-allocation appropri茅es, et le niveau de d茅tail d茅pendra de la taille de la demande et de la complexit茅 du r茅seau. Le LIR doit s'assurer que les informations n茅cessaires sont compl茅t茅es avant de faire une demande de sous-allocation 脿 AFRINIC.</p> <p>Lors de la sous-allocation de leur SAW, les LIR devraient 茅galement s'assurer que ces informations sont fournies par l'utilisateur final.</p> <p class="gt-block"><strong>5.5.1.8 Infrastructure de r茅seau (de LIR) vs r茅seaux d'utilisateurs finaux</strong></p> <p>Les adresses IP utilis茅es uniquement pour connecter un utilisateur final 脿 un fournisseur de services (par exemple, des liaisons point 脿 point) sont consid茅r茅es comme faisant partie de l'infrastructure du fournisseur de services. Ces adresses ne devraient 锚tre enregistr茅es que dans le cadre de l'infrastructure du fournisseur de services. Lorsqu'un utilisateur final dispose d'un r茅seau utilisant un espace d'adressage public, cet espace doit 锚tre enregistr茅 avec les contacts de l'utilisateur final. Si l'utilisateur final est un individu plut么t qu'une organisation, l'espace peut 锚tre enregistr茅 avec les coordonn茅es du prestataire de services mais avec l'utilisateur final r茅f茅renc茅 dans l'AFRINIC whois objet de base de donn茅es.</p> <p class="gt-block"><strong>5.5.1.9 Utilisation</strong></p> <p>L'utilisation imm茅diate des affectations doit repr茅senter au moins 25% de l'espace attribu茅. Apr猫s un an, 脿 moins que des circonstances particuli猫res ne soient d茅finies, il devrait 锚tre d'au moins 50%.</p> <p class="gt-block"><strong>5.5.1.10 R茅servations non prises en charge</strong></p> <p>Les utilisateurs finaux ne sont pas autoris茅s 脿 r茅server un espace d'adressage sur la base de plans 脿 long terme. Cela viole l'objectif de conservation et fragmente l'espace d'adressage lorsque les pr茅visions initiales ne sont pas satisfaites. Si un LIR souhaite attribuer un espace d'adressage aux clients, il doit effectuer les affectations 脿 partir de tout espace d'adressage non allou茅 ou non attribu茅 qu'il d茅tient actuellement. Aux fins de l'茅valuation des demandes d'allocation, l'espace r茅serv茅 par un LIR 脿 d'autres clients est consid茅r茅 comme inutilis茅.</p> <p class="gt-block"><strong>5.5.1.11 Validit茅 d'une mission</strong></p> <p>Les missions restent valables tant que les crit猫res d'origine sur lesquels la mission 茅tait bas茅e sont toujours en place et que la mission est enregistr茅e dans la base de donn茅es AFRINIC. Une affectation est donc invalide si elle n'est pas enregistr茅e dans la base de donn茅es et si le but pour lequel elle a 茅t茅 enregistr茅e a chang茅 ou n'est plus valable.</p> <p class="gt-block"><strong>5.5.1.12 Renum茅rotation</strong></p> <p>Cela remplace les adresses IP sur une base individuelle. Les affectations valides peuvent 锚tre remplac茅es par le m锚me nombre d'adresses si les crit猫res d'attribution d'origine sont toujours remplis. Les adresses 脿 remplacer doivent toujours 锚tre utilis茅es. Lorsqu'une demande de renum茅rotation d茅passe la fen锚tre de sous-allocation du LIR, la demande doit 锚tre envoy茅e 脿 AFRINIC pour approbation.</p> <p>Une p茅riode de trois mois est normalement consid茅r茅e comme suffisante pour migrer un r茅seau vers le nouvel espace IP. Une fois qu'un r茅seau a 茅t茅 renum茅rot茅, le personnel d'AFRINIC supprimera l'ancienne affectation de la base de donn茅es AFRINIC. Au cas o霉 la p茅riode de trois mois ne serait pas suffisante, le LIR devrait informer AFRINIC du temps suppl茅mentaire qu'il pourrait falloir pour renum茅roter compl猫tement.</p> <p class="gt-block"><strong>5.5.1.13 Fen锚tre de sous-allocation (SAW)</strong></p> <p class="gt-block"><strong>5.5.1.13.1</strong> Une fen锚tre de sous-allocation (SAW) fait r茅f茅rence au nombre maximum de IPv4 adresses que le LIR peut sous-allouer aux utilisateurs finaux sans demander l'approbation d'AFRINIC. La taille SAW est exprim茅e en notation CIDR.</p> <p class="gt-block"><strong>5.5.1.13.2</strong> AFRINIC examinera la sous-allocation faite par les LIR en utilisant leur SAW pour s'assurer que les politiques sont suivies correctement. Les LIR doivent 茅galement veiller 脿 ce que la documentation de la sous-allocation effectu茅e 脿 l'aide du SAW soit similaire 脿 celle demand茅e pour les demandes plus importantes.</p> <p class="gt-block"><strong>5.5.1.13.3</strong> Voici quelques directives pour le SAW:</p> <ol> <li>Tous les nouveaux LIR ont une SAW de z茅ro. Toutes les sous-allocations devront 锚tre approuv茅es au pr茅alable par AFRINIC.</li> <li>Le LIR ne peut effectuer aucune sous-allocation 脿 l'utilisateur final au-dessus de sa SAW dans une p茅riode de 12 mois (1 an). 脌 la fin d'une ann茅e civile 脿 compter de l'approbation d'une SAW, la SAW est actualis茅e pour une ann茅e suppl茅mentaire. Dans le cas o霉 la SAW du LIR est 茅puis茅e pour un utilisateur final particulier, l'approbation d'AFRINIC doit 锚tre demand茅e pour toute autre sous-allocation au m锚me utilisateur final.</li> <li>Les LIR sont invit茅s 脿 contacter AFRINIC pour une r茅vision de leur SAW. Ils peuvent 茅galement demander un deuxi猫me avis 脿 AFRINIC m锚me pour une sous-allocation qui pourrait 锚tre faite avec leur SAW s'ils le souhaitaient. Avant de lever une scie, les 茅l茅ments suivants seront pris en consid茅ration: <ol> <li>Toute la documentation requise est normalement pr茅sent茅e.</li> <li>Les affectations de sous-allocation pr茅c茅dentes de cette sous-allocation sont toutes enregistr茅es correctement dans la base de donn茅es.</li> <li>La SAW actuelle n'a pas 茅t茅 mal utilis茅e / abus茅e.</li> </ol> </li> <li>Les nouveaux LIR sont invit茅s 脿 former leurs contacts pour g茅rer les affectations d'espace d'adressage conform茅ment aux politiques et proc茅dures de ce document. Si, en raison de contacts inexp茅riment茅s au LIR, des erreurs dues 脿 un mauvais jugement se produisent r茅guli猫rement, le SAW peut 锚tre r茅duit ou supprim茅 pour permettre au personnel d'AFRINIC d'aider 脿 former le personnel du LIR aux politiques de la communaut茅 AFRINIC.</li> </ol> <p class="gt-block"><strong>5.5.1.14 Tenue de registres par les LIR</strong></p> <p>Les LIR doivent conserver et conserver des enregistrements de toute documentation concernant les affectations et les sous-allocations aux utilisateurs finaux. Il est n茅cessaire pour r茅f茅rence future lors de l'茅valuation des demandes de la m锚me organisation et pour tout audit par AFRINIC. Ces documents doivent 锚tre conserv茅s 茅lectroniquement pour un acc猫s plus facile. Il est conseill茅 que ces enregistrements comprennent, sans s'y limiter:</p> <ol> <li>La demande d'origine.</li> <li>Documentation 脿 l'appui.</li> <li>Correspondance connexe entre le LIR et l'utilisateur final.</li> <li>D茅cision de la mission et motifs de toute d茅cision inhabituelle.</li> <li>R么le de la personne qui a pris la d茅cision.</li> </ol> <hr> <h3>5.6 <a id="IPv4-En-User-PI-Assignments"></a>Attribution IPv4 脿 l'utilisateur final (PI)</h3> <p>AFRINIC attribue des blocs de IPv4 des adresses aux utilisateurs finaux qui demandent un espace d'adressage pour leur usage interne dans la gestion de leurs propres r茅seaux, mais pas pour la sous-d茅l茅gation ou la r茅affectation de ces adresses en dehors de leur organisation. Les utilisateurs finaux doivent r茅pondre 脿 certaines exigences pour justifier l'attribution d'un bloc d'adresse.</p> <p class="gt-block"><strong>5.6.1 Affectation minimale</strong></p> <p>En g茅n茅ral, le bloc minimum d'espace d'adresse IP attribu茅 par AFRINIC aux utilisateurs finaux est de / 24. Si des affectations inf茅rieures 脿 / 24 sont n茅cessaires, les utilisateurs finaux doivent contacter leur fournisseur en amont. Les pr茅fixes attribu茅s 脿 l'utilisateur final proviendront d'un bloc r茅serv茅脿 cet effet.</p> <p class="gt-block"><strong>5.6.2 Crit猫res d'attribution du premier utilisateur final</strong></p> <p>Les utilisateurs finaux demandeurs doivent:</p> <ol> <li>脢tre membre AFRINIC en r猫gle</li> <li>Montrez soit une utilisation efficace existante d'au moins / 25 de leur fournisseur en amont.</li> <li>Justifiez un besoin imm茅diat d'au moins 50% de la taille totale demand茅e en fonction de leur infrastructure r茅seau. Par exemple, une nouvelle entreprise.</li> </ol> <p class="gt-block"><strong>5.6.3 Attribution de PI suppl茅mentaire</strong></p> <p>Le taux d'utilisation de l'espace d'adressage est un facteur cl茅 pour justifier une nouvelle attribution d'espace d'adressage IP. Les demandeurs doivent montrer exactement comment les attributions d'adresses pr茅c茅dentes ont 茅t茅 utilis茅es et doivent fournir les d茅tails appropri茅s pour v茅rifier leur projection de croissance sur un an. Les crit猫res de base 脿 respecter sont:</p> <ol> <li>Un taux d'utilisation imm茅diat de 25%, et </li> <li>Un taux d'utilisation de 50% en un an. </li> </ol> <p>Un taux d'utilisation plus 茅lev茅 peut 锚tre requis en fonction des besoins individuels du r茅seau. Adresse IP priv茅e: les utilisateurs finaux non actuellement connect茅s 脿 un FAI et / ou pr茅voyant de ne pas 锚tre connect茅s 脿 Internet sont encourag茅s 脿 utiliser des num茅ros IP priv茅s r茅serv茅s aux r茅seaux non connect茅s (voir RFC 1918).</p> <p class="gt-block"><strong>5.6.4 Affectations d'IP 脿 l'infrastructure critique</strong></p> <p class="gt-block"><strong>5.6.4.1 AFRINIC affectera l'Utilisateur final aux fournisseurs d'infrastructures critiques de l'Internet tels que les points d'茅change Internet publics et les fournisseurs de services DNS de base. </strong></p> <p>Ces allocations ne d茅passeront pas a / 24 en utilisant IPv4. Des allocations multiples peuvent 锚tre accord茅es dans certaines situations. Les attributions de points d'茅change DOIVENT 锚tre 茅mises 脿 partir de blocs sp茅cifiques r茅serv茅s uniquement 脿 cette fin.</p> <p class="gt-block"><strong>5.6.4.2 AFRINIC rendra publique une liste de ces blocs.</strong></p> <p class="gt-block"><strong>5.6.4.3 Les op茅rateurs de points d'茅change doivent fournir une justification de l'attribution, notamment: la politique de connexion, l'emplacement, les autres participants (au minimum trois au total), ASNet coordonn茅es.</strong></p> <p>Cette politique n'emp锚che pas les op茅rateurs de points d'茅change de demander un espace d'adressage en vertu d'autres politiques telles que devenir LIR.</p> <p class="gt-block"><strong>5.6.4.4 D茅finitions:</strong></p> <p class="gt-block"><strong>5.6.4.4.1</strong> <strong>Point d'茅change</strong>:</p> <p>Un point d'茅change Internet est d茅fini comme une infrastructure de r茅seau physique (couche 2) exploit茅e par une seule entit茅 dont le but est de faciliter l'茅change de trafic Internet entre les FAI. Il doit y avoir un minimum de trois FAI connect茅s et il doit y avoir une politique claire et ouverte pour que d'autres puissent adh茅rer. Les adresses n茅cessaires 脿 d'autres fins (par exemple, services suppl茅mentaires fournis aux membres) doivent 锚tre acquises par les moyens appropri茅s (par exemple, un FAI en amont).</p> <p class="gt-block"><strong>5.6.4.4.2</strong> <strong>Fournisseur de services de base DNS</strong>:</p> <p>Un fournisseur de services de base DNS est une soci茅t茅 qui fournit des services de base au niveau racine de l鈥檃rbre DNS (op茅rateurs de serveurs racines agr茅茅s par l鈥橧CANN).</p> <hr> <h3>5.7 <a id="IPv4-Resource-Transfers-within-AFRINIC-Region"></a>Transfert de ressources IPv4 dans la r茅gion AFRINIC</h3> <p>Comme les autres Registres Internet R茅gionaux, AFRINIC va bient么t 茅puiser sa plage d'adresses d'IPv4. Afin de r茅pondre aux besoins des demandeurs de ressources tardifs, une politique de transfert des ressources IPv4 dans la r茅gion sont n茅cessaires. Le but de cette politique est de d茅finir les conditions dans lesquelles les transferts doivent avoir lieu. La politique r茅sout le probl猫me d'une organisation africaine ayant besoin IPv4 nombre de ressources apr猫s l'茅puisement de l'IPv4 脿 AFRINIC ou quand AFRINIC ne peut plus r茅pondre aux besoins d'une telle organisation.</p> <p class="gt-block"><strong>5.7.1 R茅sum茅 de la politique</strong></p> <p>Cette politique s'applique 脿 une organisation ayant un besoin justifi茅 de IPv4 ressources qui ne peuvent 锚tre satisfaites par AFRINIC.</p> <p class="gt-block"><strong>5.7.2 Les ressources IPv4 脿 transf茅rer</strong> - doit provenir d'un compte de membre AFRINIC existant ou d'un d茅tenteur de ressources h茅rit茅 dans la r茅gion de service AFRINIC.</p> <p class="gt-block"><strong>5.7.3. Conditions relatives 脿 la provenance du transfert</strong></p> <p class="gt-block"><strong>5.7.3.1</strong> La source doit 锚tre le titulaire l茅gitime actuel des adresses IPv4 reconnues par AFRINIC, et ne pas 锚tre impliqu茅 dans un diff茅rend quant au statut de ces ressources.</p> <p class="gt-block"><strong>5.7.3.2</strong> Les entit茅s sources ne seront pas 茅ligibles pour recevoir davantage IPv4 traiter les allocations ou les affectations d'AFRINIC pour une p茅riode de 12 mois apr猫s l'approbation du transfert.</p> <p class="gt-block"><strong>5.7.3.3</strong> Les entit茅s sources ne doivent pas avoir re莽u de transfert, d'allocation ou d'affectation de IPv4 nombre de ressources d'AFRINIC pour les 12 mois pr茅c茅dant l'approbation de la demande de transfert. Cette restriction exclut les transferts de fusions et acquisitions.</p> <p class="gt-block"><strong>5.7.4. Conditions relatives au destinataire du transfert</strong></p> <p class="gt-block"><strong>5.7.4.1</strong> AFRINIC doit approuver le besoin du destinataire pour les ressources IPv4. Pour qu鈥檜ne organisation puisse pr茅tendre 脿 recevoir un transfert, elle doit d鈥檃bord passer par le processus de justification de besoins en ressources IPv4 aupr猫s d'AFRINIC. C'est-脿-dire que l'organisation doit justifier et d茅montrer aupr猫s d'AFRINIC son utilisation initiale / suppl茅mentaire d'allocation / affectation, le cas 茅ch茅ant, conform茅ment aux politiques en vigueur.</p> <p class="gt-block"><strong>5.7.4.2</strong> Le destinataire doit 锚tre un membre AFRINIC, soumis aux politiques d'AFRINIC en vigueur et doit signer le contrat de services d'enregistrement pour les ressources re莽ues.</p> <p class="gt-block"><strong>5.7.4.3</strong> Les ressources h茅rit茅es transf茅r茅es ne seront plus consid茅r茅es comme des ressources h茅rit茅es. </p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>6.0 <a id="IPv6"></a>IPv6</h2> </div> <div class="panel-body"> <p>La pr茅sente section d茅finit les politiques de registre pour l'assignation et l'attribution d'adresses uniques globales IPv6 aux fournisseurs d'acc猫s Internet (FAI) et 脿 d鈥檃utres organisations de la r茅gion d鈥橝friNIC. </p> <p class="gt-block">Elle fournit, par ailleurs, des recommandations aux registres AfriNIC, APNIC, ARIN, LACNIC et RIPE-NCC sur les politiques d'attribution des adresses IPv48 aux sites finaux. <a href="https://tools.ietf.org/html/rfc6177">https://tools.ietf.org/html/rfc6177</a> .</p> <br><hr> <h3>6.1 <a id="Utilisation"></a>Utilisation</h3> Aim茅e IPv4, IPv6 est g茅n茅ralement attribu茅 aux sites finaux en montants fixes. L'utilisation r茅elle des adresses dans chaque affectation sera faible par rapport 脿 IPv4 missions. Dans IPv6, l '"utilisation" n'est mesur茅e qu'en termes de nombre de pr茅fixes attribu茅s aux sites finaux, et non de leur taille ou du nombre d'adresses r茅ellement utilis茅es dans ces pr茅fixes. <h3>6.2 <a id="HD-Ratio"></a>Rapport HD</h3> <p>Le HD-Ratio est un moyen de mesurer l'efficacit茅 de l'attribution d'adresses [RFC 3194]. Il s'agit d'une adaptation du rapport H d茅fini 脿 l'origine dans la [RFC1715] et s'exprime comme suit:</p> <p style="text-align: center;" class="gt-block"> <strong>                Log (nombre d鈥檕bjets attribu茅s)</strong></p> <p style="text-align: center;" class="gt-block"><strong>HD = ------------------------------------------------ ----------</strong></p> <p style="text-align: center;" class="gt-block"><strong>                   Log (nombre maximum d鈥檕bjets attribuables)</strong></p> <p>o霉 (dans le cas du pr茅sent document) les objets sont des adresses de sites IPv6 (pr茅fixes /48) assign茅es 脿 partir d鈥檜n pr茅fixe IPv6 d鈥檜ne certaine taille.</p> <hr> <h3>6.3 <a id="IPv6-Goals"></a>Objectifs de gestion de l'espace d'adressage IPv6</h3> <p>IPv6 l'espace d'adressage est une ressource publique qui doit 锚tre g茅r茅e avec prudence au regard des int茅r锚ts 脿 long terme d'Internet. La gestion responsable de l'espace d'adressage implique d'茅quilibrer un ensemble d'objectifs parfois concurrents. Les objectifs suivants sont pertinents pour IPv6 adresse politique.</p> <p class="gt-block"><strong>6.3.1 Unicit茅:</strong></p> <p>Chaque affectation et / ou attribution d'espace d'adressage doit garantir l'unicit茅 dans le monde entier. Il s'agit d'une exigence absolue pour garantir que chaque h么te public sur Internet puisse 锚tre identifi茅 de mani猫re unique.</p> <p class="gt-block"><strong>6.3.2 Enregistrement</strong></p> <p>L'espace d'adressage Internet doit 锚tre enregistr茅 dans une base de donn茅es de registre accessible aux membres appropri茅s de la communaut茅 Internet. Cela est n茅cessaire pour garantir l'unicit茅 de chaque adresse Internet et pour fournir des informations de r茅f茅rence pour le d茅pannage Internet 脿 tous les niveaux, allant de tous RIRs et IR aux utilisateurs finaux.</p> <p>L'objectif de l'enregistrement doit 锚tre appliqu茅 dans le contexte de consid茅rations raisonnables de confidentialit茅 et des lois applicables.</p> <p class="gt-block"><strong>6.3.3 Agr茅gation</strong></p> <p>Dans la mesure du possible, l'espace d'adressage doit 锚tre r茅parti de mani猫re hi茅rarchique, selon la topologie de l'infrastructure r茅seau. Cela est n茅cessaire pour permettre l'agr茅gation des informations de routage par les FAI et pour limiter l'expansion des tables de routage Internet.</p> <p>Cet objectif est particuli猫rement important concernant l鈥檃dressage IPv6, car la taille de la totalit茅 de la r茅serve d鈥檃dresses comporte des implications majeures tant pour le routage interne qu鈥檈xterne.</p> <p>Les politiques d鈥檃dressage IPv6 doivent 茅viter la fragmentation des plages d鈥檃dresses.</p> <p>De plus, les RIR doivent appliquer des pratiques qui maximisent le potentiel d鈥檃ttributions ult茅rieures contigu毛s aux attributions pass茅es actuellement d茅tenues. Toutefois, les attributions contigu毛s ne sont aucunement garanties.</p> <p class="gt-block"><strong>6.3.4 Conservation</strong></p> <p>Bien que IPv6 fournit un pool extr锚mement vaste d'espace d'adressage, les politiques d'adressage devraient 茅viter les pratiques inutilement inutiles. Les demandes d'espace d'adressage doivent 锚tre 茅tay茅es par une documentation appropri茅e et le stockage des adresses inutilis茅es doit 锚tre 茅vit茅.</p> <p class="gt-block"><strong>6.3.5 脡quit茅</strong></p> <p>Toutes les politiques et pratiques relatives 脿 l'utilisation de l'espace de sonorisation doivent s'appliquer de mani猫re juste et 茅quitable 脿 tous les membres existants et potentiels de la communaut茅 Internet, quels que soient leur emplacement, leur nationalit茅, leur taille ou tout autre facteur.</p> <p class="gt-block"><strong>6.3.6 Frais g茅n茅raux minimis茅s</strong></p> <p>Il est souhaitable de minimiser la surcharge associ茅e 脿 l'obtention de l'espace d'adressage. Les frais g茅n茅raux incluent la n茅cessit茅 de revenir 脿 RIRs pour un espace suppl茅mentaire trop fr茅quemment, la surcharge associ茅e 脿 la gestion de l'espace d'adressage qui cro卯t 脿 travers un certain nombre de petites extensions incr茅mentielles successives plut么t qu'脿 travers des extensions moins nombreuses mais plus importantes.</p> <p class="gt-block"><strong>6.3.7 Conflit d'objectifs</strong></p> <p>Les objectifs d茅crits ci-dessus entreront souvent en conflit les uns avec les autres ou avec les besoins des RI individuels ou des utilisateurs finaux. Tous les RI 茅valuant les demandes d'allocations et d'assignations doivent porter des jugements, en cherchant 脿茅quilibrer les besoins du demandeur avec les besoins de la communaut茅 Internet dans son ensemble.</p> <p>Dans la politique d鈥檃dressage IPv6, l鈥檕bjectif d鈥檃gr茅gation est consid茅r茅 comme le plus important.</p> <hr> <h3>6.4  <a id="IPv6-Policy-Priciples"></a>Principes politiques de l鈥橧Pv6</h3> <p>Pour atteindre les objectifs d茅crits dans la section pr茅c茅dente, les politiques de ce document discutent et suivent les principes de base d茅crits ci-dessous.</p> <p class="gt-block"><strong>6.4.1 L'espace d'adresses ne doit pas 锚tre consid茅r茅 comme une propri茅t茅.</strong></p> <p>Le fait de consid茅rer les espaces adresses comme des biens en pleine propri茅t茅 va 脿 l鈥檈ncontre des objectifs du pr茅sent document et n鈥檈st pas dans l鈥檌nt茅r锚t de la communaut茅 Internet en g茅n茅ral.</p> <p>Les politiques 茅nonc茅es dans ce document reposent sur la compr茅hension que les espaces adresses unicast IPv6 globalement uniques sont soumises 脿 une utilisation sous licence plut么t que vendues.</p> <p class="gt-block"><strong>6.4.2 Routabilit茅 non garantie</strong></p> <p>Il n鈥檈xiste aucune garantie qu鈥檜ne quelconque attribution ou assignation d鈥檃dresse sera routable globalement. Toutefois, les RIR doivent appliquer des proc茅dures qui r茅duisent la possibilit茅 de fragmentation d鈥檈spaces adresses, qui peuvent causer une perte de routabilit茅.</p> <p class="gt-block"><strong>6.4.3 Allocation minimale</strong></p> <p>Les RIRs appliqueront une taille minimale pour IPv6 allocations pour faciliter le filtrage bas茅 sur les pr茅fixes. La taille d'allocation minimale pour l'espace d'adressage IPv6 est un / 32.</p> <p class="gt-block"><strong>6.4.4 Prise en compte de IPv4 infrastructure</strong></p> <p>Lorsqu'un existant IPv4 demandes des fournisseurs de services IPv6 espace pour la transition 茅ventuelle des services existants vers IPv6, le nombre de IPv4 les clients peuvent 锚tre utilis茅s pour justifier une demande plus importante que celle qui serait justifi茅e si elle IPv6 Infrastructure.</p> <hr> <h3>6.5  <a id="Allocations-Assignments-Policies"></a>Politiques d'allocations et d'assignations</h3> <p class="gt-block"><strong>6.5.1 Allocation initiale</strong></p> <p class="gt-block"><strong>6.5.1.1 Crit猫res d'attribution initiale</strong></p> <p>Pour pouvoir b茅n茅ficier d鈥檜ne attribution initiale d鈥檈spaces adresses IPv6, une organisation doit :</p> <ol style="list-style-type: upper-alpha;"> <li>锚tre un LIR;</li> <li>pr茅senter un plan d茅taill茅 pour fournir la connectivit茅 IPv6/ services 脿 d'autres organisations / utilisateurs finaux ou 脿 des d茅partements / entit茅s / sites propres / apparent茅s dans la r茅gion AFRINIC.</li> <li> pr茅senter un plan raisonnable pour offrir des assignations /48 d'IPv6 aux sites finaux de la r茅gion d鈥橝FRINIC dans un d茅lai de douze mois</li> </ol> <p class="gt-block"> <strong>6.5.1.2 Taille d'allocation initiale</strong></p> <ol style="list-style-type: upper-alpha;"> <li>Les organisations qui r茅pondent aux crit猫res d'allocation initiaux sont 茅ligibles pour recevoir une allocation minimum de / 32.</li> <li>Les organisations peuvent se qualifier pour une allocation initiale sup茅rieure 脿 / 32 en soumettant des documents justifiant la demande.</li> <li>Dans ce cas, l'allocation initiale sera bas茅e sur l'espace n茅cessaire pour servir les clients de l'organisation, le nombre d'utilisateurs, l'茅tendue de son infrastructure, la structure hi茅rarchique et / ou g茅ographique, la segmentation de l'infrastructure pour des raisons de s茅curit茅 ou autres, et la long茅vit茅 pr茅vue pour le allocation initiale.</li> </ol> <p class="gt-block"><strong>6.5.1.3. Rectifier la taille des allocations initiales</strong></p> <p>Pendant IPv6 d茅ploiement, si une organisation constate que la taille de l'allocation initiale qu'elle a demand茅e ne r茅pond plus 脿 ses besoins, l'organisation peut soumettre un nouveau plan d'adressage 脿 AFRINIC, sans avoir 脿 attendre jusqu'脿 ce qu'elle puisse r茅pondre aux exigences d'une allocation ult茅rieure, et donc l'organisation n'aura pas 脿 prouver les seuils d'utilisation, mais plut么t la volont茅 d'appliquer un plan d'adressage diff茅rent et mieux adapt茅脿 la r茅alit茅 du d茅ploiement.</p> <p>La nouvelle taille sera ajust茅e selon le nouveau plan d'adressage comme sp茅cifi茅 au paragraphe 6.5.1.2., Et sera donc qualifi茅e pour 茅tendre le pr茅fixe actuel du nombre de bits n茅cessaire.</p> <p>Dans le cas o霉 il n'est pas possible de fournir cette longueur de pr茅fixe car l'espace adjacent est d茅j脿 utilis茅 par une autre organisation, ou si effectuer l'allocation ne laisse pas suffisamment d'espace pour les allocations ult茅rieures, AFRINIC informera le demandeur, qui peut choisir de:</p> <ol style="list-style-type: upper-alpha;"> <li>Recevez un nouveau pr茅fixe avec la nouvelle taille demand茅e et renum茅rotez leur r茅seau et renvoyez l'allocation initiale "originale" dans les 6 mois, ou</li> <li>Recevoir un pr茅fixe compl茅mentaire pour finaliser leur plan d'adressage, et annoncer les deux, le pr茅fixe initial "original" et le nouveau pr茅fixe r茅sultant de la nouvelle allocation. 脌 toutes fins utiles, dans le cas d'attributions ult茅rieures, les deux attributions doivent 锚tre consid茅r茅es comme s'il s'agissait d'une attribution unique.</li> </ol> <p>Chaque organisation ne peut utiliser cette proc茅dure qu'une seule fois. Par cons茅quent, pour cette "deuxi猫me opportunit茅", elle doit 茅tudier attentivement les plans d茅finitifs d'adressage du r茅seau 脿 moyen et long terme.</p> <p class="gt-block"><strong>6.5.2 Attribution ult茅rieure</strong></p> <p>Les organisations qui disposent d鈥檜ne attribution IPv6 existante peuvent recevoir une autre attribution conform茅ment aux politiques suivantes.</p> <p class="gt-block"><strong>6.5.2.1 Crit猫res d'attribution ult茅rieurs</strong></p> <p>Des attributions suivantes seront accord茅es lorsqu鈥檜ne organisation (LIR) satisfait au niveau minimum d鈥櫭﹙aluation qui consiste en l鈥檜tilisation pass茅e d鈥檃dresses en termes de nombre de sites en unit茅s d鈥檃ssignations /48. Le ratio HD indiqu茅 dans le document technique [RFC 3194] est utilis茅 pour d茅terminer les seuils d鈥檜tilisation qui justifient l鈥檃ttribution d鈥檃dresses suppl茅mentaires comme expliqu茅 ci-apr猫s.</p> <p class="gt-block"><strong>6.5.2.2 Ratio HD appliqu茅</strong></p> <p>La valeur HD-Ratio de 0.94 est adopt茅e comme indiquant une utilisation d'adresse acceptable pour justifier l'allocation d'espace d'adressage suppl茅mentaire. La section 6.7 fournit un tableau indiquant le nombre d'assignations n茅cessaires pour atteindre une valeur d'utilisation acceptable pour une taille de bloc d'adresse donn茅e.</p> <p class="gt-block"><strong>6.5.2.3 Taille de l'allocation ult茅rieure</strong></p> <ol style="list-style-type: upper-alpha;"> <li>Lorsqu'une organisation a atteint une utilisation acceptable de son espace d'adressage allou茅, elle est imm茅diatement 茅ligible pour obtenir une allocation suppl茅mentaire qui se traduit par un doublement de l'espace d'adressage qui lui avait 茅t茅 pr茅c茅demment allou茅. Dans la mesure du possible, l'allocation sera effectu茅e 脿 partir d'un bloc d'adresse adjacent, ce qui signifie que son allocation existante sera 茅tendue d'un bit vers la gauche.</li> <li>Si une organisation a besoin de plus d'espace d'adressage, l'organisation doit fournir une documentation justifiant l'espace dont elle a besoin pour servir ses clients, le nombre d'utilisateurs, l'茅tendue de son infrastructure, sa structure hi茅rarchique et / ou g茅ographique, la segmentation de l'infrastructure pour des raisons de s茅curit茅 ou autres, et la long茅vit茅 pr茅vu pour l'allocation initiale.</li> </ol> <p class="gt-block"><strong>6.5.3 Allocation LIR-ISP</strong></p> <p>Il n'y a pas de politique sp茅cifique pour une organisation (LIR) d'allouer de l'espace d'adressage aux FAI subordonn茅s. Chaque organisation LIR peut d茅velopper sa propre politique pour les FAI subordonn茅s afin d'encourager une utilisation optimale du bloc d'adresses total allou茅 au LIR. Cependant, toutes les affectations / 48 aux sites d'extr茅mit茅 doivent 锚tre enregistr茅es soit par le LIR ou ses FAI subordonn茅s de telle mani猫re que le RIR peut 茅valuer correctement le HD-Ratio lorsqu'une allocation ult茅rieure devient n茅cessaire.</p> <p class="gt-block"><strong>6.5.4 Affectations</strong></p> <p>Les LIR doivent faire IPv6 missions conform茅ment aux dispositions suivantes.</p> <p class="gt-block"><strong>6.5.4.1 Taille de l'espace d'adressage d'affectation</strong></p> <p class="gt-block">Les attributions doivent 锚tre effectu茅es conform茅ment au besoin sp茅cifi茅 par les utilisateurs des LIR ainsi qu'aux autres recommandations existantes telles que [RIPE-690 - <a href="https://www.ripe.net/publications/docs/ripe-690">https://www.ripe.net/publications/docs/ripe-690</a>], dont les points saillants sont r茅sum茅s ci-dessous:</p> <ol style="list-style-type: upper-alpha;"> <li>Les sites ou utilisateurs finaux doivent se voir attribuer un pr茅fixe qui est un multiple de "n" / 64 qui doit 锚tre suffisant pour r茅pondre 脿 leurs besoins actuels et pr茅vus, en tenant compte des protocoles existants et des possibilit茅s futures et en 茅vitant ainsi d'茅ventuels sc茅narios de renum茅rotation.</li> <li>La taille du pr茅fixe 脿 attribuer est une d茅cision op茅rationnelle du LIR, bien que la s茅lection de / 48 soit recommand茅e pour une infrastructure plus simple et plus fonctionnelle pour tous les points d'extr茅mit茅 du r茅seau.</li> <li>Des affectations de pr茅fixe persistantes sont recommand茅es pour 茅viter les 茅checs ind茅sirables.</li> <li>Il est recommand茅 d'utiliser un pr茅fixe / 64 pour les liaisons point 脿 point avec les GUA (Global Unicast Addresses).</li> </ol> <p>AFRINIC ne se soucie pas de la taille de pr茅fixe attribu茅e par une LIR. En cons茅quence, AFRINIC ne demandera pas d'informations d茅taill茅es sur IPv6 r茅seaux d'utilisateurs (comme dans IPv4), 脿 l'exception des cas d茅crits au point 6.5.2 et aux fins de la mesure de l'utilisation.</p> <p class="gt-block"><strong>6.5.4.2 Attribution 脿 l'infrastructure de l'op茅rateur</strong></p> <p>Une organisation (LIR) peut attribuer un / 48 par PoP comme infrastructure de service d'un op茅rateur de service IPv6 . Chaque assignation 脿 un PoP est consid茅r茅e comme une assignation quel que soit le nombre d'utilisateurs utilisant le PoP. Une assignation distincte peut 锚tre obtenue pour les op茅rations internes de l'op茅rateur.</p> <p class="gt-block"><strong>6.5.5 Enregistrement</strong></p> <p>Lorsqu'une organisation (LIR) d茅tenant un IPv6 l'allocation d'adresses fait IPv6 des attributions d'adresse, il doit enregistrer les informations d'affectation dans la base de donn茅es AFRINIC. Les informations sont enregistr茅es dans les unit茅s des r茅seaux attribu茅s / 48. Lorsque plus d'un / 48 est attribu茅脿 une organisation, l'organisation affectante est responsable de s'assurer que l'espace d'adressage est enregistr茅 dans la base de donn茅es AFRINIC.</p> <p>AFRINIC utilisera les donn茅es enregistr茅es pour calculer le HD-Ratio au moment de la demande d'attribution ult茅rieure et pour v茅rifier les changements dans les affectations au fil du temps.</p> <p>AFRINIC doit maintenir des syst猫mes et des pratiques qui prot猫gent la s茅curit茅 des informations personnelles et commerciales qui sont utilis茅es dans l'茅valuation des demandes, mais qui ne sont pas requises pour l'enregistrement public.</p> <p class="gt-block"><strong>6.5.6 Recherche invers茅e</strong></p> <p>Quand un AFRINIC d茅l猫gue IPv6 l'espace d'adressage 脿 une organisation, il d茅l猫gue 茅galement la responsabilit茅 de g茅rer la zone de recherche invers茅e qui correspond 脿 l'allocation IPv6 espace d'adressage. Chaque organisation doit g茅rer correctement sa zone de recherche invers茅e. Lors de l'attribution d'une adresse, l'organisation doit d茅l茅guer 脿 une organisation cessionnaire, sur demande, la responsabilit茅 de g茅rer la zone de recherche invers茅e qui correspond 脿 l'adresse affect茅e.</p> <p class="gt-block"><strong>6.5.7 Existant IPv6 d茅tenteurs d'espace d'adressage </strong></p> <p>Organisations ayant re莽u / 35 IPv6 allocations au titre de la pr茅c茅dente IPv6 politique d'adresse [RIRv6-Policies] ont imm茅diatement le droit de voir leur allocation 茅tendue 脿 un bloc d'adresse / 32, sans fournir de justification, tant qu'ils satisfont aux crit猫res ci-dessus. Le bloc d'adresse / 32 contiendra le plus petit bloc d'adresse d茅j脿 allou茅 (un ou plusieurs blocs d'adresse / 35 dans de nombreux cas) qui 茅tait d茅j脿 r茅serv茅 par le RIR pour une affectation ult茅rieure 脿 l'organisation. Les demandes d'espace suppl茅mentaire au-del脿 de la taille minimale / 32 seront 茅valu茅es comme indiqu茅 ailleurs dans le document.</p> <hr> <h3>6.6  <a id="Assignments-Internet-Experiments"></a>Assignations pour des essais Internet</h3> <p>Les organisations doivent souvent entreprendre des tests de d茅ploiement pour de nouveaux services et technologies Internet. Elles ont besoin de ressources de num茅rotation pour la dur茅e de l鈥檈ssai.</p> <p>L鈥檕bjectif politique de conservation des ressources rev锚t une moindre importance lorsque des ressources sont allou茅es 脿 titre temporaire.</p> <p class="gt-block"><strong>6.6.1 D茅finition de l'exp茅rience</strong></p> <p class="gt-block">Une organisation qui re莽oit des ressources de num茅rotation doit documenter l鈥檈ssai. Cela peut se faire sous forme de RFC exp茅rimental de l鈥橧ETF (Voir  <a href="http://www.ietf.org/rfc/rfc2026.txt">RFC2026</a>, ou une 芦proposition d'exp茅rimentation禄 d茅taillant les ressources n茅cessaires et les activit茅s 脿 r茅aliser.</p> <p>La taille de l鈥檃ssignation sera 茅quivalente 脿 la taille d鈥檃ttribution minimum 脿 la date de r茅ception de la demande. Lorsque l鈥檈ssai n茅cessite une variation de cette r猫gle, celle-ci doit 锚tre indiqu茅e dans la demande de ressources.</p> <p class="gt-block"><strong>6.6.2 Publication</strong></p> <p>La proposition d'exp茅rience doit 锚tre rendue publique (par exemple publi茅e sur le site web), lors de l'enregistrement des ressources par AFRINIC. Apr猫s la conclusion de l'exp茅rience, les r茅sultats doivent 锚tre publi茅s gratuitement et sans contraintes de divulgation.</p> <p class="gt-block"><strong>6.6.3 Base non commerciale</strong></p> <p>Les ressources 茅mises pour une exp茅rience ne doivent pas 锚tre utilis茅es 脿 des fins commerciales.</p> <p class="gt-block"><strong>6.6.4 P茅riode d'enregistrement temporaire des ressources.</strong></p> <p>Les ressources seront allou茅es 脿 titre temporaire pour une p茅riode d鈥檜n an. L鈥檈nregistrement des ressources peut 锚tre renouvel茅 sur r茅ception d鈥檜ne nouvelle demande qui fournit des d茅tails sur la poursuite de l鈥檈ssai durant la p茅riode de prolongation. </p> <p>Les ressources allou茅es ne peuvent 锚tre utilis茅es 脿 des fins commerciales 脿 l鈥檌ssue de la p茅riode d鈥檈ssai.</p> <p class="gt-block"><strong>6.6.5 Enregistrement</strong></p> <p>AFRINIC enregistrera les ressources 茅mises dans l'AFRINIC whois Base de donn茅es.</p> <hr> <h3>6.7  <a id="HD-T"></a>Rapport HD (HD) et seuil d'utilisation (T)</h3> <p>Le ratio HD ne se substitue pas aux mesures d鈥檜tilisation classiques actuellement effectu茅es par les FAI avec l鈥橧Pv4. En fait, le nombre d鈥檕bjets assign茅s doit toujours 锚tre calcul茅 pour l鈥檃pplication du ratio HD. La valeur premi猫re du ratio HD est son utilit茅 lorsqu鈥檌l s鈥檃git de d茅terminer un seuil d鈥檜tilisation raisonnable pour un espace adresse d鈥檜ne taille donn茅e. Le pr茅sent document utilise le ratio HD pour d茅terminer les seuils auxquels une attribution donn茅e a atteint un niveau d鈥檜tilisation acceptable, justifiant ainsi l鈥檃ssignation d鈥檈spaces adresses suppl茅mentaires.</p> <p>Le seuil d鈥檜tilisation T, exprim茅 en nombre de pr茅fixes /48 脿锚tre attribu茅s 脿 partir du pr茅fixe IPv6 P, peut 锚tre calcul茅 ainsi :</p> <p style="text-align: center;" class="gt-block"><strong>T = 2 ((48-P) * HD)</strong></p> <p>Le seuil d鈥檜tilisation pour une organisation demandant des attributions suivantes de blocs d鈥檃dresses IPv6 est exprim茅 comme une fonction de la taille du pr茅fixe et du ratio HD vis茅. Cette utilisation a trait aux /48 attribu茅s 脿 des sites finaux, pas 脿 l鈥檜tilisation des /48 dans ces sites finaux. C鈥檈st un ratio d鈥檃ttribution d鈥檃dresses et non un ratio d鈥檜tilisation d鈥檃ssignations.</p> <p>Conform茅ment aux recommandations du document technique [RFC 3194], le pr茅sent document adopte un ratio HD de 0.94 comme seuil d鈥檜tilisation pour les attributions d鈥檈spaces adresses IPv6.</p> <p>Le tableau suivant fournit des chiffres d'utilisation absolue et en pourcentage 茅quivalents pour IPv6 pr茅fixes, correspondant 脿 un rapport HD de 0.94.</p> <table class="table table-striped table-bordered table-hover table-responsive"> <tbody> <tr> <td> <p>P</p> </td> <td> <p>48-P</p> </td> <td> <p>Total / 48s</p> </td> <td> <p>Seuil</p> </td> <td> <p>Util%</p> </td> </tr> <tr> <td> <p>48</p> </td> <td> <p>0</p> </td> <td> <p>1</p> </td> <td> <p>1</p> </td> <td> <p>100.0%</p> </td> </tr> <tr> <td> <p>47</p> </td> <td> <p>1</p> </td> <td> <p>2</p> </td> <td> <p>2</p> </td> <td> <p>95.93%</p> </td> </tr> <tr> <td> <p>46</p> </td> <td> <p>2</p> </td> <td> <p>4</p> </td> <td> <p>4</p> </td> <td> <p>92.02%</p> </td> </tr> <tr> <td> <p>45</p> </td> <td> <p>3</p> </td> <td> <p>8</p> </td> <td> <p>7</p> </td> <td> <p>88.27%</p> </td> </tr> <tr> <td> <p>44</p> </td> <td> <p>4</p> </td> <td> <p>16</p> </td> <td> <p>14</p> </td> <td> <p>84.67%</p> </td> </tr> <tr> <td> <p>43</p> </td> <td> <p>5</p> </td> <td> <p>32</p> </td> <td> <p>26</p> </td> <td> <p>81.23%</p> </td> </tr> <tr> <td> <p>42</p> </td> <td> <p>6</p> </td> <td> <p>64</p> </td> <td> <p>50</p> </td> <td> <p>77.92%</p> </td> </tr> <tr> <td> <p>41</p> </td> <td> <p>7</p> </td> <td> <p>128</p> </td> <td> <p>96</p> </td> <td> <p>74.74%</p> </td> </tr> <tr> <td> <p>40</p> </td> <td> <p>8</p> </td> <td> <p>256</p> </td> <td> <p>184</p> </td> <td> <p>71.70%</p> </td> </tr> <tr> <td> <p>39</p> </td> <td> <p>9</p> </td> <td> <p>512</p> </td> <td> <p>352</p> </td> <td> <p>68.78%</p> </td> </tr> <tr> <td> <p>38</p> </td> <td> <p>10</p> </td> <td> <p>1024</p> </td> <td> <p>676</p> </td> <td> <p>65.98%</p> </td> </tr> <tr> <td> <p>37</p> </td> <td> <p>11</p> </td> <td> <p>2048</p> </td> <td> <p>1296</p> </td> <td> <p>63.29%</p> </td> </tr> <tr> <td> <p>36</p> </td> <td> <p>12</p> </td> <td> <p>4096</p> </td> <td> <p>2487</p> </td> <td> <p>60.71%</p> </td> </tr> <tr> <td> <p>35</p> </td> <td> <p>13</p> </td> <td> <p>8192</p> </td> <td> <p>4771</p> </td> <td> <p>58.24%</p> </td> </tr> <tr> <td> <p>34</p> </td> <td> <p>14</p> </td> <td> <p>16384</p> </td> <td> <p>9153</p> </td> <td> <p>55.86%</p> </td> </tr> <tr> <td> <p>33</p> </td> <td> <p>15</p> </td> <td> <p>32768</p> </td> <td> <p>17560</p> </td> <td> <p>53.59%</p> </td> </tr> <tr> <td> <p>32</p> </td> <td> <p>16</p> </td> <td> <p>65536</p> </td> <td> <p>33689</p> </td> <td> <p>51.41%</p> </td> </tr> <tr> <td> <p>31</p> </td> <td> <p>17</p> </td> <td> <p>131072</p> </td> <td> <p>64634</p> </td> <td> <p>49.31%</p> </td> </tr> <tr> <td> <p>30</p> </td> <td> <p>18</p> </td> <td> <p>262144</p> </td> <td> <p>124002</p> </td> <td> <p>47.30%</p> </td> </tr> <tr> <td> <p>29</p> </td> <td> <p>19</p> </td> <td> <p>524288</p> </td> <td> <p>237901</p> </td> <td> <p>45.38%</p> </td> </tr> <tr> <td> <p>28</p> </td> <td> <p>20</p> </td> <td> <p>1048576</p> </td> <td> <p>456419</p> </td> <td> <p>43.53%</p> </td> </tr> <tr> <td> <p>27</p> </td> <td> <p>21</p> </td> <td> <p>2097152</p> </td> <td> <p>875653</p> </td> <td> <p>41.75%</p> </td> </tr> <tr> <td> <p>26</p> </td> <td> <p>22</p> </td> <td> <p>4194304</p> </td> <td> <p>1679965</p> </td> <td> <p>40.05%</p> </td> </tr> <tr> <td> <p>25</p> </td> <td> <p>23</p> </td> <td> <p>8388608</p> </td> <td> <p>3223061</p> </td> <td> <p>38.42%</p> </td> </tr> <tr> <td> <p>24</p> </td> <td> <p>24</p> </td> <td> <p>16777216</p> </td> <td> <p>6183533</p> </td> <td> <p>36.86%</p> </td> </tr> <tr> <td> <p>23</p> </td> <td> <p>25</p> </td> <td> <p>33554432</p> </td> <td> <p>11863283</p> </td> <td> <p>35.36%</p> </td> </tr> <tr> <td> <p>22</p> </td> <td> <p>26</p> </td> <td> <p>67108864</p> </td> <td> <p>22760044</p> </td> <td> <p>33.92%</p> </td> </tr> <tr> <td> <p>21</p> </td> <td> <p>27</p> </td> <td> <p>134217728</p> </td> <td> <p>43665787</p> </td> <td> <p>32.53%</p> </td> </tr> <tr> <td> <p>20</p> </td> <td> <p>28</p> </td> <td> <p>268435456</p> </td> <td> <p>83774045</p> </td> <td> <p>31.21%</p> </td> </tr> <tr> <td> <p>19</p> </td> <td> <p>29</p> </td> <td> <p>536870912</p> </td> <td> <p>160722871</p> </td> <td> <p>29.94%</p> </td> </tr> <tr> <td> <p>18</p> </td> <td> <p>30</p> </td> <td> <p>1073741824</p> </td> <td> <p>308351367</p> </td> <td> <p>28.72%</p> </td> </tr> <tr> <td> <p>17</p> </td> <td> <p>31</p> </td> <td> <p>2147483648</p> </td> <td> <p>591580804</p> </td> <td> <p>27.55%</p> </td> </tr> <tr> <td> <p>16</p> </td> <td> <p>32</p> </td> <td> <p>4294967296</p> </td> <td> <p>1134964479</p> </td> <td> <p>26.43%</p> </td> </tr> <tr> <td> <p>15</p> </td> <td> <p>33</p> </td> <td> <p>8589934592</p> </td> <td> <p>2177461403</p> </td> <td> <p>25.35%</p> </td> </tr> <tr> <td> <p>14</p> </td> <td> <p>34</p> </td> <td> <p>17179869184</p> </td> <td> <p>4177521189</p> </td> <td> <p>24.32%</p> </td> </tr> <tr> <td> <p>13</p> </td> <td> <p>35</p> </td> <td> <p>34359738368</p> </td> <td> <p>8014692369</p> </td> <td> <p>23.33%</p> </td> </tr> <tr> <td> <p>12</p> </td> <td> <p>36</p> </td> <td> <p>68719476736</p> </td> <td> <p>15376413635</p> </td> <td> <p>22.38%</p> </td> </tr> <tr> <td> <p>11</p> </td> <td> <p>37</p> </td> <td> <p>137438953472</p> </td> <td> <p>29500083768</p> </td> <td> <p>21.46%</p> </td> </tr> <tr> <td> <p>10</p> </td> <td> <p>38</p> </td> <td> <p>274877906944</p> </td> <td> <p>56596743751</p> </td> <td> <p>20.59%</p> </td> </tr> <tr> <td> <p>9</p> </td> <td> <p>39</p> </td> <td> <p>549755813888</p> </td> <td> <p>108582451102</p> </td> <td> <p>19.75%</p> </td> </tr> <tr> <td> <p>8</p> </td> <td> <p>40</p> </td> <td> <p>1099511627776</p> </td> <td> <p>208318498661</p> </td> <td> <p>18.95%</p> </td> </tr> <tr> <td> <p>7</p> </td> <td> <p>41</p> </td> <td> <p>2199023255552</p> </td> <td> <p>399664922315</p> </td> <td> <p>18.17%</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>42</p> </td> <td> <p>4398046511104</p> </td> <td> <p>766768439460</p> </td> <td> <p>17.43%</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>43</p> </td> <td> <p>8796093022208</p> </td> <td> <p>1471066903609</p> </td> <td> <p>16.72%</p> </td> </tr> <tr> <td> <p>4</p> </td> <td> <p>44</p> </td> <td> <p>17592186044416</p> </td> <td> <p>2822283395519</p> </td> <td> <p>16.04%</p> </td> </tr> </tbody> </table> <hr> <h3>6.8  <a id="PI-A"></a>Assignations PI</h3> <p>Cette politique vise 脿 fournir l'espace d'adressage IPv6 aux sites finaux.</p> <p class="gt-block"><strong>6.8.1 Introduction</strong></p> <p>Cette politique permet d'attribuer des 芦sites finaux禄 IPv6 adresses ind茅pendantes du fournisseur (PI). Les 芦sites finaux禄 comprennent les utilisateurs finaux et les fournisseurs d'infrastructures critiques tels que les op茅rateurs de serveurs racine TLD et les points d'茅change Internet publics (IXP).</p> <p class="gt-block"><strong>6.8.2 Crit猫res d'attribution</strong></p> <ol style="list-style-type: upper-alpha;"> <li>Cible d'affectation - Sites finaux qui fournissent des services Internet publics pour un seul r茅seau d'organisations administratives, quelle que soit leur taille.</li> <li>Crit猫res d'affectation:<br> je. Le site final ne doit pas 锚tre un LIR<br> ii. Le site final doit devenir un membre utilisateur final AFRINIC et payer les frais AFRINIC normaux pour sa cat茅gorie d'adh茅sion.<br> iii. Le site final doit justifier la n茅cessit茅 de la IPv6 Espace d'adressage PI.<br> iv. Le site final doit montrer un plan d'utilisation du IPv6 espace d'adressage ind茅pendant du fournisseur dans les douze (12) mois. Pass茅 ce d茅lai, s'il n'est pas annonc茅, le IPv6 L'espace d'adressage PI doit 锚tre r茅cup茅r茅 et renvoy茅 au pool gratuit par AFRINIC.<br> v. IPv6 l'espace d'adressage ind茅pendant du fournisseur qui doit 锚tre annonc茅 par le site final ne doit pas 锚tre ventil茅.</li> </ol> <p class="gt-block"><strong>6.8.3 Espace d'adressage ind茅pendant du fournisseur (PI):</strong></p> <ol style="list-style-type: upper-alpha;"> <li>L'affectation ind茅pendante du fournisseur (PI) doit 锚tre effectu茅e 脿 partir d'un bloc sp茅cifique.</li> <li>La taille d'affectation ind茅pendante du fournisseur initial 脿 un site d'extr茅mit茅 doit 锚tre de / 48, ou un pr茅fixe plus court si le site d'extr茅mit茅 peut le justifier.</li> <li>Les attributions suivantes doivent 锚tre document茅es et justifi茅es. Dans la mesure du possible, ces attributions seront effectu茅es 脿 partir d'un bloc d'adresses contigu (c'est-脿-dire en 茅tendant les bits "n" d'affectation existants vers la gauche).</li> </ol> <p class="gt-block"><strong>6.8.4 Rectifier la taille d'une affectation initiale</strong></p> <ol style="list-style-type: upper-alpha;"> <li>Un site final peut soumettre un nouveau plan d'adressage 脿 AFRINIC si le plan initialement soumis pour justifier la mission initiale ne r茅pond plus 脿 leurs besoins actuels.</li> <li>La nouvelle affectation sera conforme au nouveau plan et sera conforme aux 6.8.2 et 6.8.3.</li> <li>Si possible, le m锚me bloc d'adresse sera 芦mis 脿 niveau禄脿 la nouvelle taille de pr茅fixe requise. Cependant, si les pr茅fixes adjacents sont d茅j脿 utilis茅s par d'autres organisations ou si une telle affectation ne laisse pas suffisamment d'espace pour des affectations ult茅rieures, AFRINIC informera l'organisation requ茅rante, qui aura les options suivantes:<br> je. Recevoir un nouveau bloc avec la nouvelle taille de pr茅fixe demand茅e, avec l'engagement de renum茅roter son r茅seau et de retourner le bloc d'origine dans un d茅lai de 6 mois;<br> ii. Recevez un nouveau bloc qui, avec le bloc d茅j脿 attribu茅, couvre le nouveau besoin justifi茅 et conservez les deux blocs.<br> Cette proc茅dure ne peut 锚tre utilis茅e qu'une seule fois par chaque site d'extr茅mit茅.</li> </ol> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>7.0  <a id="ASN"></a>ASN</h2> </div> <div class="panel-body"> <p>Cette section contient des politiques et des directives concernant la demande, l'attribution et l'enregistrement de num茅ros AS (Autonomous System) dans la r茅gion AFRINIC.</p> <hr> <h3>7.1  <a id="ASN-Intro"></a>Introduction</h3> <p>AFRINIC (l'African Network Information Center) est le registre Internet r茅gional pour l'Afrique et une partie de la r茅gion de l'oc茅an Indien (Seychelles, Maurice, Madagascar, Comores). Il est charg茅 de distribuer l'espace d'adressage Internet public et les ressources connexes (y compris les num茅ros de syst猫me autonome) dans la r茅gion et de coordonner l'茅laboration et la mise en 艙uvre des politiques de gestion de ces ressources.</p> <p>Les politiques d茅crites dans ce document ont 茅t茅 d茅velopp茅es par la communaut茅 Internet gr芒ce 脿 un processus de consensus facilit茅 par AFRINIC. Ils doivent 锚tre mis en 艙uvre par AFRINIC.</p> <hr> <h3>7.2  <a id="ASN-Scope"></a>Objectif</h3> <p>Ce document d茅crit les politiques relatives 脿 la distribution, la gestion et l'utilisation des num茅ros de syst猫me autonome (AS) dans la r茅gion de service AFRINIC. Ces politiques s'appliquent 脿 IPv4 et IPv6 les r茅seaux. Les politiques d'autres r茅gions autres que la r茅gion de service AFRINIC n'entrent pas dans le cadre de ce document.</p> <hr> <h3>7.3  <a id="ASN-Definition"></a>D茅finitions</h3> <p>Les termes et d茅finitions suivants sont utilis茅s dans ce document.</p> <ol style="list-style-type: lower-alpha;"> <li><strong>Syst猫me autonome (AS)</strong> - Un syst猫me autonome (AS) est un groupe connect茅 d'un ou plusieurs pr茅fixes IP g茅r茅s par un ou plusieurs op茅rateurs de r茅seau dans le cadre d'une politique de routage unique et clairement d茅finie.</li> <li><strong>Num茅ro du syst猫me autonome (ASN</strong>) <br> <ul> <li>Un num茅ro de syst猫me autonome (ASN) est un entier unique associ茅脿 un AS. le ASN est utilis茅 comme identifiant pour permettre 脿 l'AS d'茅changer des informations de routage dynamique avec d'autres syst猫mes autonomes.</li> <li>Les protocoles de routage ext茅rieurs (tels que le Border Gateway Protocol (BGP) d茅crit dans la RFC 1771) sont utilis茅s avec ASNs pour 茅changer des informations entre les r茅seaux. Un AS utilisera normalement un protocole de passerelle int茅rieure pour 茅changer des informations de routage sur ses r茅seaux internes.</li> <li>Sur 1 Janvier 2011, RIRs a cess茅 de faire une distinction entre les num茅ros AS 脿 2 octets uniquement et les num茅ros AS 脿 4 octets uniquement, et g猫re les attributions de num茅ros AS 脿 partir d'un pool d'allocation de num茅ros AS 脿 4 octets non diff茅renci茅. Conform茅ment 脿 la RFC6793 - <a href="https://tools.ietf.org/html/rfc6793">https://tools.ietf.org/html/rfc6793</a>, le pool de 4 octets de ASNs est 0-4294967295.</li> </ul> </li> <li><strong>R茅seau multi-h茅berg茅</strong> - Un AS multir茅sident est un AS connect茅脿 plus d'un autre AS. Un AS est 茅galement qualifi茅 de multi-h茅berg茅 s'il est connect茅脿 un point d'茅change Internet public.</li> <li><strong>Politique de routage</strong> - La politique de routage d'un AS est une description de la fa莽on dont les pr茅fixes de r茅seau sont 茅chang茅s entre cet AS et d'autres syst猫mes autonomes.</li> <li><strong>objet aut-num</strong> - Un objet aut-num est un objet dans le whois base de donn茅es utilis茅e pour s'inscrire ASN d茅tails de l'affectation.</li> </ol> <hr> <h3>7.4  <a id="ASN-Eligibility"></a>Admissibilit茅脿 l'attribution d'un num茅ro AS</h3> <p>Il est important de d茅terminer quels sites n茅cessitent des num茅ros AS uniques et ceux qui ne n茅cessitent pas de num茅ro AS unique doivent utiliser un ou plusieurs des num茅ros AS r茅serv茅s 脿 un usage priv茅. Ces num茅ros sont les suivants: 64512 脿 65535 (RFC1930).</p> <p>Pour pouvoir pr茅tendre 脿 un num茅ro AS, l'organisation requ茅rante doit remplir les conditions suivantes:</p> <p class="gt-block"><strong>7.4.1 Une politique de routage unique (sa politique diff猫re de ses homologues de la passerelle frontali猫re).</strong></p> <p class="gt-block"><strong>7.4.2 Un site multi-h茅berg茅.</strong></p> <p class="gt-block"><strong>7.4.3 Une organisation sera 茅galement 茅ligible si elle peut d茅montrer qu'elle satisfera aux crit猫res ci-dessus lorsqu'elle recevra ASN (ou dans un d茅lai raisonnablement court par la suite).</strong></p> <p class="gt-block"><strong>7.4.4 Etre membre d'AFRINIC en r猫gle (type utilisateur final ou LIR)</strong></p> <p>Toutes les demandes de ASNs selon ces crit猫res seront 茅valu茅s en utilisant les lignes directrices d茅crites dans la RFC1930 芦Lignes directrices pour la cr茅ation, la s茅lection et l'enregistrement d'un syst猫me autonome (AS).</p> <hr> <h3>7.5  <a id="Ownership-Routing"></a>Consid茅rations relatives 脿 la propri茅t茅 et au routage</h3> <p class="gt-block"><strong>7.5.1 Propri茅t茅</strong></p> <p>La communaut茅 Internet consid猫re ASNs en tant que ressource publique qui ne devrait 锚tre distribu茅e qu'en fonction des besoins d茅montr茅s. Ni la cession ni l'enregistrement ne conf猫rent la propri茅t茅 des ressources. Les organisations qui utilisent ASNs sont consid茅r茅s comme des 芦gardiens禄 plut么t que des 芦propri茅taires禄 de la ressource, et n'ont pas le droit de vendre ou autrement transf茅rer cette ressource 脿 d'autres parties.</p> <p class="gt-block"><strong>7.5.2 Consid茅rations relatives au routage</strong></p> <p>Gestion responsable de ASNs est n茅cessaire pour limiter l'expansion des tables de routage globales. L'agr茅gation de pr茅fixes d'adresses IP contigus au sein de syst猫mes autonomes uniques permet de minimiser le nombre de routes annonc茅es vers Internet mondial.</p> <hr> <h3>7.6  <a id="Assignment-Procedures"></a>Proc茅dures d'assignation</h3> <p>AFRINIC assigne des num茅ros AS pour les syst猫mes autonomes situ茅s dans la r茅gion de service AFRINIC et accepte les demandes des LIR, des non-LIR et des non-membres remplissant les conditions d'茅ligibilit茅 de la section 7.4 du pr茅sent document.</p> <p>AFRINIC peut demander de telles informations qui peuvent aider 脿 comprendre la politique de routage pr茅vue et 脿 d茅cider si un num茅ro AS est r茅ellement n茅cessaire.</p> <p class="gt-block"><strong>7.6.1 Utilisation ASNs pour le r茅seau LIR</strong></p> <p>Attribution aux FAI qui utiliseront le ASN dans leur propre r茅seau sont soumis aux conditions suivantes:</p> <ol> <li>Le FAI demandeur est responsable du maintien de l'enregistrement d茅crit 脿 la section 7.7.</li> <li>Le FAI demandeur a le droit de continuer 脿 utiliser le ASN, m锚me s'ils changent d'homologues du r茅seau ou de fournisseurs de services.</li> </ol> <p>Les LIR avec AFRINIC ne seront pas factur茅s de frais de maintenance annuels pour ASNs.</p> <p class="gt-block"><strong>7.6.2 Fournir ASNs aux non-LIR</strong></p> <p>Les attributions 脿 d'autres organisations qui ne sont pas des LIR sont soumises aux conditions suivantes:</p> <ol> <li>L'entreprise qui utilisera r茅ellement le ASN doit r茅pondre aux crit猫res ci-dessus.</li> <li>L'entreprise requ茅rante est responsable du maintien de l'enregistrement d茅crit ci-dessous.</li> <li>Des frais d'inscription uniques seront factur茅s pour chaque ASN attribu茅, comme d茅crit dans le bar猫me des frais d'AFRINIC. Tous les trois ans par la suite, AFRINIC facturera 脿 l'organisation des frais de maintenance annuels, payables 脿 la date anniversaire de la mission d'origine.</li> </ol> <hr> <h3>7.7  <a id="Registration-Requirements-7-7"></a>Exigences en mati猫re d鈥檈nregistrement</h3> <p>Tous ASNLes attribu茅s doivent 锚tre enregistr茅s publiquement dans l'AFRINIC whois base de donn茅es. AFRINIC cr茅era l'objet 'aut-num' dans la base de donn茅es.</p> <p>Tous les attributs de l'objet 'aut-num' doivent 锚tre correctement enregistr茅s conform茅ment 脿 l'AFRINIC whois documentation de la base de donn茅es.</p> <p class="gt-block"><strong>7.7.1 Enregistrement des personnes de contact</strong></p> <p>Les interlocuteurs administratifs et techniques doivent 锚tre enregistr茅s pour chaque ASN attribu茅. Le contact administratif enregistr茅 (芦admin-c禄) est la personne responsable de la ASN et devrait g茅n茅ralement 锚tre quelqu'un qui est physiquement situ茅 sur le site de l'AS.</p> <p>Le contact technique (芦tech-c禄) ne doit pas n茅cessairement 锚tre physiquement situ茅 sur le site de l'AS, mais doit 锚tre une personne qui est responsable du fonctionnement quotidien de cet AS.</p> <p class="gt-block"><strong>7.7.2 Enregistrement de la politique de routage</strong></p> <p>AFRINIC recommande que la politique de routage de l'AS soit enregistr茅e dans whois Base de donn茅es chacun ASN attribu茅.</p> <p class="gt-block"><strong>7.7.3 Mise 脿 jour des d茅tails d'enregistrement</strong></p> <p>LIR est responsable de ASNs doivent mettre 脿 jour l'objet 'aut-num' dans AFRINIC whois base de donn茅es si l'une des informations d'enregistrement change.</p> <hr> <h3>7.8  <a id="Returning-unused-ASNs"></a>Restitution d鈥橝SN non utilis茅s</h3> <p>Si une ASN n'est pas utilis茅 par l'organisation qui l'a re莽u 脿 l'origine, il doit 锚tre retourn茅. AFRINIC le remettra ensuite dans le pool public de num茅ros AS pour une r茅affectation 脿 un autre syst猫me autonome dans la r茅gion AFRINIC.</p> <hr> <h3>7.9  <a id="Misc"></a>Disposition g茅n茅rale</h3> <p>AFRINIC peut publier d'autres directives concernant ASNs y compris les d茅tails de facturation (frais de r茅cup茅ration de la maintenance) et les accords connexes, les formulaires de demande, une description plus d茅taill茅e des proc茅dures d'茅valuation, des pratiques que le LIR demande ASNs devraient adopter et des informations susceptibles d'aider les organisations 脿 demander ASNs.</p> <p>Toute autre directive publi茅e sera 茅labor茅e au sein de la communaut茅 (si n茅cessaire) et sera conforme aux objectifs et politiques d茅crits dans ce document.</p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>8.0  <a id="Abuse-Contact"></a>Coordonn茅es de contact sp茅cifiques aux cas d鈥檃bus</h2> </div> <div class="panel-body"> <h3>8.1  <a id="Abuse-Contact-Intro"></a>Introduction</h3> <p>Cette politique sp茅cifie un objet d茅di茅 qui doit 锚tre utilis茅 comme lieu pr茅f茅r茅 pour publier des informations de contact public abusives dans la r茅gion de service AFRINIC.</p> <p>L'objet mentionn茅 peut 锚tre r茅f茅renc茅 dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois Base de donn茅es. Il fournit un moyen plus pr茅cis et efficace pour les rapports d'abus d'atteindre le bon contact r茅seau.</p> <hr> <h3>8.2  <a id="AC-Policy"></a>La politique en d茅tail:</h3> <p>Pour rendre disponible un nouveau ou utiliser un d茅j脿 existant whois objet de base de donn茅es qui impl茅mente les propri茅t茅s suivantes:</p> <ol> <li>Une r茅f茅rence unique par inetnum, inet6num et aut-num</li> <li>Contient 2 attributs de messagerie: <ol> <li>"e-mail:" pour la communication personnelle</li> <li>"abuse-mailbox:" pour la gestion automatique des rapports</li> </ol> </li> </ol> <p class="gt-block">L'objet doit 锚tre accessible via le whois protocole. AFRINIC pour publier un <a href="/fr/support/how-to-publish-abuse-contact-information/how-to-publish-abuse-contact?lang=en">Document sur les meilleures pratiques</a> qui encourage tous les membres 脿 utiliser activement l'objet pour publier des informations de contact d'abus.</p> <hr> <h3>8.3  <a id="AD-Policy-Advantages-Disadvantages"></a>Avantages et inconv茅nients de la politique</h3> <p class="gt-block"><strong>8.3.1 Avantages</strong></p> <ol> <li>Les r茅seaux pourront fournir leurs propres coordonn茅es directes aux services d'abus.</li> <li>Les plaintes pour abus ne seront plus envoy茅es au "mauvais" contact.</li> <li>Cela permet une plus grande flexibilit茅 administrative et op茅rationnelle, et un traitement plus rapide des abus sera possible.</li> </ol> <p class="gt-block"><strong>8.3.2 Inconv茅nients</strong></p> <p>Cet objet, comme tous les autres objets existants, sera confront茅 au probl猫me de pr茅cision des donn茅es. Cette politique vise 脿 r茅soudre le probl猫me d'une place manquante pour les coordonn茅es d'abus et n'am茅liorera pas l'exactitude des donn茅es dans le whois base de donn茅es. N茅anmoins, il est sugg茅r茅脿 AFRINIC de proposer un moyen de recevoir des rapports sur des objets non fonctionnels ou non pr茅cis.</p> <p> </p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>9.0  <a id="Temporary-Resource-Allocation"></a>Allocations et assignations de ressources temporaires</h2> </div> <div class="panel-body"> <p>Dans certaines circonstances, les organisations peuvent avoir besoin de ressources IP pendant une certaine p茅riode, g茅n茅ralement un mois et moins. Cela pourrait 锚tre pour des expositions, des conf茅rences, des conventions, etc.</p> <p>AFRINIC attribuera donc des ressources de num茅rotation aux entit茅s n茅cessitant des num茅ros IP temporaires pour une dur茅e d茅termin茅e. Dans ce document, 芦ressources IP禄 fait r茅f茅rence 脿 la monodiffusion IPv4Adresses / v6 et num茅ros AS.</p> <hr> <h3>9.1  <a id="Temp-Doc"></a>Documenter l'activit茅 temporaire</h3> <p>L'activit茅 n茅cessitant des ressources IP temporaires doit 锚tre document茅e publiquement et disponible, de pr茅f茅rence sur un site Web. Les entit茅s n茅cessitant de telles ressources IP doivent d茅montrer qu'elles comprennent que lorsque l'activit茅 ou l'exp茅rience pour laquelle elles ont besoin des ressources IP prend fin, les ressources IP seront retourn茅es 脿 AFRINIC.</p> <p>Un "document accessible au public" est un document qui est publiquement et ouvertement accessible gratuitement et sans aucune contrainte de divulgation.</p> <p>AFRINIC ne reconna卯tra aucune activit茅 dans le cadre de cette politique si une telle activit茅 ne peut 锚tre rendue publique.</p> <hr> <h3>9.2  <a id="Assignments-IP-Resources"></a>Affectations de ressources IP</h3> <p>Les ressources sont attribu茅es sur une base de location pour une p茅riode d'un mois. La mission peut 锚tre renouvel茅e sur demande aupr猫s d'AFRINIC en fournissant les informations n茅cessaires. La taille de la ressource IP attribu茅e sera d茅termin茅e 脿 partir du plan soumis par l'entit茅 requ茅rante.</p> <p class="gt-block"><strong>9.2.1 Documentation requise:</strong></p> <p>L'organisme demandeur doit contacter AFRINIC avec les informations suivantes:</p> <ol> <li>D茅tails de l'organisation: nom de l'organisation l茅gale, pays d'enregistrement, adresse postale, adresse physique, num茅ros de t茅l茅phone et de fax, site Web (c'est un must).</li> <li>D茅tails de l'activit茅 n茅cessitant une affectation temporaire: site Web d茅taillant l'activit茅 ou site Web avec un lien vers des activit茅s pr茅c茅dentes similaires, liens 脿 partir d'autres sites (pertinents) sur cette activit茅, et date 脿 laquelle l'activit茅 ci-dessus se termine.</li> <li>Utilisation pr茅vue de ces ressources IP: indiquez la taille de sous-r茅seau requise et son utilisation, ainsi que les num茅ros AS et la d茅l茅gation inverse, si n茅cessaire.</li> <li>La date de retour pr茅vue des ressources IP ci-dessus.</li> </ol> <hr> <h3>9.3  <a id="Admin-Fees"></a>Taxes administratives</h3> <p>AFRINIC peut facturer des frais administratifs (si n茅cessaire) pour l'attribution des num茅ros IP temporaires ci-dessus.</p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>10.0  <a id="Reverse-Delegation"></a>D茅l茅gation inverse</h2> </div> <div class="panel-body"> <p>Cette section d茅crit la politique de d茅l茅gation inverse des assignations et attributions IPv4 et IPv6 dans la r茅gion desservie par AfriNIC. Veuillez noter que les registres AfriNIC ne font qu'inverser les d茅l茅gations et ne sont pas impliqu茅s dans le syst猫me d'enregistrement des noms de domaine.</p> <hr> <h3>10.1  <a id="RD-Intro"></a>Introduction</h3> <p>AFRINIC fournit un support pour permettre aux applications de mapper vers un nom de domaine 脿 partir d'une adresse IP. La d茅l茅gation inverse est obtenue par l'utilisation de in-addr.arpa (IPv4) et ip6.arpa (IPv6) domaines.</p> <hr> <h3>10.2  <a id="Obtaining-Delegation"></a>Obtention de la d茅l茅gation d'une sous-zone in-addr.arpa</h3> <p>AFRINIC accepte uniquement les demandes de d茅l茅gation invers茅e sous in-addr.arpa des LIR AFRINIC actifs. Les utilisateurs finaux doivent envoyer leurs demandes au LIR 脿 partir duquel ils ont obtenu les adresses, ou dans le cas des adresses ind茅pendantes du fournisseur, 脿 l'un des LIR de leur choix. AFRINIC effectuera des tests pour s'assurer que le serveur de noms pour la zone pour laquelle la d茅l茅gation inverse est demand茅e est en place et configur茅 conform茅ment aux recommandations de la RFC1912.</p> <hr> <h3>10.3  <a id="RD-PA"></a>D茅l茅gation inverse pour l'espace d'adressage li茅 au fournisseur d鈥檃cc猫s (PA)</h3> <p>AfriNIC ne fera que des d茅l茅gations sur des fronti猫res de 8 bits (/16 ou /24). Des d茅l茅gations multiples peuvent 锚tre appel茅es 脿 couvrir les pr茅fixes CIDR de longueur sup茅rieure 脿 /24.</p> <hr> <h3>10.4  <a id="RD-PI"></a>D茅l茅gation inverse pour l'espace d'adressage ind茅pendant du fournisseur (PI)</h3> <p>AFRINIC inversera la d茅l茅gation d'une zone dans in-addr.arpa 脿 un utilisateur final auquel un espace PI a 茅t茅 attribu茅.</p> <p>Pour les d茅l茅gations de blocs d'adresses inf茅rieurs 脿 a / 24, la m茅thode d茅crite dans 芦D茅l茅gation IN-ADDR.ARPA sans classe禄 [RFC 2317] sera utilis茅e.</p> <hr> <h3>10.5  <a id="RD-Validity"></a>Validit茅 de la d茅l茅gation inverse</h3> <p>10.5.1 AFRINIC accepte les demandes de d茅l茅gation et les modifications des d茅l茅gations des LIR dont le statut de membre est 脿 jour.</p> <p>10.5.2 Aucun service DNS invers茅 en l'absence d'affectations enregistr茅es:</p> <ol> <li>Aucune d茅l茅gation inverse de l'espace d'adressage IP administr茅 / allou茅 n'est autoris茅e 脿 moins qu'une attribution ou une sous-allocation de l'allocation d'adresse sp茅cifique ne soit enregistr茅e de mani猫re appropri茅e dans l'AFRINIC whois base de donn茅es. </li> <li>Pour une d茅l茅gation invers茅e / 24, au moins une affectation ou sous-allocation doit 锚tre enregistr茅e dans la base de donn茅es AFRINIC pour ce / 24 sp茅cifique. Il n'est pas n茅cessaire d'attribuer l'int茅gralit茅 du / 24 pour que la d茅l茅gation inverse soit autoris茅e.</li> </ol> <hr> <h3>10.6 <a id="IPv6-RD"></a> D茅l茅gation inverse IPv6 </h3> <p class="gt-block">Le consensus de l'IETF a 茅t茅 atteint pour que le domaine ip6.arpa soit utilis茅 pour le mappage d'adresse en nom DNS pour le IPv6 espace d'adressage. Faire r茅f茅rence 脿 <a href="http://www.ietf.org/rfc/rfc2874.txt">RFC2874</a> et  <a href="http://www.ietf.org/rfc/rfc3596.txt">RFC3596</a>.</p> <p>La d茅l茅gation du domaine ip6.arpa est effectu茅e par Internet Assigned Numbers Authority (IANA). Les noms dans cette zone sont d茅l茅gu茅s aux registres Internet r茅gionaux conform茅ment 脿 leur d茅l茅gation respective de IPv6 espace d'adressage.</p> <hr> <h3>10.7 <a id="lame"></a>Suppression des d茅l茅gations 芦Lame禄</h3> <p>Une fois qu'un attribut 芦nserver禄 donn茅 a 茅t茅 d茅termin茅 comme 茅tant boiteux pour un domaine donn茅, et que des tentatives raisonnables ont 茅t茅 faites pour contacter la ou les personnes responsables, l'attribut nserver doit ensuite 锚tre supprim茅 de l'objet de domaine donn茅. Une ligne 芦remarques禄 doit 锚tre ajout茅e 脿 l'objet de domaine dans la base de donn茅es enregistrant cela.</p> <p>Dans le cas o霉 tous les enregistrements de serveur de noms sont boiteux pour une d茅l茅gation donn茅e, l'objet de domaine serait supprim茅 dans son int茅gralit茅. Les informations historiques sur les objets de domaine supprim茅s doivent 锚tre archiv茅es pendant une dur茅e raisonnable et mises 脿 disposition si n茅cessaire.</p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>11.0  <a id="Resource-Reservations-IXPa"></a>R茅servations de ressources pour les points d'茅change Internet</h2> </div> <div class="panel-body"> <p>Cette politique demande 脿 AFRINIC de r茅server et de publier IPv4 les ressources, et ASNs 脿 l'usage des IXP uniquement. </p> <hr> <h3>11.1 Introduction</h3> <p>Il est commun茅ment admis que les points d'茅change Internet (IXP) sont l'un des 茅l茅ments essentiels n茅cessaires au d茅veloppement des 茅cosyst猫mes Internet. L'Afrique est toujours en train de d茅velopper des IXP et est en m锚me temps confront茅e 脿 l'茅puisement imminent de ses ressources IPv4. </p> <p>Ne pas avoir IPv4 des adresses pour d茅velopper ou d茅marrer de nouveaux IXP cr茅eraient une complexit茅 de routage inutile et inutile pour les r茅seaux connect茅s 脿 Internet, cherchant 脿 regarder les IXP pour 茅tendre leur r茅seau.</p> <p>AFRINIC dispose d茅j脿 d'une politique existante pour effectuer des allocations aux IXP [1], mais cette politique ne r茅serve pas sp茅cifiquement d'espace IPV4 pour garantir qu'il y en aura, pour que les futurs IXP puissent cro卯tre et se d茅velopper. De plus, cette politique r茅serve un ensemble de ASNs entre 0 et 65535 pour une utilisation par les IXP, pour les serveurs de routage IXP BGP. </p> <hr> <h3>11.2 Distinction entre l'appairage IXP et les r茅seaux de gestion</h3> <p>Nous distinguons deux types de ressources de num茅ros IP n茅cessaires et utilis茅s aux IXP. </p> <p>Un LAN d'茅change IXP est le bloc contigu d'adresses de r茅seau que l'IXP utiliserait pour attribuer des adresses IP uniques 脿 chaque membre de peering pour permettre 脿 chaque participant au peering d鈥櫭ヽhanger le trafic r茅seau 脿 travers l'infrastructure de peering partag茅e. La meilleure pratique est de ne pas rendre visible le r茅seau LAN de l鈥橧XP dans la table de routage globale, entre autres pour r茅duire les vecteurs d'attaque pour les routeurs de fronti猫re ISP via l'IXP. </p> <p>Du point de vue de l'identification, de la surveillance et de l'analyse d'un r茅seau, il est donc souhaitable que l'espace "LAN d'appairage" soit fourni 脿 partir d'un bloc contigu. Le LAN de gestion de l'IXP est le r茅seau de gestion utilis茅 par l'IXP pour fournir des services sur l'IXP, comme la surveillance, les statistiques, le courrier, les syst猫mes de tickets, l'approvisionnement du transit vers les racines DNS, etc. Les r茅seaux de gestion sont cens茅s 锚tre accessibles 脿 l'茅chelle mondiale, par exemple pour publier des donn茅es et permettre l'acc猫s 脿 distance 脿 une bonne infrastructure de r茅seau (comme les serveurs DNS racine et TLD) et 脿 des projets de recherche. </p> <hr> <h3>11.3 Utilisation des serveurs de route BGP</h3> <p>En r猫gle g茅n茅rale, les IXP utilisent des serveurs de routage BGP pour aider 脿 g茅rer les sessions d'appairage entre diff茅rents participants. Les serveurs de routage mettent en 艙uvre la politique de routage IXP sous la forme de communaut茅s BGP, g茅n茅ralement sous la forme A: B, o霉 A, B repr茅sentent A = serveur de routage IXP BGP et B = participant ASN. </p> <p>Les impl茅mentations BGP actuelles utilisent 6 octets pour l'attribut de communaut茅茅tendue. Par cons茅quent, un IXP avec un octet 4 ASN en cours d'utilisation sur son serveur de routage ne serait pas en mesure de mettre en 艙uvre avec succ猫s le mappage de communaut茅 BGP A: B, si un participant IXP a un octet de 4 octets ASN. Cette situation est susceptible d'锚tre v茅cue par plus d'IXP, comme 4 octets suppl茅mentaires ASNs sont attribu茅s dans le cadre du processus AFRINIC actuel. </p> <p>Si les communaut茅s de serveurs de routage IXP incluent l'ASN participant 脿 l鈥橧XP et l'ASN du pair (qui devrait 锚tre 4 octets) et que seulement 6 octets au total sont disponibles, l'ASN des serveurs de routage IXP ne pourra pas d茅passer 2 octets. </p> <hr> <h3>11.4 D茅tail de la politique</h3> <p>Pour s'assurer qu'il y ait suffisamment de ressources pour le fonctionnement des IXP, cette politique propose qu'AfriNIC r茅serve des adresses IPv4 pour les r茅seaux locaux de peering 脿 partir d'un bloc d'adresses r茅serv茅 particuli猫rement et exclusivement 脿 l'utilisation du LAN d鈥櫭ヽhange IXP. </p> <p>Les affectations pour les r茅seaux locaux homologues IXP doivent provenir d'un bloc d茅di茅, publi茅 comme tel par AFRINIC. Les attributions de Peering LAN pour chaque IXP doivent garantir que le bloc IP adjacent / 24 est r茅serv茅 (sur la base de la taille minimale de la politique d'attribution de l'utilisateur final de / 24) pour prendre en charge la croissance future de l'IXP. Cela permettra 脿 un IXP d'augmenter ses ressources LAN d'appairage 脿 / 23 sans avoir 脿 renum茅roter vers une nouvelle allocation de bloc IP contigu毛. </p> <p>Les assignations d鈥檃dresses de gestion IXP NE DOIVENT PAS 锚tre effectu茅es 脿 partir du m锚me bloc que celui des LAN d鈥櫭ヽhange IXP. </p> <p>Il est propos茅 qu'un bloc / 16 soit r茅serv茅 pour les besoins futurs des r茅seaux locaux homologues IXP dans la r茅gion de service AFRINIC, et qu'AFRINIC publie ce bloc en tant que tel. De plus, les attributions pour le r茅seau local homologue IXP devraient r茅server le bloc IP contigu / 24 adjacent au IXP demandeur pour une croissance future.</p> <p>Ces r茅servations seront maintenues jusqu'脿 ce que le pool disponible des / 16 ne puisse plus attribuer / 23 affectations. Par la suite, de nouvelles demandes peuvent 锚tre attribu茅es 脿 partir de l'espace r茅serv茅 d茅tenu pour la croissance future de l'IXP. Il est en outre propos茅 de r茅server l'茅quivalent d'un bloc / 16 suppl茅mentaire pour les pr茅fixes de gestion IXP, distinct des r茅seaux locaux d'appairage. </p> <p>Il est propos茅 que AFRINIC r茅serve un bloc de ASNs entre 0 et 65535 XNUMX pour une utilisation dans les serveurs de routage BGP des points IXP dans la r茅gion de service AFRINIC. Le nombre de ASNs 脿 r茅server doit 锚tre le plus 茅lev茅 de 114, ou la moiti茅 du reste ASNs entre 0 et 65535 dans le bloc d'AFRINIC 脿 la date de ratification de cette politique. AFRINIC allouera ces ressources sur la base du premier arriv茅, premier servi. </p> <hr> <h3>11.5 Crit猫res d'茅valuation</h3> <p>Cette politique ne sugg猫re pas de nouveaux crit猫res d'茅valuation pour d茅terminer la validit茅 d鈥檜n IXP. </p> <p> </p> </div> </div> <div class="panel panel-default"> <div class="panel-heading"> <h2>12.0  <a id="Anycast"></a>Assignation de ressources Anycast</h2> </div> <div class="panel-body"> <p>Cette politique permet 脿 une organisation de recevoir une assignation ou une attribution IPv4 / IPv6 et un num茅ro AS uniquement pour une utilisation anycast ou GXS (RoX Exchange).</p> <hr> <h3>12.1 R茅sum茅</h3> <p>Cette politique permet l'utilisation de:</p> <ol> <li>Un bloc /1 IPv24 pour les services anycast 脿 partir d'une attribution PA obtenue d'un LIR ou d'un utilisateur final direct.</li> <li>Un bloc /48 d'IPv6 pour les services anycast 脿 partir d'une attribution IPv6 obtenue d'un LIR ou d'un utilisateur final direct.</li> <li>Un num茅ro AS pour une utilisation anycast.</li> </ol> <p>Le personnel d'AFRINIC envisagera toute diffusion IPv4/IPv6 blocs attribu茅s pour 锚tre 芦pleinement utilis茅s禄 par le LIR lors de l'examen de l'utilisation pour la premi猫re allocation ou pour une allocation suppl茅mentaire 脿 un LIR.</p> <hr> <h3>12.2 脡nonc茅 de politique</h3> <p class="gt-block"><strong>12.2.1 Une organisation peut obtenir un (1) / 24 IPv4 et / ou un (1) / 48 IPv6 pr茅fixe 脿 des fins de diffusion ou GRX 脿 partir d'une attribution ou d'une attribution directe d'utilisateur final 茅mise par AFRINIC.</strong></p> <p>Un num茅ro AS doit 茅galement 锚tre d茅livr茅 aux m锚mes fins sur demande. Ces ressources doivent 锚tre utilis茅es dans le seul but de fournir des services anycast. Celles-ci IPv4/IPv6 les pr茅fixes compteront comme 茅tant pleinement utilis茅s lorsqu'une organisation demande des ressources suppl茅mentaires. Les crit猫res d'utilisation qui s'appliquent 脿 tous IPv4 et IPv6 les demandes d'attribution ou d'attribution initiales seront supprim茅es pour les demandes d'assignation 脿 diffusion multiple.</p> <p class="gt-block"><strong>12.2.2 Les blocs utilis茅s pour les services anycast ne peuvent pas 锚tre attribu茅s ou sous-attribu茅s.</strong></p> <p> Ils doivent 锚tre class茅s 芦 ASSIGNED ANYCAST 禄 dans la base de donn茅es Whois d鈥橝friNIC.</p> <p> </p> </div> </div> </div> <div class="article-footer-wrap"> <div class="article-footer-top"> <div class="helix-social-share"> <div class="helix-social-share-icon"> <ul> <li> <div class="facebook" data-toggle="tooltip" data-placement="top" title="Share On Facebook"> <a class="facebook" onclick="window.open('http://www.facebook.com/sharer.php?u=http://afrinic.net/cpm-1-3','Facebook','width=600,height=300,left='+(screen.availWidth/2-300)+',top='+(screen.availHeight/2-150)+''); return false;" href="http://www.facebook.com/sharer.php?u=http://afrinic.net/fr/cpm-1-3"> <i class="fa fa-facebook"></i> </a> </div> </li> <li> <div class="twitter" data-toggle="tooltip" data-placement="top" title="Share On Twitter"> <a class="twitter" onclick="window.open('http://twitter.com/share?url=http://afrinic.net/cpm-1-3&text=Consolidated%20Policy%20Manual%20(v1.3)','Twitter share','width=600,height=300,left='+(screen.availWidth/2-300)+',top='+(screen.availHeight/2-150)+''); return false;" href="http://twitter.com/share?url=http://afrinic.net/fr/cpm-1-3&text=Consolidated%20Policy%20Manual%20(v1.3)"> <i class="fa fa-twitter"></i> </a> </div> </li> <li> <div class="google-plus"> <a class="gplus" data-toggle="tooltip" data-placement="top" title="Partager sur Google Plus" onclick="window.open('https://plus.google.com/share?url=http://afrinic.net/cpm-1-3','Google plus','width=585,height=666,left='+(screen.availWidth/2-292)+',top='+(screen.availHeight/2-333)+''); return false;" href="https://plus.google.com/share?url=http://afrinic.net/fr/cpm-1-3"> <i class="fa fa-google-plus"></i></a> </div> </li> <li> <div class="linkedin"> <a class="linkedin" data-toggle="tooltip" data-placement="top" title="Partager sur Linkedin" onclick="window.open('http://www.linkedin.com/shareArticle?mini=true&url=http://afrinic.net/cpm-1-3','Linkedin','width=585,height=666,left='+(screen.availWidth/2-292)+',top='+(screen.availHeight/2-333)+''); return false;" href="http://www.linkedin.com/shareArticle?mini=true&url=http://afrinic.net/fr/cpm-1-3"> <i class="fa fa-linkedin-square"></i></a> </div> </li> </ul> </div> </div>  </div> </div> <div class="printfriendly-button-wrapper" style="text-align: right"><a class="printfriendly-button print-no" style="cursor: pointer" onclick="window.print(); return false;" title="Print Friendly, PDF & Email"><img style="border:none;-webkit-box-shadow:none; box-shadow:none;" src="https://cdn.printfriendly.com/buttons/printfriendly-button-lg.png" alt="Print Friendly, PDF & Email"></a></div> <dd class="modified"> <i class="fa fa-calendar-o"></i> Derni猫re modification le - <time datetime="2023-05-06T09:51:57+04:00" itemprop="dateModified" title="Last Modified on - "> 06 mai 2023 </time> </dd> </article></div></div></div></section></div><section id="sp-footer-menu" class=" hidden-xs"><div class="container"><div class="row"><div id="sp-position1" class="col-sm-3 col-md-3"><div class="sp-column font9"><div class="sp-module "><h3 class="sp-module-title">Services aux membres</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3705"><a href="/fr/membership"> Devenir membre</a></li><li class="item-3697"><a href="/fr/resources-2"> Gestion des ressources des num茅ros Internet</a></li><li class="item-3698"><a href="/fr/asn-2"> Num茅ro du syst猫me autonome (ASN)</a></li><li class="item-3699"><a href="/fr/ipv6-2"> Protocole Internet version 6 (IPv6)</a></li><li class="item-3700"><a href="/fr/transfers-2"> Transferts de ressources</a></li><li class="item-3701"><a href="/fr/management-2"> Gestion des ressources</a></li></ul> </div></div></div></div><div id="sp-position2" class="col-sm-3 col-md-3"><div class="sp-column font9"><div class="sp-module "><h3 class="sp-module-title">S茅curit茅 du routage</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3702"><a href="/fr/resource-certification-2"> Programme de certification des ressources (RPKI)</a></li><li class="item-3703"><a href="/fr/tal-2"> Localisateur d'ancrage de confiance (TAL)</a></li><li class="item-3704"><a href="/fr/internet-routing-registry-2"> Registre de routage Internet (IRR)</a></li></ul> </div></div><div class="sp-module "><h3 class="sp-module-title">DNS</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3718"><a href="/fr/reverse-dns-2"> DNS inverse</a></li><li class="item-3716"><a href="/fr/dnssec-2"> Programme DNSSEC</a></li><li class="item-3717"><a href="/fr/dns-support-2"> Programme de support DNS</a></li></ul> </div></div></div></div><div id="sp-position3" class="col-sm-3 col-md-3"><div class="sp-column font9"><div class="sp-module "><h3 class="sp-module-title">WHOIS</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3706"><a href="/fr/whois-2"> WHOIS</a></li><li class="item-3707"><a href="/fr/terms-2"> Conditions d鈥檜tilisation</a></li><li class="item-3708"><a href="/fr/utilities-2"> WHOIS Crypte</a></li><li class="item-3709"><a href="/fr/ip-tools-2"> Outils IP</a></li><li class="item-3710"><a href="/fr/data-protection-2"> Votre protection des donn茅es</a></li><li class="item-3712"><a href="/fr/lame-2"> Outil Lame</a></li><li class="item-3713"><a href="/fr/whois/rdap"> RDAP`</a></li></ul> </div></div></div></div><div id="sp-position4" class="col-sm-3 col-md-3"><div class="sp-column font9"><div class="sp-module "><h3 class="sp-module-title">Formation</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3715"><a href="http://learn.afrinic.net/" target="_blank"> Services de formation</a></li><li class="item-3714"><a href="http://learn.afrinic.net/events" target="_blank"> Ateliers de formation</a></li></ul> </div></div><div class="sp-module "><h3 class="sp-module-title">Ev猫nments</h3><div class="sp-module-content"><ul class="nav menu"> <li class="item-3719"><a href="https://meeting.afrinic.net"> Nos r茅unions</a></li><li class="item-3720"><a href="/fr/webinar-series-2"> S茅rie de webinaires</a></li><li class="item-3721"><a href="/fr/past-webinars-2"> Webinaires pass茅s</a></li></ul> </div></div></div></div></div></div></section><section id="sp-bottom" class="font9 hidden-xs"><div class="container"><div class="row"><div id="sp-bottom1" class="col-xs-6 col-sm-6 col-md-4"><div class="sp-column font9"><ul class="social-icons"><li><a target="_blank" href="https://www.facebook.com/afrinic"><i class="fa fa-facebook"></i></a></li><li><a target="_blank" href="https://twitter.com/afrinic"><i class="fa fa-twitter"></i></a></li><li><a target="_blank" href="https://www.youtube.com/c/AFRINIC"><i class="fa fa-youtube"></i></a></li><li><a target="_blank" href="https://twitter.com/afrinic"><i class="fa fa-linkedin"></i></a></li><li><a target="_blank" href="https://www.flickr.com/photos/afrinic/"><i class="fa fa-flickr"></i></a></li><li><a target="_blank" href="/fr/news/feed?format=feed&type=rss"><i class="fa fa-rss"></i></a></li></ul></div></div><div id="sp-time" class="col-xs-6 col-sm-4 col-md-4"><div class="sp-column time"><div class="sp-module "><div class="sp-module-content"> <span class="mod_datetime">Date et heure 脿 Maurice - <time datetime="2025-03-27T20:03:00+04:00">2025/03/27 <span id="mod_datetime_custom_time_301"></span> <script type="text/javascript">  </script></time></span> </div></div></div></div><div id="sp-bottom2" class="col-xs-6 col-sm-6 col-md-4 hidden-xs"><div class="sp-column font9"><div class="sp-module "><div class="sp-module-content"> <div class="custom"> <p style="text-align: right;" class="gt-block"><a title="Statut des services en ligne AFRINIC" href="http://status.afrinic.net/" target="_blank" rel="help noopener noreferrer">Statuts des services</a> | <a href="/fr/changelog" rev="contents">Changelog</a> | <a href="/fr/support?lang=en" data-mce-empty="1"> </a><a href="/fr/website-use-terms?lang=en-GB" target="_blank" rel="noopener noreferrer" rev="contents">Clause de non-responsabilit茅</a> |  <a href="/fr/privacy" target="_blank" rel="noopener noreferrer">politique de confidentialit茅</a></p></div> </div></div></div></div></div></div></section><footer id="sp-footer" class=" affix-bottom"><div class="container"><div class="row"><div id="sp-footer1" class="col-sm-12 col-md-12"><div class="sp-column font9"><span class="sp-copyright"><div align="center">漏 Copyright <script>document.write( new Date().getFullYear() );</script>. Tous droits r茅serv茅s - African Network Information Centre <a href="https://afrinic.net/fr" target="_blank"> (AFRINIC)</a><br><img src="http://afrinic.net/ast/img/afrinic-logo/afrinic-iso.svg" alt="" width="60" height="40"></div></span></div></div></div></div></footer> </div>    <div class="offcanvas-menu"> <a href="#" class="close-offcanvas"><i class="fa fa-remove"></i></a> <div class="offcanvas-inner"> <div class="sp-module "><div class="sp-module-content"><ul class="nav menu"> <li class="item-161 deeper parent"><a href="/fr/about"> 脌 Propos</a><span class="offcanvas-menu-toggler collapsed" data-toggle="collapse" data-target="#collapse-menu-161"><i class="open-icon fa fa-angle-down"></i><i class="close-icon fa fa-angle-up"></i></span><ul class="collapse" id="collapse-menu-161"><li class="item-880"><a href="/fr/history"> Notre Histoire</a></li><li class="item-3490"><a href="/fr/partners"> Nos partenaires</a></li><li class="item-332"><a href="/fr/membership"> Adh茅sion</a></li><li class="item-3491"><a href="/fr/service-region"> Notre r茅gion de service</a></li><li class="item-2627"><a href="/fr/agmm"> AGMM</a></li><li class="item-1437"><a href="/fr/membership/cost"> Les Tarifs</a></li><li class="item-808"><a href="/fr/governance"> Gouvernance</a></li><li class="item-809"><a href="/fr/stats"> Statistique</a></li><li class="item-334"><a href="/fr/corporate-documents"> Documents d'entreprise</a></li><li class="item-335"><a href="/fr/team"> Notre 茅quipe </a></li><li class="item-336"><a href="/fr/contact"> Contactez-nous</a></li></ul></li><li class="item-829 deeper parent"><a href="/fr/our-work"> Notre Travail</a><span class="offcanvas-menu-toggler collapsed" data-toggle="collapse" data-target="#collapse-menu-829"><i class="open-icon fa fa-angle-down"></i><i class="close-icon fa fa-angle-up"></i></span><ul class="collapse" id="collapse-menu-829"><li class="item-520"><a href="/fr/membership"> Services aux membres</a></li><li class="item-518"><a href="/fr/resources"> Gestion des ressources des num茅ros Internet</a></li><li class="item-3685"><a href="/fr/reverse-dns"> DNS inverse</a></li><li class="item-517"><a href="/fr/whois"> WHOIS</a></li><li class="item-1775"><a href="/fr/membership/cost"> Les Tarifs</a></li><li class="item-674"><a href="/fr/internet-routing-registry"> Registre de routage Internet (IRR)</a></li><li class="item-675"><a href="/fr/dnssec"> Programme DNSSEC</a></li><li class="item-677"><a href="/fr/resource-certification"> Programme de certification des ressources (RPKI)</a></li><li class="item-521"><a href="/fr/corporate-documents"> Documents d'entreprise</a></li><li class="item-522"><a href="http://learn.afrinic.net/" target="_blank"> Services de formation</a></li><li class="item-730"><a href="/fr/support"> Support et FAQ</a></li><li class="item-2794"><a href="/fr/changelog"> Changelog des services en ligne</a></li><li class="item-672"><a href="/fr/dns-support"> Programme de support DNS</a></li><li class="item-678"><a href="/fr/root-server-copy"> Programme de copie de serveur racine</a></li><li class="item-3695"><a href="/fr/internet-development-programs"> Programmes de d茅veloppement Internet</a></li></ul></li><li class="item-163 alias-parent-active deeper parent"><a href="/fr/participate"> Participer</a><span class="offcanvas-menu-toggler collapsed" data-toggle="collapse" data-target="#collapse-menu-163"><i class="open-icon fa fa-angle-down"></i><i class="close-icon fa fa-angle-up"></i></span><ul class="collapse" id="collapse-menu-163"><li class="item-602"><a href="/fr/code"> Code de Conduite </a></li><li class="item-603"><a href="/fr/email"> E-mails et listes de diffusion</a></li><li class="item-604 alias-parent-active"><a href="/fr/policy"> D茅veloppement de politiques:</a></li><li class="item-3382"><a href="/fr/committees/afgwg"> Gouvernements</a></li><li class="item-605"><a href="/fr/committees"> Comit茅s</a></li><li class="item-606"><a href="/fr/election-process"> 脡lections</a></li><li class="item-607"><a href="/fr/exhaustion"> 脡puisement IPv4 </a></li><li class="item-608"><a href="/fr/internet-governance"> Gouvernance Internet</a></li><li class="item-2239"><a href="/fr/privacy"> politique de confidentialit茅</a></li><li class="item-3756"><a href="/fr/participate-kpt/global-policies"> Politiques globales</a></li></ul></li><li class="item-164 deeper parent"><a href="/fr/events"> Ev猫nments</a><span class="offcanvas-menu-toggler collapsed" data-toggle="collapse" data-target="#collapse-menu-164"><i class="open-icon fa fa-angle-down"></i><i class="close-icon fa fa-angle-up"></i></span><ul class="collapse" id="collapse-menu-164"><li class="item-700"><a href="https://meeting.afrinic.net" target="_blank"> R茅unions</a></li><li class="item-701"><a href="/fr/events/sponsorship"> Possibilit茅s de sponsoring</a></li><li class="item-802"><a href="/fr/events/hosting-guide"> Guide pour organiser une R茅union d'AFRINIC</a></li><li class="item-703"><a href="http://learn.afrinic.net/events" target="_blank"> Ateliers de formation</a></li><li class="item-938"><a href="/fr/outreach"> Outreach</a></li><li class="item-3673"><a href="/fr/events/webinar-series"> S茅rie de webinaires</a></li></ul></li><li class="item-756 deeper parent"><a href="/fr/news"> M茅dias</a><span class="offcanvas-menu-toggler collapsed" data-toggle="collapse" data-target="#collapse-menu-756"><i class="open-icon fa fa-angle-down"></i><i class="close-icon fa fa-angle-up"></i></span><ul class="collapse" id="collapse-menu-756"><li class="item-757"><a href="/fr/news"> Actualit茅s</a></li><li class="item-758"><a href="/fr/press"> Communiqu茅s de presse</a></li><li class="item-759"><a href="/fr/presentations"> Pr茅sentations</a></li><li class="item-761"><a href="/fr/factsheets"> Fiches d'information</a></li><li class="item-947"><a href="/fr/newsletter"> Infolettre</a></li><li class="item-2636"><a href="/fr/branding"> personnalis茅</a></li><li class="item-3377"><a href="/fr/post-guidelines"> Directives de contribution</a></li></ul></li><li class="item-3734"><a href="https://blog.iso.afrinic.net/"> Blog</a></li></ul> </div></div> </div>  </div>   <script> function autoDetect() { var current_language = document.querySelector('html').getAttribute("lang") if(current_language == "*" || !current_language) current_language = 'en'; var accept_language = navigator.language.toLowerCase() || navigator.userLanguage.toLowerCase(); switch(accept_language) { case 'zh-cn': case 'zh': var preferred_language = 'zh-CN'; break; case 'zh-tw': case 'zh-hk': var preferred_language = 'zh-TW'; break; default: var preferred_language = accept_language.substr(0, 2); break; } var lg_flag = document.querySelector(".sp-module-content .notranslate option[onclick*='en|"+ preferred_language +"']"); var expiryDate = new Date(); expiryDate.setMonth(expiryDate.getMonth() + 1); if(preferred_language != current_language && lg_flag && document.cookie.match('gt_auto_switch') == null ) { document.cookie = 'gt_auto_switch=1; expires='+ expiryDate.toGMTString() +'; path=/;'; doGTranslate('en|'+preferred_language); } } autoDetect(); </script>  <script> var default_language = "en"; function switch_active_language(){ var current_lang = document.querySelector('html').getAttribute('lang') || default_language; if(current_lang == "en-gb") current_lang = "en"; var select_query = document.querySelector('#sp-top1 select option[value="en|'+ current_lang +'"]'); if(select_query) select_query.setAttribute("selected", "selected"); } //Change selected to current language jQuery(document).ready(function() { switch_active_language(); }); </script>  <button id="ot-sdk-btn" class="ot-sdk-show-settings">Param猫tres des cookies</button>    <a href="javascript:void(0)" class="scrollup"> </a>  <script type="text/javascript"> var _paq = _paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="https://analytics.afrinic.net/"; _paq.push(['setTrackerUrl', u+'piwik.php']); _paq.push(['setSiteId', '2']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s); })(); </script> <noscript><p><img src="https://analytics.afrinic.net/piwik.php?idsite=2&rec=1" style="border:0;" alt="" /></p></noscript>  <script data-cfasync="false" src="https://tdns2.gtranslate.net/tdn-bin/queue.js"></script></body></html>