Network: IPv4, IPv6 протоколы (фрагментация, флаги, nat, вопросы)

• У любого статического маршрута метрика 0 по умолчанию (Cisco)

• IP unnumbered позволяет обрабатывать пакеты без настройки IP-адреса на интерфейсе. Это работает путем “заимствования” IР-адреса у другого интерфейса.

• RIPE рекомендовал не принимать анонсы больше /24, большинство операторов придерживаются этого правила. Если хочется анонсировать префиксы большего размера (напр. /25) – нужно писать апстримам.

Фрагментация/FRAGMENTATION

• • Использование MSS в соответствии с настройкой MTU на интерфейсе
  • Path MTU Discovery (PMTUD)

Loobpack

• Иногда может быть удобно/безопасно использовать loopback адресацию для сервисов, которые должны взаимодействовать только в рамках одного узла – заведомо знаешь, что наружу эти сервисы не “торчат”

IPv6

>netsh int ipv6 show neigh
Интерфейс 49: vEthernet (Default Switch)
IP-адрес Физический адрес Тип
-------------------------------------------- ----------------- -----------
fe80::3c8f:65ff:628:3084 00-00-00-00-00-00 Недостижимый
fe80::7143:f0cc:1bf8:5e9f 00-00-00-00-00-00 Недостижимый
fe80::7c02:5035:3589:8919 00-00-00-00-00-00 Недостижимый
fe80::9c6f:14a9:ab96:25f7 00-00-00-00-00-00 Недостижимый
fe80::e1cf:42d4:10f7:da93 00-00-00-00-00-00 Недостижимый
ff02::1 33-33-00-00-00-01 Постоянный
ff02::2 33-33-00-00-00-02 Постоянный
ff02::c 33-33-00-00-00-0c Постоянный
ff02::16 33-33-00-00-00-16 Постоянный
ff02::fb 33-33-00-00-00-fb Постоянный
ff02::1:2 33-33-00-01-00-02 Постоянный
ff02::1:ff89:8919 33-33-ff-89-89-19 Постоянный

>ping fe80::3c8f:65ff:628:3084
Обмен пакетами с fe80::3c8f:65ff:628:3084 по с 32 байтами данных:
Ответ от fe80::3c8f:65ff:628:3084: время<1мс
Ответ от fe80::3c8f:65ff:628:3084: время<1мс
Ответ от fe80::3c8f:65ff:628:3084: время<1мс

Отключение IPv6 в Linux 😀

echo "net.ipv6.conf.default.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf

Примеры адресов IPv6 multicast

•                 FF02::1:FFC3:8FB – general
•                 FF02::1 – all nodes

For scanning of network, we ping the multicast address ff02::1 (FROM TRex manual)

•                 FF02::2 – all routers
•                 FF02::5 – all OSPF routers
•                 FF02::6 – DR OSPF routers

unicast/anycast

•                 2001:0:130F::9C0:876A:130B – global
•                 FE80::7F38:BE28:10FE – link-local
•                 FDEC:2707:2023::1/64 – unique-local (FC00::/7)
•                 2002::/16 – 6to4 tunnel
•                 ::IPv4_addr/96 – ipv6ip tunnel
•                 ::1/128 – loopback
•                 ::/128 – default

Unique Local IPv6-адреса FC00::/7 – это адреса по типу серых IPv4-адресов, но не совсем. Устройства с серыми IPv4-адресами могут маршрутизироваться в интернете через технологию NAT. А Unique Local IPv6-адресам это не нужно. Такие адреса назначают устройствам, которым не нужно никогда выходить в интернет. Например, принтер. Они должны быть доступны только внутри корпоративной сети. Подытожим, Unique Local IPv6-адреса используются только в пределах одной компании и не маршрутизируются в интернете.

ipv6 назначение адресов (slaac, dhcpv6)

• slaac – Хосты сами генерируют IPv6-адрес на основе информации, полученной от маршрутизатора (префикс маршрутизатора + mac хоста). Информация о серверах DNS добавляется вручную администратором.
• steteless dhcpv6 – Хосты получают только дополнительную информацию от сервера DHCP, такую как сервера DNS, маршруты. IPv6-адрес генерируется на основе информации, полученной от маршрутизатора (slaac + доп. Опции по dhcp).
• stateful dhcpv6 – Хосты получают всю информацию от сервера DHCPv6, включая IPv6-адрес, сервера DNS и т.д.

NAT

• Хорошо разобрана работа и настройка NAT на Cisco (ASA, Firepower)
• SNAT – кейс выход пользователей в интернет
• DNAT – кейс доступ внешних пользователей в DMZ
• UPNP включает NAT-PMP и IGD, каждый из который позволяет приложениям автоматически открывать порты на роутерах с включенным UPNP; безопасность безусловно при этом страдает

The UPnP and NAT-PMP service enables client PCs and other devices such as game consoles to automatically allow required inbound traffic and can account for outbound NAT on traffic using the same ports. There are many popular programs and platforms which support UPnP such as Torrent clients, Steam/Steam Deck, Nintendo consoles, PlayStation consoles, XBox consoles, video conferencing apps, and more. NAT-PMP is supported primarily by Apple products.

UPnP and NAT-PMP are a classic example of the “Security vs. Convenience” trade-off. By their very nature, these services are insecure. Any program on the network can allow in and forward any traffic – a potential security nightmare.

Overload

При NAT overload порт источника не сохраняется:

• • он может не сохраняться независимо от наличия текущих записей (скрин ниже с примером Cisco IOS NAT)
  • или может не сохранятся только при конфликте с текущими записями
  • в теории можно реализовать сохранение – напр. пул IP и выборка из пула того белого IP, у которого порт свободен, но я о таких реализациях не слышал

Сколько локальных IP в один обычно мапится:

1. 1. На Cisco по умолчанию 120 в 1
   2. В провайдерах при использовании CGNAT обычно 32/64/128 в 1

Paired-Address-Pooling
ip nat settings pap [limit {1000 | 120 | 250 | 30 | 500 | 60}]

Configures NAT paired address pooling configuration mode.
Use the limit keyword to limit of the number of local addresses you can use per global address. The default is 120.

Пользователю выделяются блоки по 1к портов (максимум 4 блока) с таймаутом в 5 минут

NAT и IPv6

В IPv6 есть 6to6 NAT. Как я понимаю это для угоды “люди привыкли”, в целом “отцы” судя по rfc4864 (реализуем плюсы NAT без NAT) против NAT’ов в IPv6, поэтому и private address space (аналог дипазонов 10/172.16/192.168, которые NAT’ились) отменили в последующем . Есть так же NPTv6, но насколько я понял это NAT, не похожий на текущий – нет stateful таблицы, нет конкретных хостов в таблице .

https://networklessons.com/cisco/ccie-routing-switching-written/ipv6-nptv6-network-prefix-translation

The NPTv6 support on ASR1k/CSR1k/ISR4k feature supports IPv6-to-IPv6 Network Prefix Translation (NPTv6) which enables a router to translate an IPv6 packet header to IPv6 packet header and vice versa. The IPv6-to-IPv6 Network Prefix Translation (NPTv6) provides a mechanism to translate an inside IPv6 source address prefix to outside IPv6 source address prefix in IPv6 packet header and vice-versa. A router that implements an NPTv6 prefix translation function is referred to as an NPTv6 Translator.

ВОПРОСЫ

Какой префикс IPv6 зарезервирован для 6to4 туннелей?

2002::/16

Какое поле IPv6 заголовка предотвращает зацикливание IP пакетов?

Hop limit (ранее TTL)

От какого заголовка IPv4 отказались в IPv6?

Header Checksum

ICMPv6 (Neighbor Discrovery Protocol)

AC

A

C

AB

A: Although RFC2544 assumes that the testing with UDP, I agree that considering TCP connection handling is important here, since stateful NATxy boxes are not simple IP forwarders, but they are kind of L4 devices as I said in my previous mail.


Q: The issue with any middle box is that vendors typically optimize processing for specific protocol. While measuring performance for UDP is great for gaming and voice (typically), TCP brings additional processing overhead which will make the box (typically) perform slower.
As for the concerns on testing - we can introduce concept of ?ramp up? during test, which is to lessen the impact of blasting DUT with maximum amount of flows at the same time, and instead ramp them up from baseline of X, with Y connections per second within next Z seconds (for example - 60 seconds). Of course, we could potentially recommend doing *both* of the tests, to show peak and nominal performance, so the lab test team would be able to asses results in wider spectrum of operating regimes.

A: I agree with you that NAT protocol helpers may have a significant impact 
on the throughput of the NATxy boxes and, therefore, the distribution of 
the destination port numbers matters a lot.

On the one hand Section 4.5 of RFC 4814 (the authors of which I have 
CC-d), requires a uniform distribution of the destination port numbers 
in the range of [1, 49151].
On the other hand, I think that the Author of RFC 4814 did not intend to 
say anything about the popularity of the different protocols. They 
focused on the hashing effect of the port numbers, that is, how the test 
frames are distributed among the different CPU-s of the DUT.

Authors, did I understand your intention well?

If it is so, then I can imagine two major approaches to handle the 
problem of NAT protocol helpers:

Approach 1.
Collect statistic about the popularity of the different protocols (that 
is the distribution of the destination port numbers) and generate 
pseudorandom destination port numbers by following that distribution. 
Hopefully, pseudorandom source port numbers will still do an appropriate 
hashing.
In fact, our draft has already done a similar thing by limiting the 
destination port numbers to avoid a DoS attack against the connection 
tracking table of the DUT, please refer to Section 4. 1 
https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful#section-4.1

However, these two solutions may conflict with each other, therefore, I 
would prefer the following approach.

Approach 2.
Completely eliminate the phenomenon of protocol helpers (either by 
disabling them or leaving out their port numbers, perhaps by leaving out 
all the system port for simplicity). We recommended to use a "narrow" 
range for destination port numbers. So this range should not overlap 
with the range of the system ports.
And apply and additional benchmarking test according to "Benchmarking 
Methodology for Network Security Device Performance", the (the authors 
of which I have also CC-d) the latest version of which is available 
from: 
https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-ngfw-performance-09

Authors of that draft, do you think that Approach 2 can be feasible?


Q: In my opinion, a good standard procedure for measuring NATxy boxes is very useful and important.
I assume a very important problem is NAT protocol helpers (e.g. ftp, pptp, tftp). Their implementations on the NATxy boxes can greatly affect the performance of the device. 
So it is important to take these into account. A possible solution is to omit well-known ports of these protocols from the target ports, or to consider some statistical distributions of them in the measurement process. 
(And I have more ideas...) I suggest a deeper investigation of this problem and possible modifications based on the results.