gul_tech: (Default)
[personal profile] gul_tech
В свете нашумевшего исчерпания IP-адресов составил список - кто является обладателем блоков /8, и используют ли они их. Оказалось, что неиспользуемых довольно много. Хотя и непонятно, можно ли их законно отобрать и дать кому-то другому (RIR-ам).
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.

IPUsageOwner
3.0.0.0/8usedGeneral Electric Company
4.0.0.0/8usedLevel 3 Communications, Inc.
6.0.0.0/8usedArmy Information Systems Center
8.0.0.0/8usedLevel 3 Communications, Inc.
9.0.0.0/8unusedIBM
11.0.0.0/8<1%DoD Intel Information Systems
12.0.0.0/8usedAT&T Bell Laboratories
13.0.0.0/8usedXerox Corporation
15.0.0.0/8usedHewlett-Packard Company
16.0.0.0/8usedDigital Equipment Corporation
17.0.0.0/8usedApple Computer Inc.
18.0.0.0/8usedMIT
19.0.0.0/8unusedFord Motor Company
20.0.0.0/8usedComputer Sciences Corporation
21.0.0.0/8<1%DDN-RVN
22.0.0.0/8unusedDefense Information Systems Agency
25.0.0.0/8unusedUK Ministry of Defence
26.0.0.0/8unusedDefense Information Systems Agency
28.0.0.0/8unusedDSI-North
29.0.0.0/8unusedDefense Information Systems Agency
30.0.0.0/8unusedDefense Information Systems Agency
32.0.0.0/8usedAT&T Global Network Services
33.0.0.0/8usedDLA Systems Automation Center
34.0.0.0/8<1%Halliburton Company
35.0.0.0/8usedMERIT Computer Network
38.0.0.0/8usedPSINet, Inc.
40.0.0.0/8usedEli Lily & Company
44.0.0.0/8usedAmateur Radio Digital Communications
47.0.0.0/8usedBell-Northern Research
48.0.0.0/8unusedPrudential Securities Inc.
51.0.0.0/8unusedUK Government Department for Work and Pensions
52.0.0.0/8<1%E.I. duPont de Nemours and Co., Inc.
53.0.0.0/8usedCap Debis CCS
54.0.0.0/8unusedMerck and Co., Inc.
55.0.0.0/8usedDoD Network Information Center
56.0.0.0/8<1%US Postal Service
57.0.0.0/8usedSITA
214.0.0.0/8usedUS-DOD
215.0.0.0/8usedUS-DOD

Date: 2011-02-06 09:21 am (UTC)
From: [identity profile] lesnix.livejournal.com
> Откуда может взяться v6-only часть Интернета? Кто будет делать v6-only ресурсы, недоступные для v4-only пользователей?
Их будут делать контент-провайдеры, которым не достанется нужного количества адресов IPv4.

На самом деле, на ситуация надо смотреть немного с другой стороны. Логика примерно такая:
1. IPv4 - "изя всё". В этой ситуации больше всего страдают крупные потребители адресов, коими являются провайдеры.
2. Раз адресов нет, провайдер будет выдавать пользователям приватные v4 и использовать NAT44 (на первых порах это абсолютно обязательно) и, если провайдер не дурак, то еще и IPv6, т.к. наличие возрастающей со временем доли (нетранслируемого) v6-трафика скомпенсирует рост затрат на трансляторы.
Таким образом, на первых порах у всех новоподключенных пользователей будет dulstack в том или ином виде.
3. Однако, на первых порах подавляющее большинство трафика будет именно IPv4. И весь этот трафик будет ходить через трансляторы. Это, конечно же, будет вызывать постоянные проблемы у пользователей (вспомним все недостатки NAT'а), а самое главное - временами это будет упираться в очередную "полку" очередного транслятора.
4. Контент-провайдеры увидят, что пользователи, приходящие на их ресурс из-за провайдерских NATов, испытывают проблемы. Очевидно, что наиболее простым решением в этом случае будет обеспечить доступ к своему контенту через IPv6. Потому, что при маршрутизации IPv6-трафика не будет такого узкого места, как "транслятор".
5. За счет роста количества контента, доступного по IPv6, будет расти доля нативного IPv6-трафика. Это будет снижать расходы на трансляторы и, через время (не спрашивайте какое, я не знаю) вовсе уберет в них необходимость.

Такое вот будущее представляется ;)

Date: 2011-02-06 09:53 am (UTC)
From: [identity profile] gul-kiev.livejournal.com
На такую схему у меня есть два возражения.

1. Имеющегося адресного пространства IPv4 полностью достаточно для всех пользователей Интернета без всяких натов. Проблема не в исчерпании IPv4, а в неравномерном его распределении. Провайдерам, у которых есть крупные блоки IP (первое, что видно: Cogent - /8, Level3 - два по /8), совершенно незачем давать пользователям IPv6 или использовать NAT44. Соответственно, они получают конкурентное преимущество и расширяют свою сферу влияния. Происходит обратный процесс: не адреса распределяются в соответствии с потребностями, а влияние владельцев IP-адресов распределяется в соответствии с потребностями в этих адресах. Что я считаю совершенно неправильным, т.к. те, кто захватил себе IP-адресов больше, чем реально нужно - это "плохие парни", но именно сейчас они получают преимущество.

2. Я в этой схеме не вижу момента, когда появятся v6-only сетевые ресурсы. А без этого нельзя говорить о переходе с IPv4 на IPv6 и о том, что IPv6 решает проблемы дефицита IPv4-адресов.

Date: 2011-02-06 10:13 am (UTC)
From: [identity profile] lesnix.livejournal.com
Касаемо возражения 1):
Даже если согласиться с тем, что имеющегося адресного пространства IPv4 достаточно для всех пользователей Интернета и проблема только в неравномерном его распределении, то... Вы же понимаете, что рост числа пользователей Интернета не прекращается ни на секунду. Чего стоят одни только мобильщики. В общем, даже если более "честно" (хотя кто и почему это будет решать - как именно более честно) распределить адреса - то это будет всего-лишь очередной отсрочкой.

Касаемо возражения 2):
Я просто не стал дописывать пункт о "светлом будущем". Вот он, в дополнение к тому, что я уже написал:
6. В какой-то момент контент-провайдеры поймут, что прибыль, получаемая за счет тех пользователей, которые все еще ходят к ним (контент-провайдерам) по IPv4, несравнима с затратами, которые необходимы для поддержки v4-контента. Это и станет моментом, когда контент-провайдеры начнут постепенно отключать v4 на своих ресурсах.

Date: 2011-02-06 11:09 am (UTC)
From: [identity profile] gul-kiev.livejournal.com
1)
Я не говорю, что IPv4 при "правильном" распределении хватит всем и навсегда. Я говорю о том, что из-за неравномерного распределения приведённая схема перехода на IPv6 через предварительный всеобщий NAT44 не будет работать, т.к. всегда будут провайдеры с избытком IPv4-адресов, которым не будет необходимости делать NAT44 и давать пользователям IPv6. Не может быть у всех недостатка, т.к. общее кол-во IP-адресов больше общего кол-ва пользователей. Если у кого-то будет недостаток, значит, у кого-то будет и избыток.

2)
Из-за п.1 число пользователей с IPv4 (и, соответственно, прибыль от них) ещё очень долго будет слишком значительной для того, чтобы сетевые ресурсы могли отказаться от IPv4.

Date: 2011-02-06 11:19 am (UTC)
From: [identity profile] lesnix.livejournal.com
1) Про "избыток" - прочитайте мой следующий коммент - http://gul-tech.livejournal.com/9151.html?thread=93119#t93119
Мы не можем говорить об избытке, не зная, какую именно систему адресации используют Level3 внутри своего жирного блока.

Date: 2011-02-06 11:27 am (UTC)
From: [identity profile] gul-kiev.livejournal.com
Неравномерное распределение адресов между провайдерами или неравномерное распределение своего блока IP внутри одного провайдера - разница лишь в том, что провайдеру внутри себя проще сделать renumbering и оптимизировать распределение адресов.

Конечно, если подходить с позиции "на эту локалку исторически выделено /9, хотя там всего два десятка машин, но изменять адресацию не представляется возможным" - тогда да, адресов реально не хватает. :)

Date: 2011-02-06 11:36 am (UTC)
From: [identity profile] lesnix.livejournal.com
Провайдеру внутри себя проще сделать renumbering ? "проще"?
Я уже представляю, как какой-нибудь огромный тирванище из альтруистических соображений возьмет да и поменяет ВСЮ свою систему адресации внутри своих сетей. Прямо вот так, в работающей сети. По ночам. На лету. Ага. Щаззз (С)

Нет, вы таки читните этот 4692. Причем не ради того, чему он посвящён - не ради плясок вокруг HD and so on. А просто ради того, чтобы увидеть некоторое summary по свойствам иерархических систем адресации.

В общем, основная мысль такова - тотальный renumbering в больших сетях сложен настолько, что почти можно сказать "неосуществим". Чтобы удостовериться - можно спросить у тирванов, например :)

Date: 2011-02-06 10:29 am (UTC)
From: [identity profile] lesnix.livejournal.com
И еще.
Говоря об обладателях /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 неидеален, но выбора у нас нет.

Date: 2011-02-06 11:18 am (UTC)
From: [identity profile] gul-kiev.livejournal.com
> Короче, всё сложно, сдавайтесь. v6 неидеален, но выбора у нас нет.

Считаю, что переход на IPv9 с 64-битными адресами, для которых IPv4 будут являться подмножеством, является решением этой проблемы, и оно должно быть применено несмотря на уже имеющуюся поддержку IPv6. Т.к. именно оно обеспечит решение всех обсуждающихся здесь проблем.

Важно, что не нужно иметь два разных адреса, две разных таблицы роутинга, две разных BGP-сессии и т.д. Предыдущая версия софта умеет роутить только 32-битные пакеты, проапдейтились - роутятся уже 64-битные. Софт понимает только IPv4, перекомпилили (возможно, с минимальными правками) - уже поддерживает IPv9.
За пару лет нетрудно перейти (при поддержке вендоров) и забыть про все проблемы с нехваткой адресного пространства.

Date: 2011-02-06 11:27 am (UTC)
From: [identity profile] lesnix.livejournal.com
Да нет же, блин, не всё так просто :)
Ну ведь [livejournal.com profile] dbg и правда все объяснил в соседнем посте. Формат заголовка разный? Разный. Ну вот и приехали - нет совместимости. Тот же v6.

Кроме того, почему тогда ничего не меняет наличие т.н. IPv4-Compatible IPv6-адресов (RFC 4291, пункт 2.5.5.1) ? Адреса IPv4 - вполне себе подмножество IPv6. В чем разница ? :)

Паша, если про IPng - вы всерьез, то напишите драфт про этот свой новый IP. Я думаю, когда вы более детально все это продумаете - станет ясно, что это ничего в корне не меняет. Нет в вашем IPng обратной совместимости.
Edited Date: 2011-02-06 11:27 am (UTC)

Date: 2011-02-06 11:42 am (UTC)
From: [identity profile] gul-kiev.livejournal.com
В соседнем посте мы поговорили (http://gul-tech.livejournal.com/8891.html?thread=80059#t80059) c dbg, и у меня не сложилось впечатление, что он указал на какие-то неразрешимые противоречия. Может, вы читали не всю ветку?

Формат пакетов разный. Если оба адреса 32-битные, используется старый формат, если хотя бы один 64-битный - новый. Обратная совместимость есть.
"Тот же v6" - вот же и говорю, что это совсем не тот же v6, потому что нет необходимости выдавать другие ip-адреса пользователям, получать другие блоки у rir, иметь две таблицы роутинга, по паре bgp-сессий на каждого нейбора... Если ресурс получил 64-битный адрес, его видимость или невидимость зависит не от провайдера, а от пользователя. На старой системе сайт не виден, надо проапдейтится. К такому пользователи привыкли и относятся с пониманием. Провайдеры не смогут не поддерживать IPng, как не смогут не поддерживать asn32, потому что они так или иначе апдейтят и железо, и софт (а вот не поддерживать IPv6 могут вполне, даже если их софт и железо его поддерживает).
На первом этапе, если у провайдера старое железо или софт, он не заявляет о готовности роутить IPng, и эти пакеты ходят в обход такого провайдера (просто эти BGP-анонсы через него не проходят).

> Паша, если про IPng - вы всерьез, то напишите драфт про этот свой новый IP

Подумаю в эту сторону... Только боюсь, что если этим заниматься всерьёз, нужно плотно общаться с вендорами, с IANA...

Profile

gul_tech: (Default)
gul_tech

December 2020

S M T W T F S
  12345
6789101112
13141516171819
202122 23242526
2728293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Mar. 16th, 2026 09:18 am
Powered by Dreamwidth Studios