On Sep 25, 2021, at 02:10 , borg@uu3.net wrote:
Because IPv4 loopback is 127.0.0.1/8 and its usefull?
How so? Where do you actually use 16.7 million loopback addresses, let alone 18 Quitillion+ * 65536 (/48)?
0:0:1-ffff:0/32 means you generate addreses from that range and not necessary using /32 prefix.. It just range thats reserved for LL.
So you want to reserve the range 0:0:1:0..0:0:ffff:0 with all zeros in the last 16 bits as loopback? Why the (effectively discontiguous net mask)? Why not include 0:0:0:0 in it? Sorry, not trying to rain on your parade, but trying to understand your thinking here.
Same about RFC1918 aka space.. its a range reserved for local addreses.
My point was why repeat the RFC-1918 mistake. There’s really no need for it unless you intend to recreate the NAT problems. Further, you specified: 0:0:0:1/48 as loopback, that’s the range 0:0:0:0..0:0:0:ffff in your proposed addressing structure. 0:0:1-ffff:0/16 as RFC-1918, that’s an odd way of notating 0:0:0:0..0:ffff:ffff:ffff in your proposed addressing structure. As such, your meaning is unclear. So it’s unclear how you intend to map ranges and netmxasks in your proposal.
The whole rationale is: - shorter prefix wins (so no overlap?)
Usually longest matching prefix wins, but when you’re talking about the distinction between RFC-1918 and loopback, I think overlap poses a human factors problem that you haven’t considered.
- you can use nice short addreses like ::1234 for loopback or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like
Not to put too fine a point on it, but ::1 works in IPv6 today. If you want, you are free to assign anything else you want on the loopback interface, so for example, you could assign fd:0:0:1::/64 to the loopback interface and use any address you want from fd:0:0:1::0 through fd:0:0:1:ffff:ffff:ffff:ffff as loopback addresses. (I don’t see a point in using GUA for loopback as long as the ULA silliness exists. In fact, this might be the one and only legitimate use case I can see for ULA.) For RFC1918, you can make up anything you want within fd::/8 in IPv6 as it exists today. Ideally, you choose a randomized /48 from fd::/8 and subnet that along /64 boundaries, but I don’t see that as significantly more complex than what I think you are proposing.
Whole ::1 short format should be used only to cut leading zeros not "more zeroes whatnever they appear".
Why? The current format allows you to put the :: wherever you think it makes the most sense and as long as there’s only one :: in an address (which is a requirement), there’s no ambiguity about the number of 0s replaced. Yes, it makes textual comparison of addresses messy, but there’s really no need for that. Far better use textual representations only for user presentation anyway. Internally, they should always be stored/handled as a 128-bit unsigned integer value. So the fact that: 2001:db8:0:1::5 2001:db8::1:0:0:0:5 Are two different ways of representing the same address isn’t of any concern unless you’re making the mistake of trying to string wise compare them in their text-representation format. Both equate to the same uint128_t value.
ND is new thing and it requires new things to protect it from attacks?
Not so much. The defined ND attacks aren’t new for ND. They all exist in ARP as well. What is new is 64-bit wide network segments. If you put a /6 on a switch in IPv4 and then do an ARP scan, you’ll get the same table overflow problems as you are talking about with “ND attacks”. The difference is that in IPv4, /6 networks are extraordinarily rare (if any exist at all) while it is commonplace in IPv6 to have /64 network segments. Nonetheless, this isn’t actually inherent in the difference between ND ad ARP, it is inherent in the difference between network segments limited to 1024 possible host addresses or less and network segments that have more than 18 Quintillion possible host addresses. In fact, if you’re really super-worried about this (which isn’t really a thing in most environments, TBH), you can create your IPv6 networks as /120s or /118s or whatever and simply limit the total number of available host addresses. You have to give up some IPv6 features that don’t exist in IPv4 anyway, but ND will still work and you won’t have to worry about table overflows any more than you did in IPv4.
While all the hate towards NAT, after years of using it I see it as cool thing now. Yeah it breaks E2E, and thats why its place is only at CPE. The true tragedy is CGN.
So making the average household a second-class citizen on the network is “cool thing now”? Not in my opinion. There are lots of applications that should exist today and don’t because we chose to break the E2E model. Of the applications that do, there is a great deal of added complexity, fragility, and a loss of privacy due to the use of rendezvous hosts to overcome the difficulties posed by NAT. Even in CPE, NAT is still harmful. CGN just makes it clear how harmful it is at an even larger scale.
Yeah, services make money so they should addapt new protocol, so users can access those services. In my opinion, due to IPv4 exhaustion, this is right adoption scheme. You move users to IPv6 and free IPv4 addresses for more services. It means internet can still grow and noone is really cut off. Once IPv6 mass is big enough, you can start to fade IPv4 services.
Yeah, that’s not really effective. What really needs to happen is moving content to IPv6 so that new users that are IPv6-only aren’t faced with a less useful internet. Moving eyeballs to IPv6 while growing content in IPv4- only land helps no-one. The content providers lose users. The users lose access to content. Owen