Все в порядке с безопасностью. Для обычного юзера никаких проеимуществ нет, оно просто работает и все. А вот IPv4 для обычных юзеров скоро работать не сможет - все, адреса официально закончились. Остался только вторичный рынок, так что агонию можно будет продлить лет на пять.
@@NetworkeducationRu есть одно преимущество очевидное - связность пир ту пир, в частности это очень хорошо будет заметно при большом распространении IPv6 на тех же торрентах. + СИП телефония без НАТа, это тоже как по мне - преимущество. нагрузка на домашние роутеры ниже за счет отсутствия НАТа, это тоже преимущество. плюсов много.
Правильно ли я понимаю, что минимальный MTU = 576 байт, это не минимально возможное MTU IPv4 пакета, а тот предельный минимум, который обязано поддерживать оборудование? Другими словами, любой маршрутизатор не может быть спроектирован так, что у него максимальный поддерживаемый MTU < 576 байт? А минимальный MTU самого пакета это 46 байт, которые можно вложить в ethernet кадр?
хотя нет, 46 байт это минимум, что должно быть вложено в Ethernet, но до него можно ещё добивать нулями. Нашёл в wiki, что минимальный размер ipv4 = 20 байт, это чистый заголовок без самих данных.
Давайте разбираться. Маршрутизаторы не обязаны работать по Ethernet, есть куча других канальных технологий, в которых IP прекрасно себя чувствует. - Если маршрутизатору нужно отправить маленький пакет в Ethernet-кадре, это проблема Ethernet - как добить содержимое до 46 байт, и как потом отделить зерна от плевел. - Но зато если нужно отправить в Ethernet-кадре слишком большой пакет, то это уже проблема маршрутизатора, и там начинаются пляски с фрагментацией. IP пакет может быть любого размера в известных пределах. - Если речь идет про IPv4, то размер пакета вместе с заголовком вкладывается в 16-битное поле Total Length. Ограничение снизу - 20 байт (размер заголовка), сверху - 65535 байт. - Если речь идет про IPv6 (без Jumbo Payload), то размер пакета ограничен снизу 41 байтами (при использовании Payload length=0 обязана присутствовать опция Jumbo Payload, так что хотя бы один байт нагрузки положить придется, плюс 40 байт фиксированного заголовка). Ограничение сверху вытекает из 16-битного поля Payload Length плюс 40 байт фиксированного заголовка, не включенного в оное, т.е. 65535+40=65575 байт. Не любые канальные среды и устройства нормально работают с пакетами слишком большого размера. В частности, на момент создания IPv4 были устройства, приемный буфер которых был ограничен 1КБ памяти. Такие устройства не могут принять пакет размером 65535 байт. - Чтобы отправитель мог отправить пакет и не заботиться о том, что получатель его не прожует, авторы IPv4 договорились о том, что любое устройство способно обработать пакет размером до 576 байт, включая заголовки. Больше - по желанию, но 576 и меньше - обязательно. - В IPv6 этот порог повысили до 1280 байт.
Цитата из RFC791 (IPv4): Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols.
Всё отлично, но не ожидал от того кто озвучивает лекцию таких ляпов. Не надо переходить на IPv6, его надо ДОБАВЛЯТЬ, без дуалстека пока никуда к сожалению.
Никто не спорит с этим. Рискну предположить, что в контексте речь шла про то, что 1) необходимо внедрять IPv6 на транспорте и 2) настраивать приложения с его поддержкой.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Для обычного юзера приемущества есть? Или нет? И что с безопасностью?
Все в порядке с безопасностью.
Для обычного юзера никаких проеимуществ нет, оно просто работает и все. А вот IPv4 для обычных юзеров скоро работать не сможет - все, адреса официально закончились. Остался только вторичный рынок, так что агонию можно будет продлить лет на пять.
@@NetworkeducationRu есть одно преимущество очевидное - связность пир ту пир, в частности это очень хорошо будет заметно при большом распространении IPv6 на тех же торрентах. + СИП телефония без НАТа, это тоже как по мне - преимущество. нагрузка на домашние роутеры ниже за счет отсутствия НАТа, это тоже преимущество. плюсов много.
Правильно ли я понимаю, что минимальный MTU = 576 байт, это не минимально возможное MTU IPv4 пакета, а тот предельный минимум, который обязано поддерживать оборудование? Другими словами, любой маршрутизатор не может быть спроектирован так, что у него максимальный поддерживаемый MTU < 576 байт? А минимальный MTU самого пакета это 46 байт, которые можно вложить в ethernet кадр?
хотя нет, 46 байт это минимум, что должно быть вложено в Ethernet, но до него можно ещё добивать нулями. Нашёл в wiki, что минимальный размер ipv4 = 20 байт, это чистый заголовок без самих данных.
Давайте разбираться.
Маршрутизаторы не обязаны работать по Ethernet, есть куча других канальных технологий, в которых IP прекрасно себя чувствует.
- Если маршрутизатору нужно отправить маленький пакет в Ethernet-кадре, это проблема Ethernet - как добить содержимое до 46 байт, и как потом отделить зерна от плевел.
- Но зато если нужно отправить в Ethernet-кадре слишком большой пакет, то это уже проблема маршрутизатора, и там начинаются пляски с фрагментацией.
IP пакет может быть любого размера в известных пределах.
- Если речь идет про IPv4, то размер пакета вместе с заголовком вкладывается в 16-битное поле Total Length. Ограничение снизу - 20 байт (размер заголовка), сверху - 65535 байт.
- Если речь идет про IPv6 (без Jumbo Payload), то размер пакета ограничен снизу 41 байтами (при использовании Payload length=0 обязана присутствовать опция Jumbo Payload, так что хотя бы один байт нагрузки положить придется, плюс 40 байт фиксированного заголовка). Ограничение сверху вытекает из 16-битного поля Payload Length плюс 40 байт фиксированного заголовка, не включенного в оное, т.е. 65535+40=65575 байт.
Не любые канальные среды и устройства нормально работают с пакетами слишком большого размера. В частности, на момент создания IPv4 были устройства, приемный буфер которых был ограничен 1КБ памяти. Такие устройства не могут принять пакет размером 65535 байт.
- Чтобы отправитель мог отправить пакет и не заботиться о том, что получатель его не прожует, авторы IPv4 договорились о том, что любое устройство способно обработать пакет размером до 576 байт, включая заголовки. Больше - по желанию, но 576 и меньше - обязательно.
- В IPv6 этот порог повысили до 1280 байт.
Цитата из RFC791 (IPv4):
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.
The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information. For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram. The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.
+
Всё отлично, но не ожидал от того кто озвучивает лекцию таких ляпов.
Не надо переходить на IPv6, его надо ДОБАВЛЯТЬ, без дуалстека пока никуда к сожалению.
Никто не спорит с этим. Рискну предположить, что в контексте речь шла про то, что 1) необходимо внедрять IPv6 на транспорте и 2) настраивать приложения с его поддержкой.