КОМПЬЮТЕРНЫЕ СЕТИ

1. Александр Масальскихrusalmas@gmail.com КОМПЬЮТЕРНЫЕ СЕТИ Лекция №15 IPv6. Глобальные сети. Интернет. DNS. WWW Санкт-Петербург, 2012

2. Network Address Translation • 31 января 2011 года последние два незарезервированные IANA блока адресов были выделены APNIC в соответствии со стандартными процедурами выделения адресов региональным интернет-регистраторам. Осталось пять зарезервированных и потому нераспределённых блоков. В соответствии с правилами ICANN, IANA приступила к распределению каждого из этих блоков каждому из региональных интернет-регистраторов после пресс-конференции 3 февраля 2011 года, что привело к окончанию запаса адресов IANA. • Различные самостоятельные адресные блоки, исторически используемые отдельно от региональных интернет-регистраторов, были распределены региональным интернет-регистраторам в феврале 2011 года. • APNIC является первым региональным интернет-регистратором, который прекратил свободно выделять IPv4 адреса. Это произошло 15 апреля 2011 года. С этой даты начался период, когда уже не каждый локальный интернет-регистратор (LIR) может получить IPv4-адреса в нужном ему количестве. Как следствие этого истощения, требуемые многими приложениями соединения точка-точка не будут всегда доступны в IPv4-Интернете до тех пор, как IPv6 будет полностью внедрён.

3. Network Address Translation

4. Network Address Translation • Региональный интернет-регистратор(англ. RegionalInternetRegistry) — организация, занимающаяся вопросами адресации и маршрутизации в сети Интернет.

5. Network Address Translation • NAT (Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адресатранзитныхпакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation.

6. Network Address Translation • Существует 3 базовых концепции трансляции адресов: • статическая (StaticNetworkAddressTranslation), • динамическая (DynamicAddressTranslation), • маскарадная (NAPT, NAT Overload, PAT).

7. Network Address Translation • Статический NAT — Отображение незарегистрированного IP-адреса на зарегистрированный IP-адрес на основании один к одному. Особенно полезно, когда устройство должно быть доступным снаружи сети. • Динамический NAT — Отображает незарегистрированный IP-адрес на зарегистрированный адрес от группы зарегистрированных IP-адресов. Динамический NAT также устанавливает непосредственное отображение между незарегистрированным и зарегистрированным адресом, но отображение может меняться в зависимости от зарегистрированного адреса, доступного в пуле адресов, во время коммуникации. • Перегруженный NAT (NAPT, NAT Overload, PAT, маскарадинг) — форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. Известен также как PAT (PortAddressTranslation). При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта. • Механизм NAT определён в RFC 1631, RFC 3022.

8. Network Address Translation

9. Network Address Translation • Позволяет сэкономить IP-адреса (только в случае использования NAT в режиме PAT) • Позволяет предотвратить или ограничить обращение снаружи ко внутренним хостам, оставляя возможность обращения изнутри наружу. При инициации соединения изнутри сети создаётся трансляция. Ответные пакеты, поступающие снаружи, соответствуют созданной трансляции и поэтому пропускаются. Если для пакетов, поступающих снаружи, соответствующей трансляции не существует (а она может быть созданной при инициации соединения или статической), они не пропускаются. • Позволяет скрыть определённые внутренние сервисы внутренних хостов/серверов. По сути, выполняется та же указанная выше трансляция на определённый порт, но возможно подменить внутренний порт официально зарегистрированной службы (например, 80-й порт TCP (HTTP-сервер) на внешний 54055-й). Повышение безопасности и скрытие «непубличных» ресурсов.

10. Network Address Translation • Не все протоколы могут «преодолеть» NAT. Некоторые не в состоянии работать, если на пути между взаимодействующими хостами есть трансляция адресов. Некоторые межсетевые экраны, осуществляющие трансляцию IP-адресов, могут исправить этот недостаток, соответствующим образом заменяя IP-адреса не только в заголовках IP, но и на более высоких уровнях (например, в командах протокола FTP). Application-levelgateway. • Из-за трансляции адресов «много в один» появляются дополнительные сложности с идентификацией пользователей и необходимость хранить полные логи трансляций. • DoS со стороны узла, осуществляющего NAT — если NAT используется для подключения многих пользователей к одному и тому же сервису, это может вызвать иллюзию DoS-атаки на сервис (множество успешных и неуспешных попыток). Частичным решением проблемы является использование пула адресов (группы адресов), для которых осуществляется трансляция. • В некоторых случаях, необходимость в дополнительной настройке при работе с пиринговыми сетями и некоторыми другими программами, в которых необходимо не только инициировать исходящие соединения, но также принимать входящие.

11. Internet Protocol version 6 • Основные цели: • Поддержка миллиардов хостов • Уменьшение размера таблиц маршрутизации • Ускорение обработки пакетов маршрутизаторами за счёт упрощения протокола • Более продуманная система обеспечения безопасности • Необходимость учитывать тип сервиса • Упрощение работы многоадресных рассылок с помощью указания областей рассылки • Мобильность хостов • Задел на развитие протокола • Возможность сосуществования с IPv4

12. Internet Protocol version 6 • Существуют различные типы адресов IPv6: • одноадресные (Unicast), • групповые (Anycast) • многоадресные (Multicast). • Адреса типа Unicast хорошо всем известны. Пакет, посланный на такой адрес, достигает в точности интерфейса, который этому адресу соответствует. • Адреса типа Anycast синтаксически неотличимы от адресов Unicast, но они адресуют группу интерфейсов. Пакет, направленный такому адресу, попадёт в ближайший (согласно метрике маршрутизатора) интерфейс. Адреса Anycast могут использоваться только маршрутизаторами.

13. Internet Protocol version 6 • Адреса типа Multicast идентифицируют группу интерфейсов. Пакет, посланный на такой адрес, достигнет всех интерфейсов, привязанных к группе многоадресного вещания. • Широковещательные адреса IPv4 (обычно xxx.xxx.xxx.255) выражаются адресами многоадресного вещания IPv6. • Адреса разделяются двоеточиями (напр. fe80:0:0:0:200:f8ff:fe21:67cf). Большое количество нулевых групп может быть пропущено с помощью двойного двоеточия (fe80::200:f8ff:fe21:67cf). Такой пропуск должен быть единственным в адресе.

14. Internet Protocol version 6 • Фиксированный заголовок IPv6-пакета состоит из 40 октетов (320 бит) и имеет следующий формат:

15. Internet Protocol version 6 • Version: версия протокола; для IPv6 это значение равно 6 (значение в битах — 0110). • TrafficClass: приоритет пакета (8 бит). Это поле состоит из двух значений. Старшие 6 бит используются DSCP для классификации пакетов. Оставшиеся два бита используются ECN для контроля перегрузки. • FlowLabel: метка потока. • PayloadLength: в отличие от поля TotalLength в протоколе IPv4 данное поле не включает фиксированный заголовок пакета (16 бит).

16. Internet Protocol version 6 • NextHeader: задаёт тип расширенного заголовка (англ. IPv6 extension), который идёт следующим. В последнем расширенном заголовке поле NextHeader задаёт тип транспортного протокола (TCP, UDP и т. д.) • HopLimit: аналог поля timetolive в IPv4 (8 бит). • SourceAddress и DestinationAddress: адрес отправителя и получателя соответственно; по 128 бит. • С целью повышения производительности и с расчётом на то, что современные технологии канального уровня обеспечивают достаточный уровень обнаружения ошибок, заголовок не имеет контрольной суммы.

17. Internet Protocol version 6 • Расширенные заголовки содержат дополнительную информацию и размещены между фиксированным заголовком и заголовком протокола более высокого уровня. Тип первого расширенного заголовка указывается в поле NextHeaderфиксированного заголовка, а каждый расширенный заголовок имеет аналогичное поле в котором хранится тип следующего расширенного заголовка. В поле NextHeader последнего заголовка находится тип протокола более высокого уровня, находящегося в качестве полезных данных. • Каждый расширенный заголовок должен иметь размер в октетах, кратный 8. Некоторые заголовки необходимо расширить до нужного размера.

18. Internet Protocol version 6

19. Internet Protocol version 6 • Обычная длина полезных данных: Поле фиксированного заголовка PayloadLength имеет размер 16 бит, поэтому максимально возможный размер полезных данных и расширенных заголовков равен 65535 октетам. Максимальный размер фрейма многих протоколов канального уровня гораздо меньше. • Джамбограммы IPv6-пакет может нести больше данных с помощью опции jumbopayload в расширенном заголовке Hop-By-HopOptions. Эта опция позволяет обмениваться пакетами с размером полезных данных на 1 байт меньшим чем 4Гбайт (232 − 1 = 4294967295 байт). Пакет с таким содержимым называют джамбограммой. • Так как протоколы TCP и UDP оба имееют поля длины, ограниченные 16 битами, для поддержки джамбограмм требуется реализация модифицированных протоколов транспортного уровня. Джамбограммы могут работать только на подключениях с MTU, большим чем 65583 октетов (более 65 535 октетов для полезных данных, 40 октетов для фиксированного заголовка и 8 октетов для расширенного заголовка Hop-By-HopOptions).

20. Internet Protocol version 6 • Фрагментация: IPv6-пакеты никогда не фрагментируются маршрутизаторами. Пакеты, чей размер превышает MTU сетевого подключения уничтожаются и отправителю посылается сообщение PackettooBig (ICMPv6 тип 2). Подобное поведение в IPv4происходит если установлен бит Don’tFragment. • Ожидается, что конечные IPv6-узлы выполнят Path MTU discovery для определения максимально-допустимого размера отправляемых пакетов и протокол более высокого уровня ограничит размер пакета. Однако если протокол более высокого уровня не в состоянии сделать этого, отправитель может использовать расширенный заголовок Fragment для выполнения фрагментации IPv6-пакетов. Все протоколы, передающие через себя IPv6-пакеты, должны иметь MTU равный или больший 1280 октетов. Протоколы, не способные передать пакет длиной 1280 октетов одним блоком, должны произвести фрагментацию и сборку самостоятельно, не затрагивая уровень IPv6.

21. Internet Protocol version 6 • Фрагментирование: Пакет, содержащий фрагмент оригинального (большого) пакета, состоит из двух частей: нефрагментируемая часть оригинального пакета, одинаковая для всех фрагментов, и фрагментируемая часть, идентифицируемая по смещению фрагмента. • Нефрагментируемая часть пакета состоит из фиксированного заголовка и расширенных заголовков оригинального пакета (опционально). • Значение поля NextHeader последнего заголовка нефрагментируемой части должно быть равным 44, обозначающее, что следующим заголовком будет Fragment. В заголовке Fragment поле NextHeader должно быть равно типу первого заголовка фрагментируемой части. После заголовка Fragment следует фрагмент оригинального пакета. Размер каждого фрагмента фрагментируемой части должен быть кратен 8, исключение составляет последний фрагмент.

22. Internet Protocol version 6 • Сборка фрагментов: Принимающий узел, собрав все фрагменты, отбрасывает расширенный заголовок Fragments и размещает фрагменты по смещениям, указанным в поле FragmentOffset, умноженным на 8. Пакеты, содержащие фрагменты, не обязаны приходить в правильном порядке, и они будут переставлены принимающим узлом, если потребуется. • Если спустя 60 секунд после получения первого фрагмента были собраны не все фрагменты, то сборка оригинального пакета отменяется и все полученные фрагменты отбрасываются. Если при этом получен первый фрагмент (с полемFragmantOffset равным нулю), то отправителю фрагментированного пакета посылается сообщение FragmentReassemblyTimeExceeded (ICMPv6 тип 3 код 1). • Максимальный размер оригинального пакета не должен превышать 65 535 октетов, а если после сборки оригинальный пакет оказывается больше, то он должен быть отброшен.

23. 6to4 • 6to4 это переходный механизм, позволяющий передавать IPv6 пакеты через IPv4 сети, и не требующий создания двусторонних туннелей. Это, как правило, используется, когда конечный пользователь или сайт хотят получить соединение с IPv6 Интернетом, но не могут получить его от провайдера. • 6to4 может использоваться как отдельным узлом, так и целой IPv6 сетью. При этом нужен как минимум один «белый» IPv4 адрес для шлюза, на каждый IPv4 адрес выделено до 1 208 925 819 614 629 174 706 176 (280) IPv6 адресов или до 65536 (216) подсетей.

24. 6to4 • Выделение блока адресов • Для каждого глобального адреса IPv4, выделена 48-битная 6to4 IPv6 приставка. Она может быть создана на основе IPv4 адреса. При этом адрес IPv4 ставится позади 2002::/16 приставки, но в шестнадцатеричном виде. Так IPv6 приставка для IPv4 адреса 192.0.2.4 будет равна 2002:C000:0204::/48. • Любой адрес IPv6 с приставкой 2002::/16, известен как 6to4 адрес. • Инкапсуляция • 6to4 хост вкладывает пакет IPv6 в пакет IPv4 с типом протокола 41 ("IPv6 (encapsulation)"). Перед тем как отправить пакет 6to4 хост проверяет адрес назначения на принадлежность к 6to4 сети и если это адрес соответствует 6to4, то он извлекает IPv4 адрес из 6to4 адреса и отправляет пакет по полученному адресу. • Маршрутизация между 6to4 и другими IPv6 сетями • Для того чтобы 6to4 хосты могли отправлять пакеты в другие IPv6 сети, были созданы 6to4 ретрансляторы, которые подключены как к IPv4 сети, так и к IPv6 сети. Когда 6to4 хосту нужно отправить IPv6 пакет, он отправляет его по anycastадресу 192.88.99.1. Ретранслятор, получив 6to4 пакет, извлекает IPv6 пакет и отправляет его по IPv6 сети. Для IPv6 хостов 6to4 хосты выглядят, как обычные IPv6 хосты и IPv6 пакет будет передан на ближайший 6to4 ретранслятор, анонсирующий префикс 2002::/16.

25. Teredo • Teredo — сетевой протокол, предназначенный для передачи IPv6 пакетов через сети IPv4, в частности через устройства, работающие по технологии NAT, путём их инкапсуляции в UDP дейтаграммы • Стандартные средства инкапсуляции IPv6 в IPv4 требуют, чтобы как сервер, так и клиент имели собственный IP-адрес. Однако, в настоящее время многие устройства присоединены к Интернету IPv4 через одно или несколько устройствNAT, как правило из-за нехватки IPv4 адресов. В такой ситуации единственный доступный IPv4 адрес принадлежит устройству NAT. Протокол Teredo даёт возможность доступа к IPv6 сетям при такой конфигурации сети. • В настоящее время активно обсуждаетсябезопасностьприменения протокола Teredo. Основной угрозой является то, что на данный момент не все межсетевые экраны способны фильтровать Teredo трафик, что может сделать возможным несанкционированное проникновение в IPv6 сеть.

26. History of the Internet WeeSan Lee weesan@cs.ucr.edu

28. 1969 ARPANET was born. 4 nodes were inter-connected: UCLA,SRI,UCSB, U. of Utah Charley Kline from UCLA sent 1st packet. First RFC by Steve Crocker.

29. 1970 RFC maintained by Jon Postel (the RFC-editor). ARPANET used NCP (Network Control Protocol), first end-to-end protocol

30. 1971 15 nodes were connected. Ray Tomlinson of BBN invented email program.

31. 1972 @ was chosen by Ray Tomlinson to separate the userid and hostname. First computer-to-computer chat program at UCLA.

32. 1973 Ethernet was invented by Bob Metcalfe's (Harvard PhD Thesis)

33. 1974 TCP (Transmission Control Protocol) was invented by Vint Cerf and Bob Kahn.

34. 1975 First mailing list was created by Steve Walker.

35. 1976 Queen Elizabeth II sent out an email.

36. 1978 TCP splited into TCP and IP.

37. 1979 3Com was co-founded by Bob Metcalfe.

38. 1981 BITNET (Because It’s Time NETwork) was started.

39. 1982 DoD used TCP/IP to inter-connect networks. Thus, the Internet!!!

40. 1983 NCP → TCP/IP. ARPANET was split into ARPANET and MILNET. BSD included TCP/IP.

41. 1984 DNS (Domain Name System) was introduced. > 1000 hosts.

42. 1986 NSFNET was created, connecting 5 super-computers. IETF was formed. NNTP was created.

43. 1987 > 10,000 hosts.

44. 1988 First Internet Worm released by Morris. CERT (Computer Emergency Response Team) was formed as a result. IRC was created.

45. 1989 > 100,000 hosts

46. 1990 ARPANET ceased. AOL, CompuServe provided dial-up service.

47. 1991 WWW was created by Tim Berners-Lee from CERN. Linux was released by Linus Torvalds.

48. 1992 > 1,000,000 hosts. MBONE was created.

49. 1993 Network Solution, Inc was chosen to provide domain name registration. www.whitehouse.gov online. Mosaic was created.

50. 1994 NSFNET was transformed to commercial network. Shopping mall. Can order pizza online.