Re: IPv6 prefix lengths - how long?

[Gyan Mishra <[e-mail]>]

All your concerns are duly noted.

As far as changing the prefix length I understand that with IPV6 it seems and maybe true that IPv6 exhaustion is not possible but that is what we said about IPv4 but that does not give reason to be wasteful.  I believe 64 bits iid is wasteful.

I understand the privacy extension and pseudo random id Understood is a double edge sword that the end user does not want their IP tracked but from the network administration perspective that is required for IP management and forensics to identify attackers.  So that does get tricky.

I think if we shaved just one 16bit field from the station id we could still maintain the pseudo random privacy extensions and also would give 16 bits to the prefix so instead of ISPs dolling out /48’s as the Norm to customers that could be scaled way way down to now giving out a /64 per customer would amount to the same # of subnets /64 subnets in a /48 64k subnets a /64 would now have 64k /82’s.  

From an enterprise security perspective IT security requires the ability to track every IP address on the network both IPv4 and IPv6.

So with IPv6 deployments with Verizon IT internally for security reasons to be able to track activities of any host we disable the random station id and temporary address set by default on hosts.

For law enforcement to be able to track unlawful IP how is that combatted for required forensic when the IPv6 address changes makes it difficult.

Network scanning with IPv6 is impossible so the need to a privacy extension where the IP changes on the same network is not as necessary as it makes forensics and troubleshoot impossible to track attackers which reading the link below which talks about rfc 7217 Symantec opaque interface IDentifiers which is stable non changing on the same network and only changes when moving between networks.

https://www.internetsociety.org/blog/2015/02/ipv6-security-myth-5-privacy-addresses-fix-everything/

Excerpt from the link above regarding privacy extension from ISC
In response to this privacy threat, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” were developed and are now published in RFC 4941. Ultimately the idea documented here is to generate “privacy addresses” (also known as “temporary addresses”) that change over time. Unpredictable and short-lived, these addresses are meant to combat the threat of your devices being identified and tracked as you use the Internet.

Myth: Privacy Addresses Fix Everything!
Reality: It’s Complicated

The first thing to note about privacy addresses is that they are created in addition to, not in place of, your “regular” SLAAC address. This means that for the purposes of scanning and locating hosts, privacy addresses are of little help.

Another issue that should be considered with regard to privacy addresses is their short-lived nature and its affect on troubleshooting and forensics. It is very hard for network administrators to manage a network full of devices constantly changing their source addresses. Setting up filters, looking back at logs, and many other regular tasks become much more difficult when you can’t predict what address a node will be using, nor guess which address it was using.

The obvious solution to both of these challenges is to use a single, stable address that is not based on the interface’s MAC address. Replacing the EUI-64 based SLAAC address with a randomized one does reduce the ability for an attacker to target OUI patterns or other heuristics. Making the address stable (across reboots and network moves) makes filtering, troubleshooting, and forensics much more possible than with truly temporary addresses. Unfortunately, an unchanging address does not address the privacy concerns that prompted the creation of privacy addresses in the first place – unchanging IIDs can be used to identify and track a given device.

A more recent solution to this is being called “Semantically Opaque Interface Identifiers” and a method for generating them is documented in RFC 7217:

This document specifies a method to generate Interface Identifiers that are stable for each network interface within each subnet, but that change as a host moves from one network to another. Thus, this method enables keeping the “stability” properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another.
Not bad! I do note that on-network correlation is still possible, since the addresses only change when moving from one network to another. But that is of course what makes the address easier to manage from a network administrator point of view. It should also be noted that a device could use privacy addresses for outbound communication and opaque addresses for inbound communication, possibly frustrating network admins but improving privacy.

The alternative to all of this would be to use properly configured DHCPv6 instead of SLAAC on your networks. Just be sure to take into account all the risks of scanning mentioned in the last myth, and consider using privacy/temporary addresses with your DHCP implementation for user privacy.


Sent from my iPhone

> On Jun 8, 2019, at 11:20 PM, Mark Smith <[e-mail]> wrote:
> 
> Hi Fred,
> 
> On Sat, 8 Jun 2019 at 03:44, Templin (US), Fred L
> <[e-mail]> wrote:
>> 
>> Hi, we all know about the tussle regarding the /64 boundary for IPv6 prefixes but
>> 
>> assuming that we will one day want to allow longer prefixes the question is “how long”?
>> 
>> 
>> 
> 
> <snip>
> 
>> 
>> 
>> Because of RFC7934, we see the value of Host Address Availability Recommendations.
>> 
>> It makes the point that, due to the nature of multi-addressing supported by IPv6, it
>> 
>> would be useful for each node to be able to configure multiple (perhaps even many)
>> 
>> IPv6 addresses from an IPv6 prefix. But, “how many”?
>> 
>> 
>> 
>> My assertion is that a multi-addressed host (or, an End User Network router) should
>> 
>> support numbering for at least 1K IPv6 addresses. This would imply that (assuming
>> 
>> at some point the /64 boundary is relaxed) the longest IPv6 prefix should be a /118.
>> 
>> 
> 
> I think we really need to work out what a host is first.
> 
> Is it the physical device? Virtual hosts within a physical device?
> Individual applications? Threads or processes within applications?
> 
> 
> "On Many Addresses per Host", S. Bellovin
> https://tools.ietf.org/html/rfc1681
> 
> 
> "Transient Addressing for Related Processes: Improved Firewalling by
> Using IPV6 and Multiple Addresses per Host", Peter M. Gleitz, Steven
> M. Bellovin
> https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html
> 
> 
> "node" is probably better to use to describe a network attached entity
> that needs one or more addresses to be able to send or receive
> packets.
> 
> The number of addresses a node needs depends on what it is, what it is
> doing and how it is going to use its addresses. In some cases 1K would
> be excessive for a node, for others it could be far too little.
> 
> As others have said, there can be other properties of addresses, such
> as privacy, security, and plug-and-play operation. As an example, the
> choice in 1980 of 48 bit Ethernet addresses, rather than just 10 bit
> addresses as originally required to suit a maximum of 1024 nodes on a
> link, has paid off immensely for nearly 40 years.
> 
> "Too many" addresses for a node, to the point where the unit of
> allocation starts to cost something where the cost is worth worrying
> about, is a much better answer than not enough.
> 
> I'd say that cost threshold is at /64 today (e.g. RFC 8273, "Unique
> IPv6 Prefix per Host"), also placing value on it being the minimum
> link allocation convention we've had for more than 20 years (since RFC
> 2373), and that there is more than approximately 3/4 of the total IPv6
> address space unallocated for any purpose at all.
> 
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>> Thoughts?
>> 
>> 
>> 
>> Fred
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------