IPv6 woes - RFC

Sat Sep 25 10:43:47 UTC 2021

On Sat, 25 Sept 2021 at 11:10, <borg at uu3.net> wrote:

> Because IPv4 loopback is 127.0.0.1/8 and its usefull?
>

I am not sure why it is useful but nothing stops you from adding more
loopback addresses:

root at jump2:~# ip addr add ::2/128 dev lo
root at jump2:~# ping6 ::2
PING ::2(::2) 56 data bytes
64 bytes from ::2: icmp_seq=1 ttl=64 time=0.043 ms

While I am not sure what use extra addresses from the 127.0.0.0/8 prefix are
on the loopback, it is quite common for us to add extra global addresses
and then use that with proxy arp. Of course that is only necessary on IPv4
since IPv6 isn't so restrained that we have to save every last address bit
using tricks.

>
> - you can use nice short addreses like ::1234 for loopback
>

root at jump2:~# ip addr add ::1234/128 dev lo
root at jump2:~# ping6 ::1234
PING ::1234(::1234) 56 data bytes
64 bytes from ::1234: icmp_seq=1 ttl=64 time=0.046 ms

:-)

>   or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like
>

With IPv6 you can use fe80::1:aaaa for link local and fd00::1:0:1234 for
your RFC1918 like setup. And then you can use 1:1 NAT to transform that to
GUA on the router. Even NAT, if you insist on using it, is better with IPv6.

The confusion here appears to be that auto generated link local prefixes
are long with many hex digits. But compared to the new proposal, which
could have no auto generated link local due to having too few bits, there
is nothing that stops you from manually assigning link local addresses. It
is just that nobody wants to bother with that and you wouldn't either.

Example:

root at jump2:~# ip addr add fe80::1:aaaa/64 dev eth0
root at jump2:~# ping6 fe80::1:aaaa%eth0
PING fe80::1:aaaa%eth0(fe80::1:aaaa) 56 data bytes
64 bytes from fe80::1:aaaa: icmp_seq=1 ttl=64 time=0.033 ms

> ND is new thing and it requires new things to protect it from attacks?
>

I am not aware of any NDP attacks that would be any different if based on
ARP. Those two protocols are practically the same.

Regards,

Baldur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210925/a420c2e2/attachment.html>