IPv6 woes - RFC

Owen DeLong owen at delong.com
Sat Sep 25 19:25:48 UTC 2021



> On Sep 25, 2021, at 02:10 , borg at 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



More information about the NANOG mailing list