IP - кого надо раскулачить
Feb. 5th, 2011 11:00 amВ свете нашумевшего исчерпания IP-адресов составил список - кто является обладателем блоков /8, и используют ли они их. Оказалось, что неиспользуемых довольно много. Хотя и непонятно, можно ли их законно отобрать и дать кому-то другому (RIR-ам).
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.
| IP | Usage | Owner |
| 3.0.0.0/8 | used | General Electric Company |
| 4.0.0.0/8 | used | Level 3 Communications, Inc. |
| 6.0.0.0/8 | used | Army Information Systems Center |
| 8.0.0.0/8 | used | Level 3 Communications, Inc. |
| 9.0.0.0/8 | unused | IBM |
| 11.0.0.0/8 | <1% | DoD Intel Information Systems |
| 12.0.0.0/8 | used | AT&T Bell Laboratories |
| 13.0.0.0/8 | used | Xerox Corporation |
| 15.0.0.0/8 | used | Hewlett-Packard Company |
| 16.0.0.0/8 | used | Digital Equipment Corporation |
| 17.0.0.0/8 | used | Apple Computer Inc. |
| 18.0.0.0/8 | used | MIT |
| 19.0.0.0/8 | unused | Ford Motor Company |
| 20.0.0.0/8 | used | Computer Sciences Corporation |
| 21.0.0.0/8 | <1% | DDN-RVN |
| 22.0.0.0/8 | unused | Defense Information Systems Agency |
| 25.0.0.0/8 | unused | UK Ministry of Defence |
| 26.0.0.0/8 | unused | Defense Information Systems Agency |
| 28.0.0.0/8 | unused | DSI-North |
| 29.0.0.0/8 | unused | Defense Information Systems Agency |
| 30.0.0.0/8 | unused | Defense Information Systems Agency |
| 32.0.0.0/8 | used | AT&T Global Network Services |
| 33.0.0.0/8 | used | DLA Systems Automation Center |
| 34.0.0.0/8 | <1% | Halliburton Company |
| 35.0.0.0/8 | used | MERIT Computer Network |
| 38.0.0.0/8 | used | PSINet, Inc. |
| 40.0.0.0/8 | used | Eli Lily & Company |
| 44.0.0.0/8 | used | Amateur Radio Digital Communications |
| 47.0.0.0/8 | used | Bell-Northern Research |
| 48.0.0.0/8 | unused | Prudential Securities Inc. |
| 51.0.0.0/8 | unused | UK Government Department for Work and Pensions |
| 52.0.0.0/8 | <1% | E.I. duPont de Nemours and Co., Inc. |
| 53.0.0.0/8 | used | Cap Debis CCS |
| 54.0.0.0/8 | unused | Merck and Co., Inc. |
| 55.0.0.0/8 | used | DoD Network Information Center |
| 56.0.0.0/8 | <1% | US Postal Service |
| 57.0.0.0/8 | used | SITA |
| 214.0.0.0/8 | used | US-DOD |
| 215.0.0.0/8 | used | US-DOD |
no subject
Date: 2011-02-06 10:29 am (UTC)Говоря об обладателях /8 и /9, Вы, кажется, не учитываете одно из свойств иерархических систем IP-адресации: в иерархической системе адресации фактическое исчерпание адресов наступает не в тот момент, когда исчерпаны все адресные блоки, а в тот момент, когда исчерпаны адресные блоки хотя бы на одном из уровней.
В оригинале (RFC 4692) это звучит так:
"Within a typical network address plan, the network's address space is exhausted not when all address resources have been used, but at the point when one element within the structure has exhausted its pool, and when augmentation of this pool by drawing from the pools of other elements would entail extensive renumbering."
Иными словами, если используемая Level3 система адресации неэффективна, фактический коллапс такой системы может наступить сильно раньше, чем арифметическое исчерпание адресов. А неэффективной система может быть не только по глупости, но и по другим причинам - возможно, что на тот момент другие факторы, влияющие на выбор системы адресации, оказались для того же Level3 более важными, чем соображения эффективности адресации. Because of money, например.
Короче, всё сложно, сдавайтесь. v6 неидеален, но выбора у нас нет.
no subject
Date: 2011-02-06 11:18 am (UTC)Считаю, что переход на IPv9 с 64-битными адресами, для которых IPv4 будут являться подмножеством, является решением этой проблемы, и оно должно быть применено несмотря на уже имеющуюся поддержку IPv6. Т.к. именно оно обеспечит решение всех обсуждающихся здесь проблем.
Важно, что не нужно иметь два разных адреса, две разных таблицы роутинга, две разных BGP-сессии и т.д. Предыдущая версия софта умеет роутить только 32-битные пакеты, проапдейтились - роутятся уже 64-битные. Софт понимает только IPv4, перекомпилили (возможно, с минимальными правками) - уже поддерживает IPv9.
За пару лет нетрудно перейти (при поддержке вендоров) и забыть про все проблемы с нехваткой адресного пространства.
no subject
Date: 2011-02-06 11:27 am (UTC)Ну ведь
Кроме того, почему тогда ничего не меняет наличие т.н. IPv4-Compatible IPv6-адресов (RFC 4291, пункт 2.5.5.1) ? Адреса IPv4 - вполне себе подмножество IPv6. В чем разница ? :)
Паша, если про IPng - вы всерьез, то напишите драфт про этот свой новый IP. Я думаю, когда вы более детально все это продумаете - станет ясно, что это ничего в корне не меняет. Нет в вашем IPng обратной совместимости.
no subject
Date: 2011-02-06 11:42 am (UTC)Формат пакетов разный. Если оба адреса 32-битные, используется старый формат, если хотя бы один 64-битный - новый. Обратная совместимость есть.
"Тот же v6" - вот же и говорю, что это совсем не тот же v6, потому что нет необходимости выдавать другие ip-адреса пользователям, получать другие блоки у rir, иметь две таблицы роутинга, по паре bgp-сессий на каждого нейбора... Если ресурс получил 64-битный адрес, его видимость или невидимость зависит не от провайдера, а от пользователя. На старой системе сайт не виден, надо проапдейтится. К такому пользователи привыкли и относятся с пониманием. Провайдеры не смогут не поддерживать IPng, как не смогут не поддерживать asn32, потому что они так или иначе апдейтят и железо, и софт (а вот не поддерживать IPv6 могут вполне, даже если их софт и железо его поддерживает).
На первом этапе, если у провайдера старое железо или софт, он не заявляет о готовности роутить IPng, и эти пакеты ходят в обход такого провайдера (просто эти BGP-анонсы через него не проходят).
> Паша, если про IPng - вы всерьез, то напишите драфт про этот свой новый IP
Подумаю в эту сторону... Только боюсь, что если этим заниматься всерьёз, нужно плотно общаться с вендорами, с IANA...