Voir aussi:

Contents

Koumbit à l'Arin
Requesting IP allocation from ARIN
Changing reverse DNS authority
1. Verifying the delegation
Pricing
Requirements
Monitoring
Other procedures
1. Registering a PGP key
Migration vers les nouveaux netblocks 2012
IPv6

Koumbit à l'Arin

http://whois.arin.net/rest/org/RKN Koumbit
https://whois.arin.net/rest/poc/NOC11998-ARIN.html NOC
https://whois.arin.net/rest/poc/ABUSE3016-ARIN.html Abuse
https://whois.arin.net/rest/org/RKN/pocs Les contacts relié à Koumbit

Requesting IP allocation from ARIN

We are in the process of looking at resource allocations directly from ARIN. This is a complicated bureaucratic process that involve multiple steps. Bear with us.

Create a ARIN Online account

Those accounts are per person accounts, so no role emails like noc@ and so on here. I (anarcat) created myself an account to recover the RKN OrgID.

Create a POC

https://www.arin.net/resources/request/poc.html with all the details

In short,

Create an account on arin.net
Confirm your email
Ask to be link to "koumbit" https://www.arin.net/public/secure/poc/link.xhtml

See above Koumbit à l'Arin to see the account already linked to Koumbit

Create an OrgID

https://www.arin.net/resources/request/org.html

Example: http://whois.arin.net/rest/org/RKN

I have requested that RKN to be linked with my POC. See 79414

Request IP allocation

https://www.arin.net/resources/request/ipv4_initial_alloc.html https://www.arin.net/resources/request/ipv6_initial_alloc.html

apparently, the first IPv6 allocation is free, so we should probably just go ahead with that too while we're here.

See IPv6 for this too.

Note: there's already: http://whois.arin.net/rest/net/NET-209-44-112-0-1.html http://whois.arin.net/rest/rdns/112.44.209.in-addr.arpa.

Create an ASN

https://www.arin.net/resources/request/asn.html

Changing reverse DNS authority

The ARIN Online site is where you can change your reverse DNS authority ("glue") records. If your IP block was SWIP'd to you (reassigned), then you can make those changes in the "Manage resources" tab of the ARIN Online website.

Verifying the delegation

Lets answer the question? Which dns server has the authority to map the reverse name for an ip (PTR).

We use the nslookup command, then we ask the root dns server, about our ip 199.58.80.0, it's pointing us to another dns server which then ask, then another one... until the last delegation! yes, it's Koumbit!

$ nslookup
> server a.root-servers.net
Default server: a.root-servers.net
Address: 198.41.0.4#53
Default server: a.root-servers.net
Address: 2001:503:ba3e::2:30#53
> 199.58.80.0
Server:         a.root-servers.net
Address:        198.41.0.4#53

Non-authoritative answer:
*** Can't find 0.80.58.199.in-addr.arpa.: No answer

Authoritative answers can be found from:
in-addr.arpa    nameserver = a.in-addr-servers.arpa.
......

> server a.in-addr-servers.arpa.
Default server: a.in-addr-servers.arpa.
Address: 199.212.0.73#53
Default server: a.in-addr-servers.arpa.
Address: 2001:500:13::73#53
> 199.58.80.0
Server:         a.in-addr-servers.arpa.
Address:        199.212.0.73#53

Non-authoritative answer:
*** Can't find 0.80.58.199.in-addr.arpa.: No answer

Authoritative answers can be found from:
199.in-addr.arpa        nameserver = arin.authdns.ripe.net.
....
> server arin.authdns.ripe.net.
Default server: arin.authdns.ripe.net.
Address: 193.0.9.10#53
Default server: arin.authdns.ripe.net.
Address: 2001:67c:e0::10#53
> 199.58.80.0
Server:         arin.authdns.ripe.net.
Address:        193.0.9.10#53

Non-authoritative answer:
*** Can't find 0.80.58.199.in-addr.arpa.: No answer

Authoritative answers can be found from:
80.58.199.in-addr.arpa  nameserver = ns3.koumbit.net.
80.58.199.in-addr.arpa  nameserver = ns1.koumbit.net.
80.58.199.in-addr.arpa  nameserver = ns2.koumbit.net.

Pricing

ASN: 500$ initially, 100$/yr unless there is another allocation
IPv4 /21 (8 X /24): $1,250$/yr
IPv4 /20 or /29 (16 or 32 X /24): $2,500$/yr
IPv6 /41: $1,250/yr (free for first year, maybe completely free)

Requirements

Multihomed: An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs.
Minimal size: We are not currently multi-homed, according to that definition - which means we need to go for the minimal /20. source this isn't so clear this page says that a /22 is available to "organization [that] intend to multi-home using the requested block"
Utilisation deadline: resources need to be used within 90 days source

Monitoring

Comme c'est nos fournisseurs réseaux qui font l'annonce de nos ip, on veut faire la surveillance de l'annonce des ips sur le net. Bgpmon.net fait très bien l'affaire. Voici la configuration pour le moment.

Other procedures

Registering a PGP key

https://www.arin.net/CA/

We can use PGP to communicate with ARIN...

Migration vers les nouveaux netblocks 2012

Voir: AllocationIp/ReallocationPlan2012.

IPv6

See also IPv6 and AllocationIp#ARIN_IPv6.

Allocation size

Koumbit has received a netblock from ARIN (a /36). A /48 has 65,536 sub-networks of 18,446,744,073,709,551,616 IP addresses (/64). We are more likely to get a /32 however, which is 65,536 /48 networks, or a /36, which is only 256 /48 networks.

On doit fournir cette information:

In the next 1, 2, and 5 years, estimate how much space you plan to assign to customers? (e.g. how many /64s, /56s, /48s, and other prefix sizes you will be assigning?)

Comme Anarcat écrivait dans une LettreDuVendredi:

79228162514264337593543950336 (2⁹⁶ ou 7.9E28), le nombre d'IPs (IPv6) qu'on aurait en faisant une demande a l'ARIN. C'est l'équivalent d'avoir 4 billions (2^32) de réseaux de 4 billions de réseaux (oui, encore) de 4 billions d'IPs. Pour comparaison, il y a 4 billion d'IPs dans l'internet IPv4 actuel. Donc on aurait la capacité d'adresser 16 billions de billions d'internets, juste pour nous.

C'est immense.

Voir aussi:

According to our current IPv4 allocation, we could get, at no extra cost, a /36 allocation. This is what we've requested and received. See AllocationIp#ARIN_IPv6

General allocation plan

Addresses could be allocated in the following way:

-Assign an IPv6 address automatically (radvd) for the main IP of each machine. (This should work OK with the public/private vlan scheme, since the switch filters by port, not IP)-
One /64 block for HAG, but keep most users on the same IP, assign a new IP from that /64 for each SSL site. (this way they are all in the same block)
One /64 block per server / vserver. This way clients can allocate an IP per vhost, which is the recommended way. This requires modifying the routing tables, so more difficult to automate.

À noter aussi que dans la configuration ci-haut, une règle de routage est ajoutée pour chaque /64 assigné à un client ou une machine. Il serait peut-être possible d'éviter ce problème en ayant l'IP du routeur comme un /48 et assigner des /64 au client, mais mettre /48 comme netmask.

Autres politiques à respecter:

allocation end-user: /48, mais souvent on alloue un /56 (3177 was obsoleted by 6177)
different BGP announcements require a maximum prefix size of /48, /32 is more usual
allocate at least a /48 per datacenter (source)
sparse allocation: we allocate in the middle of the available netblock (source) - 3531 contradicts 5375 section 2.4, yay
put the VLAN id in the address? (rfc5375, section 2.4)
No subnets will use prefixes longer than /64.
interconnects: allocate a /64 use a /126 or /127 and read 3627
allocate on nibble boundaryes (4 bit, one hex digit)

RFCs galore

3531: "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block", 2003
5375: "IPv6 Addressing Considerations" - December 2008
v6ops: working document, 2013
3177: "IAB/IESG Recommendations on IPv6 Addresses" - September 2001 obsoleted by 6177
6177: "IPv6 Address Assignment to End Sites", March 2011
3849: "IPv6 Documentation Address" - July 2004
6883: "IPv6 Guidance for Internet Content Providers and Application Service Providers", March 2013
3627: "Use of /127 Prefix Length Between Routers Considered Harmful", September 2003

Autres références

Questions en suspend

sparse ou compact?
SLAAC? est-ce qu'on fait une allocation automatique puis on route le bloc d'IP vers le SLAAC?
/48, /56 ou /64 aux machines colo, VPS, VPN?
- bgm: /48 par machine physique, /64 pour un VPS.
/44 pour le core est enorme, on suggere /48 dans la docu que j'ai lu et meme ca est enorme
-est-ce qu'on va passer le test du "host density" avec un /36??-
- ARIN a alloué un /32
est-ce que c'est joli? il devrait être facile de déterminer à quel network / emplacement une IP appartient...

Plan proposé pour 2602:ff21::/32

Attention! Il y a une erreur dans ce plan d'allocation, parce que la délégation de ARIN est un /36, pas un /32!!

2602::ff21::/32

2602:ff21:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
          | |    |  |
          | |    |  --------┬---------╯
          | |    |          |
          | |    |       /64 par VM
          | |    |                    
          | |    ╰----------┬---------╯
          | |               |
          | |       /56 par serveur KVM
          | |           - incluant colo? peuvent être /64 (comme chez OVH)
          | |           - si dans un /40, 65k machines par service
          | |           - si dans un /48, 255 machines par service
          | |      (assume max 255 VMs par serveur)
          | |    (et si jamais tech change -> nouveau type de service ou </64 par VM)
          | |
          | |  Ex: 2602:ff21:5000:0100::/56 à 2602:ff21:5000:01ff::/56 = KVM 0
          | |      2602:ff21:5000:0200::/56 à 2602:ff21:5000:02ff::/56 = KVM 1
          | |      2602:ff21:5000:ff00::/56 à 2602:ff21:5000:ffff::/56 = KVM 0xFF
          | |      2602:ff21:50ff:ff00::/56 à 2602:ff21:5000:ffff::/56 = KVM 0xFFFF
          | |
          | ╰-------------------------╯
          |                 |
          |         /40 par type de service (0xff = 255 types de services)
          |
          |   Ex: 2602:ff21:5000::/40 à 2602:ff21:50ff::/40 = VPS service
          |       2602:ff21:5100::/40 à 2602:ff21:51ff::/40 = Colo service
          |       2602:ff21:5200::/40 à 2602:ff21:52ff::/40 = VPN service
          |       2602:ff21:5300::/40 à 2602:ff21:52ff::/40 = ...
          |       2602:ff21:ff00::/40 à 2602:ff21:ffff::/40 = Unicorn service
          |
          ╰---------------------------╯
                            |
                /36 par "point of presence" (POP), 16 POPs

              Ex: 2602:ff21:1000::/36 à 2602:ff21:1fff::/36 = POP 1
              Ex: 2602:ff21:2000::/36 à 2602:ff21:2fff::/36 = POP 2
              Ex: 2602:ff21:f000::/36 à 2602:ff21:ffff::/36 = POP 0xF

RFC 3849 (exemple)

Ceci n'est pas une allocation réelle! Le bloc 2001:0DB8::/32 est seulement un exemple, tiré du RFC 3849.

Nous avons maintenant une allocation IPv6 (voir AllocationIp#ARIN IPv6). Cette allocation est un exemple de comment les choses pourraient être séparées avec IPv6, en admettant qu'on a 2001:0DB8:a000::/36 (16 x /40):

2001:0DB8:a000::/40

pop0: tour - 16 x /44

2001:0DB8:A000::/44

core0

2001:0DB8:A000::/48

core0

2001:0DB8:A000::/64: core0 automatic allocation
2001:0DB8:A000::1/64: main core router

2001:0DB8:A001::/48

core0-resv1

2001:0DB8:A010::/44

pop0-resv1

2001:0DB8:A020::/44

pop0-resv2

2001:0DB8:A030::/44

pop0-resv3

2001:0DB8:A040::/44

VPS, colos et dédi (16k x /56)

2001:0DB8:A040::/48

colo0 (256 x /56)

2001:0DB8:A040:00::/56

colo0-main0

2001:0DB8:A040::/64: colo0-main0
2001:0DB8:A040::1/64: colo0-main0 colo gateway
2001:0DB8:A040:1::/64: reserved?

2001:0DB8:A040:100::/56

reserved...

[...]

...

2001:0DB8:A040:1000::/56

colo client 1 (start allocating in the middle)

2001:0DB8:A040:1001::/56

colo client 2

[...]

+ 253 /56 colo clients

2001:0DB8:A040:FFFF::/56

colo client FFFF

2001:0DB8:A041::/48

colo0-resv0

2001:0DB8:A042::/48

colo0-resv1

[...]

+ 5 /48 colo0-resvN

2001:0DB8:A048::/48

vps0 (256 x /56)

2001:0DB8:A049::/48

vps0-resv9

2001:0DB8:A04A::/48

vps0-resvA

[...]

+ 5 /48 vps0-resvN

2001:0DB8:A04F::/48

vps0-resvF

2001:0DB8:A050::/44

pop0-resv5

2001:0DB8:A060::/44

pop0-resv6

2001:0DB8:A070::/44

pop0-resv7

2001:0DB8:A080::/44

shared0

2001:0DB8:A080::/48: Koumbit main colo netel shared hosting (aegir) vlan
2001:0DB8:A081::/48: Koumbit main colo netel shared hosting (alternc) vlan

2001:0DB8:A090::/44

pop0-resv9

2001:0DB8:A0A0::/44

pop0-resvA

2001:0DB8:A0B0::/44

pop0-resvB

2001:0DB8:A0C0::/44

pop0-resvC

2001:0DB8:A0D0::/44

pop0-resvD

2001:0DB8:A0E0::/44

pop0-resvE

2001:0DB8:A0F0::/44

pop0-resvF

2001:0DB8:a100::/40

pop1-resv

2001:0DB8:a200::/40

pop2-resv

2001:0DB8:a300::/40

pop3-resv

2001:0DB8:a400::/40

pop4: vpns (16 x /44, each into a /56 per client, so 65k clients)

2001:0DB8:a400::/44

vpn0 (4096 x /56)

2001:0DB8:a400::/56: client A

2001:0DB8:a410::/44

vpn1-resv

[...]

+14 /44 libres pour les VPNs

2001:0DB8:a800::/40

pop8 (office)

2001:0DB8:a800::/44: office0-dmz
2001:0DB8:a810::/44: office1-priv
[...]: +13 /44 libres

2001:0DB8:a900::/40

pop9-resv

2001:0DB8:aa00::/40

popA-resv

2001:0DB8:ab00::/40

popB-resv

2001:0DB8:ac00::/40

popC: accès commuté (théorique)

2001:0DB8:ad00::/40

popD-resv

2001:0DB8:ae00::/40

popE-resv

2001:0DB8:af00::/40

popF-resv

Plan proposé pour 2602:ff21::/36

Réviser ce plan et le comparer avec les deux plans ci-haut pour déterminer le bon à prendre. Correspond plus ou moins au plan RFC 3849 ci-haut, mais en forme graphique et avec des exemples et modifications.

Ci-bas, on alloue des IPs automatiquement en SLAAC dans le premier /64 des /44 pour pas avoir à gosser avec le routage ou le DHCP pour avoir du réseau. Ensuite, si les machines veulent router plus d'IPs que leur SLAAC, on leur route un /56 statiquement ou en DHCPv6.

Par exemple, dans pop0-colo0 (2602:ff21:40::/44) on alloue le premier /64 (2602:ff21:40::/64) au SLAAC, et donc les machines là on une IP du style:

2602:ff21:40::xxxx:xxxx:xxxx:xxxx/64

Ensuite, on peut déléguer un /56 ou un /64 en dessous, si nécessaire (ou automatiquement). Typiquement, on voudrait probablement l'allouer automatiquement pour des machines qu'on *sait* qu'elles auront besoin de plus d'IPs (e.g. les machines à VM, quoique là on délèguerait à Ganeti).

Voici un exemple de plan d'allocation du 2602::ff21::/36, tel qu'imaginé par TheAnarcat un samedi après-midi en révisant le plan d'allocation RFC-3849 fait ci-haut par lui-même et le plan graphique fait par MathieuLutfy un peu plus tard:

2602:ff21:0xxx:xxxx:xxxx:xxxx:xxxx:xxxx
           |||   |  |
           |||   |  --------┬---------╯
           |||   |          |
           |||   |       /64 par VM
           |||   |                    
           |||   ╰----------┬---------╯
           |||              |
           |||      /56 par serveur KVM
           |||          - incluant colo? peuvent être /64?
           |||          - si dans un /40, 65k machines par service
           |||          - si dans un /44, 14k machines par service
           |||          - si dans un /48, 255 machines par service
           |||     (assume max 255 VMs par serveur)
           |||   (et si jamais tech change -> nouveau type de service ou </64 par VM)
           |||
           |||   Ex: 2602:ff21:100:0100::/56 à 2602:ff21:100:01ff::/56 = KVM 0 in office
           |||       2602:ff21:100:0200::/56 à 2602:ff21:100:02ff::/56 = KVM 1 in office
           |||       2602:ff21:100:ff00::/56 à 2602:ff21:100:ffff::/56 = KVM 0xFF
           |||       2602:ff21:100:ff00::/56 à 2602:ff21:100:ffff::/56 = KVM 0xFFFF
           |||
           |||
           |||   Ex: 2602:ff21:40::/64 à 2602:ff21:40::ffff:ffff:ffff:ffff/64 = pop0-colo0-slaac
           |||   Ex: 2602:ff21:40:100::/56 à 2602:ff21:40:1ff::/56 = pop0-colo0-client0-deleg0
           |||
           |||   ie. un /56 routé vers le /64 autonmatiquement alloué à la colo, sur demande ou automatiquement avec DHCPv6
           ||╰------------------------╯
           ||              |
           ||       /44 par "service" (0xf = 16 services)
           ||
           || Ex: 2602:ff21::/44 à 2602:ff21:f::/44 = pop0-core0
           ||     2602:ff21:10::/44 à 2602:ff21:1f::/44 = pop0-resv1
           ||     2602:ff21:20::/44 à 2602:ff21:2f::/44 = pop0-resv2...
           ||     ...
           ||     2602:ff21:40::/44 à 2602:ff21:4f::/44 = pop0-colo0
           ||     ...
           ||     2602:ff21:80::/44 à 2602:ff21:8f::/44 = pop0-shared0
           ||     ...
           ||     2602:ff21:a0::/44 à 2602:ff21:af::/44 = pop0-vps0...
           ||     ...
           ||     2602:ff21:f0::/44 à 2602:ff21:ff::/44 = pop0-resvF...
           ||
           |╰-------------------------╯
           |            |
           |        /40 par "point of presence" (PoP) (0xf = 16 PoP)
           |
           |  Ex: 2602:ff21::/40 à 2602:ff21:ff::/40 = pop0: tour = 16 x /44
           |      2602:ff21:100::/40 à 2602:ff21:1ff::/40 = pop1: office
           |      2602:ff21:200::/40 à 2602:ff21:2ff::/40 = pop2: resv
           |      2602:ff21:300::/40 à 2602:ff21:3ff::/40 = pop3: e.g. anycast
           |      2602:ff21:f00::/40 à 2602:ff21:fff::/40 = popf: resv
           |
           ╰--------------------------╯
                      |
                2602::ff21:/36

CategoryConfiguration

Wiki

Page

User

Koumbit à l'Arin

Requesting IP allocation from ARIN

Create a ARIN Online account

Create a POC

Create an OrgID

Request IP allocation

Create an ASN

Changing reverse DNS authority

Verifying the delegation

Pricing

Requirements

Monitoring

Other procedures

Registering a PGP key

Migration vers les nouveaux netblocks 2012

IPv6

Allocation size

General allocation plan

RFCs galore

Autres références

Questions en suspend

Plan proposé pour 2602:ff21::/32

RFC 3849 (exemple)

Plan proposé pour 2602:ff21::/36