Re: Extending a /64

[Mark Smith <[e-mail]>]

On Mon, 16 Nov 2020, 09:03 Michael Richardson, <[e-mail]>
wrote:

>
> Mark Smith <[e-mail]> wrote:
>     > On Mon, 16 Nov 2020, 07:19 Philip Homburg, <
> [e-mail]>
>     > wrote:
>
>     >> > Again, there are 35 trillion /48s in 2000::/3. How many would you
>     >> > need?
>     >>
>     >> It gets tight when you want the prefix to contain 39 bits to number
> around
>     >> half a million planes.
>     >>
>
>     > Why are half a million planes going to be on the Internet?
>
> No, not "Internet"
> "internet" --- as in, uses IPv6.
>

Asking for GUA space implies attached to the big-I Internet when the ULA
space exists for non-Internet connected devices.

If a single /48 ULA isn't big enough, generate more.


How and if it connects to the DFZ is not really any of our business.
>


It is when GUAs are being requested, and the RFC4291 address format is
being ignored. It's not IPv6 and can't be called "IPv6" if it doesn't
comply with the IPv6 specifications.

GUAs have two properties:

- globally unique address
- provide potential global reachability to any and all global Internet
destinations

ULAs only have the first property.

If a device doesn't need the second property, the device doesn't need a GUA.

The security principle of least privilege demands that devices aren't given
the second property when they don't need it.


> Because thinking that you can put ALG gateways and NATs and other crap in
> the
> way to keep stuff off the internet is IPv4 think.


A management platform or system that controls and aggregates data from ULA
addressed devices is perfectly compliant with the IPv6 architecture,
because the management system is built with hosts. No NAT, no ALGs, the
transport connections are end host to end host within the distinct network.

Outside access to that would be via multi-homing one or more of the hosts
in the management system. Specifically, forwarding between the hosts'
interfaces is not enabled. The multihomed host(s) are relaying data between
these two networks at the application layer and as part of the application
architecture.

This is how the IPv6 smart meter network I've seen works - and actually,
were IPv6 only on the meter side, and only IPv4 on the outside.

The reason NATs and ALGs cause problems is they're not proper and distinct
RFC8200 hosts or routers. They're a mutant half way between - do more than
dumb packet forwarding (routing), but don't properly do all of what the
host and application processing does. They "half" participate in the end to
end protocols.

If you can't or don't want to for security reasons provide direct host to
host connectivity within a single network, you partition the network into
two with a multihomed host or hosts and have an application architecture
that suits that. Anything less than that i.e. NATs or ALGs, doesn't comply
with the device roles in RFC8200, and suffers from the well known problems
caused by "more than routers, but not full hosts".

Regards,
Mark.


> If our answer to requests for IPv6 address space involves IPv4-style
> justification, then we might as well give up and go for triple-NATed CGN.
>
> Now, I don't understand how 39bits are needed to number log_2(10^6) =
> 20bits
> of airplane.  It seems to leave more than 16-bits for subnets on each
> airplane, which is still a lot.
>
> Remember that it might be 2^19 concurrent airplanes, but the address plan
> would be expected to last a hundred years or so.
>
>
>     > Supposedly only some drones needed (really?) to be on the Internet.
> How did
>     > that turn into every plane?
>
> Because every plane has electronics that speak IPv6.
>
>     > Can somebody post a link to the draft that tries to justify this
> idea?
>     > Has a security threat model been done?
>
> Who cares?  Firewalls work regardless of what address space is used.
>

I



> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>