Subject: IPv6 prefix lengths - how long?

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 7 Jun 2019 17:43:12 +0000

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"?

We all know about /127 for point to point links, but I am not talking about those. I am

talking about prefixes that are assigned to nodes that might be acting either as routers

or as multi-addressed hosts.

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.

Thoughts?

Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Jun 2019 11:10:11 -0700

From my perspective, there is no requirement that there be a single prefix. You could have 128 prefixes, each with 8 addresses in use. I'm not sure why you would, but I don't see an architectural reason that you couldn't. You just wouldn't be using SLAAC to assign them.

From my perspective, if a platform contains some number of internal objects (VMs, containers, applications, whatever) that each get one or more addresses, I'd be hard pressed to make a general statement about the platform. If it needs to support 10,000 VMs-or-whatever, I guess it needs to support at least 10,000 addresses. If they are all packaged up into one prefix, that's going to be a /112 prefix at least, and the platform had best support it.

It's not really a technical requirement that all platforms have to support. It's a market requirement, and the platform in question is being designed to meet that market.

> On Jun 7, 2019, at 10:43 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> assuming that we will one day want to allow longer prefixes the question is “how long”?
> 
> IPv6 addresses from an IPv6 prefix. But, “how many”?
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 15:27:01 -0400

TorIX uses a /111 prefix for the IX network.

This seems to be just big enough so that they can match the last two octets
of the IPv4 with the last two octets of the IPv6, plus a bit of room to grow
(I guess).   Routers are not configured by SLAAC (or DHCPv6).

This choice seems to be related to concerns about limitations on floods of ND
and inability (in some equipment at some point in history) to lock down the
IPv6 neighbor cache.

My feeling is that we should be able to use LL addresses only at IXs.
I'm sure that there is something missing in some systems that prevents this,
but maybe we should think about whether this should be documented as a
requirement.

Fred is asking about a completely different situation, but ultimately it is
also about management of neighbor cache entries.  How do we divide up and
protect a limited resource against abuse?

BTW, I think that a /118 is trivially enumerable by an attacker.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 15:30:54 -0400

Fred Baker <[email-masked]> wrote:
    > It's not really a technical requirement that all platforms have to
    > support. It's a market requirement, and the platform in question is
    > being designed to meet that market.

I agree that it's a market requirement not a technical requirement.

It would help the market if customers could understand which market they are
in, and could communicate their needs consistently to vendors (or to search
engines).

And vendors could position their equipment intelligently into different
markets.  So it would be nice if we could make up a few categories that
we know about, leaving gaps where we don't know anything.

The IETF Conference network is clearly one category we know well.
An IX network is another useful data point.

The data center with 10,000 VMs in a cabinet is probably a third, but it may
be far more complex.  Maybe the RIFT people can give us some numbers.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 7 Jun 2019 20:51:49 +0100

> but maybe we should think about whether this should be documented as a

I'm not fully sure that there is a problem here that needs to be fixed, 
at least for IXs.  Just to clarify the problem statement I think you're 
talking about: IXs can benefit from an ARP sponge to dampen ARP chatter, 
but there are concerns that the large host address space associated with 
/64 could cause ND cache exhaustion on routers.  Both these issues are 
well known to IXPs.

Some AMS-IX people wrote a paper about 10y ago about this - "Effects of 
IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge".  Their 
analysis suggested that the best approach was to use an ARP sponge for 
ipv4, and to use l2 port ingress mcast rate limiters for ipv6, with no 
ND sponge.  Neither the ipv4 nor ipv6 cases provided compelling reasons 
to think that there were insurmountable operational barriers for 
handling the root problem.  In any event, no IXP that I know of has been 
taken out by ND cache exhaustion, and for sure, people on the Internet 
test that vector regularly enough.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 16:27:17 -0400

Nick Hilliard <[email-masked]> wrote:
    > Some AMS-IX people wrote a paper about 10y ago about this - "Effects of IPv4
    > and IPv6 address resolution on AMS-IX and the ARP Sponge".  Their
    > analysis

Thank you for the pointers. my google results for the archives:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692 and
https://www.delaat.net/rp/2008-2009/p23/report.pdf
Effects of IPv and IPv address resolution on AMS-IX and the ARP Sponge

Abstract
  Heavy ARP traffic can cause routers to run out of resources. Therefore,
  AMSIX developed a daemon called ARP Sponge. When the number of ARP requests
  for an IP address exceeds a threshold, the ARP Sponge starts sending ARP replies
  which keeps ARP traffic down. The ARP Sponge currently works using IPv only.
  IPv uses Neighbor Discovery (ND) instead of ARP for address resolution. ND
  uses the solicited-node multicast address instead of broadcast, consuming
  less resources from routers. Therefore, IPv support should not necessary,
  though it still can be used to detect network problems and legacy router
  configurations.
  We tested this on an emulation of the AMS-IX platform, both the current
  version and its new version, yet to be introduced, based on MPLS/VPLS and
  with various customer platforms and found that IPv support need (and maybe
  should) not be implemented.

https://www.os3.nl/_media/2012-2013/courses/rp2/p57_report.pdf
Abstract
  The AMS-IX ISP Peering LAN connects more than 600 routers. These routers use
  ARP in order to establish connectivity with each other. With such a large network, it
  can be expected that there are nodes down at any moment. Even if that is not the case,
  there are also ARP Requests for IP addresses no longer in use. This causes severe
  broadcast traffic in the network.
  All the nodes that are listening for ARP messages have to further process the packets,
  meaning that all nodes in the network will spend CPU cycles to process
  these messages. This is inefficient, as most of the time those messages do
  not concern them,
  and some devices even prioritize ARP processing over, for instance, routing protocol
  jobs.
  So far, the solution that AMS-IX has implemented is the ARP Sponge. This
  tool reduces the amount of broadcast traffic on the peering LAN by replying
  to ARP requests for dead addresses.
  The goal of this research project is to investigate the use of OpenFlow to
  further bring down the amount of broadcast traffic on the AMS-IX peering
  LAN.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Jun 2019 08:52:16 +1200

I can't speak for the other authors of draft-bourbaki-6man-classless-ipv6,
but my answer is: this question isn't our business. If we disestablish
the /64 boundary, we surely don't replace it with a new one.

Privacy considerations are probably a determining factor, as we
hinted in https://tools.ietf.org/html/rfc7421#section-4.5

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 7 Jun 2019 16:23:14 -0500

I mostly agree with Brian, other than that are many advantages to alignment
on nibble boundaries with the hexadecimal representation of IPv6 addresses.
So, any of the 16 nibble aligned options seem fine with me; /64, /68, /72,
/76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124. So,
personally, I would argue against /118 on that principle.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 8 Jun 2019 11:51:48 -0400

6MAN,

I agree with Brian and David on increasing the prefix length past the 64 bit boundary and agree that there are many advantages to alignment on nibble boundaries with the hexadecimal representation of IPv6 addresses. 

The RFC 4291 IPv6 addressing and the original stance on 64bit boundary was based on the EUI64 format for the Mac generated FFFE bit stiff between the 3rd and 4th octet of the station id or random station id.

I agree that a 64bit station id was overkill and was made 20 years ago thinking futuristically that every physical device you can think of would have an IP but now in reality large in my opinion that would never be used and really wasted valuable bits on a station Id that could have been used more wisely to expand the prefix length.

If we make the prefix longer to whatever size makes sense and I am all for it and have wanted to make that change to the standard length for a long time now.

If we all do agree to increasing the prefix length any of the 16 nibble aligned options seem fine with me; /64, /68, /72, /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124. 

Of all the nibble values listed above what I am thinking a value that would make sense given how flat we can go with future L2 switching broadcast domain taking into account future IPv6 only but also current dual stack infrastructure of having both IPv4 broadcast and IPv6 constrained multicast what would be the maximum subnet size that is still future looking and future proof.

I can take the onus on creating a new draft that would update RFC 4291 and any other applicable RFCs on the prefix length increase.

6MAN chairs 

Please let me know if you are Ok with be moving forward with creating this draft and I will get started now on 00 revision.

Thank you

Gyan Mishra
Verizon Communications 
Phone: 301 502-1347
email:[email-masked]

> On Jun 7, 2019, at 5:23 PM, David Farmer <[email-masked]> wrote:
> 
> I mostly agree with Brian, other than that are many advantages to alignment on nibble boundaries with the hexadecimal representation of IPv6 addresses. So, any of the 16 nibble aligned options seem fine with me; /64, /68, /72, /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124. So, personally, I would argue against /118 on that principle.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Jun 2019 18:28:44 +0200

>The RFC 4291 IPv6 addressing and the original stance on 64bit boundary was bas
>ed on the EUI64 format for the Mac generated FFFE bit stiff between the 3rd an
>d 4th octet of the station id or random station id.
>
>I agree that a 64bit station id was overkill and was made 20 years ago thinkin
>g futuristically that every physical device you can think of would have an IP 
>but now in reality large in my opinion that would never be used and really was
>ted valuable bits on a station Id that could have been used more wisely to exp
>and the prefix length.

With SLAAC, EUI64 has to some extent been replaced with pseudo-random 
numbers.

For that to work, the number of bits needs to be sufficient to avoid
collisions. The exact number of bits you need depends on the number of
addresses on a subnet and how much you care about the damage done by
collisions.

The problem is that we know that a 64 bit pseudo-random number is safe,
but there is no sensible way to set a lower bound. There certainly is
no consensus on a lower bound.

At the same time, we are not running out /64 prefixes. We have prefix
allocation problem. We have enough /64s to give every virtual subnet its
own /64.

So the obvious thing to do is to leave the 64 bit boundary in place for SLAAC.

If you really need longer prefixes, then just use static configuration or
DHCPv6.

---

From: James R Cutler <[email-masked]>
Date: Sat, 8 Jun 2019 13:02:36 -0400

> On Jun 8, 2019, at 12:28 PM, Philip Homburg <[email-masked]> wrote:
> 
> ——————————————————————————————————

I have difficulty considering the use of a 64 bit as a “waste" because it:
1. Has not been shown to create a resource shortage in the foreseeable future.
2. It is a “safe” size for a pseudo-random space as far as we know.
3. As Philip Homburg stated, we have no proof for a minimum size space.

I consider the effort and confusion involved in modification away from 64 bit Station IDs to be a waste (SLAAC, anyone?). 

I would rather see the effort put into better solutions security problems, including name to address resolution and routing.

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 Jun 2019 13:20:20 +1000

Hi Fred,

> assuming that we will one day want to allow longer prefixes the question is “how long”?

<snip>

> 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.

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 Jun 2019 14:00:26 +1000

On Sun, 9 Jun 2019 at 03:03, James R Cutler <[email-masked]> wrote:
<snip>
> 3. As Philip Homburg stated, we have no proof for a minimum size space.

Waste occurs when you get no useful value from something.

As a relevant example, Ethernet addresses are 48 bits, yet when
Ethernet was designed, there was a limit of 1024 nodes on a link. That
means only 10 bits were required to uniquely identify a node.

So what value have those other 38 bits provided in the past 39 years,
and has that been useful value? Or does everybody think those other 38
bits are a waste, because they're strictly not necessary for the
protocol to work?

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 9 Jun 2019 10:07:35 -0400

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 <[email-masked]> wrote:
> 
> Hi Fred,
>

---

From: James R Cutler <[email-masked]>
Date: Sun, 9 Jun 2019 11:54:09 -0400

> On Jun 9, 2019, at 10:07 AM, Gyan Mishra <[email-masked]> wrote:
> 
> 
From many views, I must agree with you about “wasteful”.

Where we part company is that the costs involved in changing away from 64 bits is more wasteful than your proposal. The especially applies to time (labor) costs, both for new RFPs, design and prototyping, and deployment costs. It has take around two decades to get this far with IPv6. Adding yet another detour to this journey is not an improvement.

James R. Cutler
[email-masked]
GPG keys: hkps://hkps.pool.sks-keyservers.net

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Jun 2019 05:41:02 +1000

On Mon, 10 Jun 2019 at 00:07, Gyan Mishra <[email-masked]> wrote:
> 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

Nobody said that.

>From Vint Cerf, about the IPv4 address structure before IPv4 became
popular. This addressing structure is described in RFC 760, before
classes were introduced. Classes were introduced in RFC 791, and were
the first of many hacks to squeeze more host and network addresses out
of IPv4's 32 bit address field.

"When the Internet design work began, there were only a few fairly large
networks around. ARPANET was one. The Packet Radio and Packet Satellite
networks were still largely nascent. Ethernet had been implemented in
one place: Xerox PARC. We had no way to know whether the Internet idea
was going to work. We knew that the NCP protocol was inadequate for
lossy network operation (think: PRNET and Ethernet in particular). This
was a RESEARCH project. We assumed that national scale networks were
expensive so there would not be too many of them.  And we certainly did
not think there would be many built for a proof of concept. So 8 bits
seemed reasonable. Later, with local networks becoming popular, we
shifted to the class A-D address structure and when class B was near
exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but
perhaps others also) came up with CIDR and the use of masks to indicate
the size of the "network" part of the 32 bit address structure. ..."

https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

> but that does not give reason to be wasteful.  I believe 64 bits iid is wasteful.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 9 Jun 2019 21:25:42 -0400

I concur with you on the cost benefit trade off.

However I would like to state that there have been many tweaks to RFCs
written  across the board across all IETF workgroups and cost has nevet
been a factor in the consideration since when you add a new feature or
change its really the developers doing the coding to determine feasablility
and cost as every draft proposed is new or change that is Depricates an old
RFC and there is always cost involved no matter how minor the change is but
just because there is cost involved does not mean you don't move forward
with the change or move forward with the change.

If what you are staying that the cost would out weight the benefit we would
have to truly do a cost benefit analysis on every draft that is approved
and I don't think the IETF had the man power to do so.

Of all the IETF WGs that I have been part of for many years cost had not
been the factor for that reason that determines wheathet the change is
approved or not.

The major factor is if the change  makes sense and if their is a problem or
gap or issue or problem or defect we are trying to solve and if we are able
to get consensus by the WG and chairs and ISG for approval.

Gyan

On Sun, Jun 9, 2019, 11:54 AM James R Cutler <[email-masked]>
wrote:

> 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.
>
> Where we part company is that the costs involved in changing away from 64
> bits is more wasteful than your proposal. The especially applies to time
> (labor) costs, both for new RFPs, design and prototyping, and deployment
> costs. It has take around two decades to get this far with IPv6. Adding yet
> another detour to this journey is not an improvement.
>
> James R. Cutler

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Jun 2019 01:34:17 -0400

6MAN chairs - Ole & Bob

I would like to volunteer in writing the draft to increase the prefix
length.  Please let me know if you agree with the basic content and premise
of what I have stated below so I can get started on the draft.

One of the technical justifications behind this MAJOR change in IPv6
addressing architecture RFC 4291 is that the current 64 bit iid is very
wasteful and that many bits should be reallocated for the prefix reducing
the size of the iid.

The only justification that did exist for the 64 bit iid but I don't think
is valid is with RFC 4941 SLAAC privacy extensions which given the issue
with network administrators being able to track malicious hosts now with
RFC4941 ends up protecting the end user with the pseudo random station id
but at the same time protects the attacker as well.  So in my opinion
network administrators and for that matter law inforcement has a critical
security requirement to track all addresses allocated and with address
changing makes that impossible to track thus creating an attack vector for
malicious activity.  Not good at all for IPv6 security.

RFC 7217  Semantically Opaque Interface Identifiers addresses this concern
by making the SLAAC address stable so it does not change when on the same
network and only changes when the host moves between networks.  This RFC
eliminates the major security hole created by RFC 4941 privacy extension
with the changing pseudo random iid.

The proposed iid size /82=48 bit iid  /96= 32 bit iid /112-16 bit iid would
use the RFC7217 Semantically Opaque Interface Identifiers  - random but
stable IPv6 address that does not change unless the prefix changes (Host
moves to a different network)

We have the option to increase on any nibble boundary  /64, /68, /72, /76,
/80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124.  I
propose in the draft that this is done on any of the three 16 bit
boundaries /82 /96 /112 to have a clear delineation between prefix & iid
and that we would make this backwards compatible and would be disabled by
default similar to the ipv6-only flag per OS vendor implementation and
enabled only through  RFC 5175 Reserved flag bit when the router sets the
flag it would be cached by the host similar to the other RFC 5175 flags.

  Current Router Advertisement Flags Currently, the NDP Router
Advertisement message contains the following one-bit flags defined in
published RFCs:
0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|R|R|
 +-+-+-+-+-+-+-+-+
Figure 1: Router Advertisement Flags
 o M - Managed Address Configuration Flag [RFC4861]
 o O - Other Configuration Flag [RFC4861]
 o H - Mobile IPv6 Home Agent Flag [RFC3775]
 o Prf - Router Selection Preferences [RFC4191]
 o P - Neighbor Discovery Proxy Flag [RFC4389]
 o R - Reserved - bit 6 - IPv6 only flag  - draft-ietf-6man-ipv6only-flag-05
 o R - Reserved - bit 7 - Prefix length flag ===========> New option = Gyan
draft

So if this bit is set then the /82 /96 /112 prefix advertised on the router
would get advertised down to the host in the RA advertisement below:
EUI64 - Default -
Router sets bit 7 - EUI48 format - /112 SLAAC prefix sent to host
Router sets bit 7 - EUI32 format - /96 SLAAC prefix sent to host
Router sets bit 7 - EUI16 format - /82 SLAAC prefix sent to host

No change to LL format which would be still default /64 EUI64 iid.

The IANA RIR's would not change what they are doing for now with the
standard allocations to Service Providers.

Service Providers would start advocating to customers to start using the
new IPv6 addressing format at a major cost savings which would push them to
migrate towards the new standard.
/48.

*How the new numbering schema stacks up as far ad space savings:  (Pretty
amazing when you look at the numbers below)*

/48 Default Customer allocation = 64k /64's = Default /64 EUI64 / Privacy
Ext = 64 bit ssid

/96 Default Customer allocation = 64k /112's  = Equivalent to the number
of  /64 subnets in a /48  ==========> Instead of  SP's allocating /48's to
customers  would be able to allocate /96 to customers
/82 Default Customer allocation = 64k /96's = Equivalent to the number of
/64 subnets in a /48 ==========> Instead of  SP's allocating /48's to
customers  would be able to allocate /82 to customers
/82 Default Customer allocation = 4.2 Billion  /112's =  SP allocation /32
4.2 billion /64 subnets  ==========> Instead of the RIR allocating /32's to
ISP's would be able to allocate /82's to ISP's

So this would be for the future for future SP's and Enterprises migrating
to IPv6 now have the option of getting smaller registered blocks.

Also existing SP's & Enterprises also have the opportunity to switch gears
and change to the new addressing schema to save on address space.

This would be a MAJOR game changer for IPv6 and really would ensure that
IoT and other devices as we proliferate dolling out /48's and /32s as if
the their is no end in sight given the massive size of the IPv6 space that
at least we know that we are not being wasteful in our addressing
architecture.

Thank you

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

On Sun, Jun 9, 2019 at 9:25 PM Gyan Mishra <[email-masked]> wrote:

> If what you are staying that the cost would out weight the benefit we
> would have to truly do a cost benefit analysis on every draft that is
> approved and I don't think the IETF had the man power to do so.
>
> The major factor is if the change  makes sense and if their is a problem
> or gap or issue or problem or defect we are trying to solve and if we are
> able to get consensus by the WG and chairs and ISG for approval.
>
> Gyan
>
>

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Jun 2019 01:41:37 -0400

Sorry my math was off on the bit offset for /82 should be /80

Router sets bit 7 - EUI16 format - /80 SLAAC prefix sent to host

/96 Default Customer allocation = 64k /112's  = Equivalent to the number
of  /64 subnets in a /48  ==========> Instead of  SP's allocating /48's to
customers  would be able to allocate /96 to customers
/80 Default Customer allocation = 64k /96's = Equivalent to the number of
/64 subnets in a /48 ==========> Instead of  SP's allocating /48's to
customers  would be able to allocate /82 to customers
/80 Default Customer allocation = 4.2 Billion  /112's =  SP allocation /32
4.2 billion /64 subnets  ==========> Instead of the RIR allocating /32's to
ISP's would be able to allocate /82's to ISP's

Thank you

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

On Mon, Jun 10, 2019 at 1:34 AM Gyan Mishra <[email-masked]> wrote:

> RFC 7217  Semantically Opaque Interface Identifiers addresses this
> concern by making the SLAAC address stable so it does not change when on
> the same network and only changes when the host moves between networks.
> This RFC eliminates the major security hole created by RFC 4941 privacy
> extension with the changing pseudo random iid.
>
> The proposed iid size /82=48 bit iid  /96= 32 bit iid /112-16 bit iid
> would use the RFC7217 Semantically Opaque Interface Identifiers  - random
> but stable IPv6 address that does not change unless the prefix changes
> (Host moves to a different network)
>
>  o R - Reserved - bit 7 - Prefix length flag ===========> New option =
> Gyan draft
>
> So if this bit is set then the /82 /96 /112 prefix advertised on the
> router would get advertised down to the host in the RA advertisement below:
> EUI64 - Default -
> /82 Default Customer allocation = 4.2 Billion  /112's =  SP allocation
> /32  4.2 billion /64 subnets  ==========> Instead of the RIR allocating
> /32's to ISP's would be able to allocate /82's to ISP's
>
>>> 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.
>>>
>>> Where we part company is that the costs involved in changing away from
>>> 64 bits is more wasteful than your proposal. The especially applies to time

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 10 Jun 2019 16:53:48 +0000

Two points I pulled out of the many points that were made were that 1) prefixes that are
overly long can be trivially enumerated by an attacker, and 2) prefixes should be aligned
on nibble boundaries.

I really resonate with point 1), and with Host Address Availability (RFC7934) we see that
it is good to allow hosts (nodes) to configure many IPv6 addresses - perhaps even very
many. I agree with the points that there are already vast numbers of /64s available for
delegation, and /64 has many nice properties including RFC7934 support and intractable
address enumeration. But, if we want to go longer than /64 and still satisfy those
properties, how long would that be - /96?

Point 2) I am not as sure on. Why is it important for prefixes to land on even nibble
boundaries? I can easily delegate a /63 today for example, and I don't see anything
wrong with that. Are we saying that that should be disallowed?

Fred

---

From: Yucel Guven <[email-masked]>
Date: Mon, 10 Jun 2019 20:17:05 +0200

About Point 2:
No, I think should not be disallowed. We should not restrict addresses to
be on the nibble boundaries.
(Might that 'mimic' the the classfull addresses of v4? Maybe)
One useful/practical reason of having prefixes on nibble boundaries is
that it makes easy entering/registering the DNS records,
e.g.  if you have /64 (or multiples of 4 -since a nibble has 4bits, in
general), then only one DNS record is needed,
if it's a non-nibble prefix, then more than one DNS entry should be
recorded, which will not be practical.

Reg.'s
Yucel

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Jun 2019 13:02:20 -0500

> wrong with that. Are we saying that that should be disallowed?

No, not disallowed, nibble alignment is not required, it is simply
recommended. Nibble alignment just makes it easier for humans to understand
and recognize the boundary. Making things easier for humans to recognize
makes it more likely they will catch their mistakes, and less likely they
will make mistakes.

Thanks.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jun 2019 10:32:28 +1000

On Tue., 11 Jun. 2019, 02:54 Templin (US), Fred L, <
[email-masked]> wrote:

> address enumeration. But, if we want to go longer than /64

Why do we want to go longer than /64?

The IPv6 address space is 2^96 times, or about 73 billion billion times
larger than IPv4s.

Plenty of people have done the maths to show that we are not going to run
out of IPv6 addresses.

Just a few months ago Brian worked out that every grain of sand on Earth
could have its own /64, and from memory, that was just within 2000::/3.

For a technical field, I'm becoming more and more amazed at how many people
trust their intuition completely ("IPv4 ran out in a few decades so IPv6
will too"), rather than saying to themselves, "my intuition may be correct,
do the facts support it?".

It's not engineering if people rely on intuition, because ever now and then
things are counter-intuitive.

and still satisfy those

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 11 Jun 2019 01:20:24 +0000

We’ve been around and around on this. Today’s reality is that households and devices are being provided, in many cases, with only a /64. Therefore, unless the households or devices are happy with a flat address space inside their /64, prefix, they would need to be assigned more /64 prefixes.

In many cases, I’d say universally actually, users prefer to architect their systems as they see fit, without having to involve new requests to their ISPs. IPv4 taught us to appreciate the flexibility of CIDR. IMO, I’d leave it wide open, the prefix length, and many RFCs not related to ULA, link local, or SLAAC already allow this. In fact, even SLAAC can easily be made to accommodate various prefix/IID lengths, if it should ever come to that.

(Sorry for top posting.)

Bert

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Monday, June 10, 2019 20:32
To: Templin (US), Fred L <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: IPv6 prefix lengths - how long?

On Tue., 11 Jun. 2019, 02:54 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:
Two points I pulled out of the many points that were made were that 1) prefixes that are
overly long can be trivially enumerated by an attacker, and 2) prefixes should be aligned
on nibble boundaries.

The IPv6 address space is 2^96 times, or about 73 billion billion times larger than IPv4s.

Plenty of people have done the maths to show that we are not going to run out of IPv6 addresses.

Just a few months ago Brian worked out that every grain of sand on Earth could have its own /64, and from memory, that was just within 2000::/3.

For a technical field, I'm becoming more and more amazed at how many people trust their intuition completely ("IPv4 ran out in a few decades so IPv6 will too"), rather than saying to themselves, "my intuition may be correct, do the facts support it?".

It's not engineering if people rely on intuition, because ever now and then things are counter-intuitive.

and still satisfy those

Fred
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jun 2019 14:01:44 +1000

On Tue, 11 Jun 2019 at 11:20, Manfredi (US), Albert E
<[email-masked]> wrote:
>
> We’ve been around and around on this. Today’s reality is that households and devices are being provided, in many cases, with only a /64.

It's 33%. Multiple /64s is 57% and the majority. 33% is "many" but not
the majority.

"With regards to what prefix is allocated for customers’ LANs, 22% of
the respondents indicated that they are using a /48, 35% indicated
they are using a /56, 33% a /64 and 10% other sizes (among them, a
/60, a /62, a /57, a /127 and a /128). "

https://blog.apnic.net/2016/11/14/ipv6-deployment-survey-results/

> Therefore, unless the households or devices are happy with a flat address space inside their /64, prefix, they would need to be assigned more /64 prefixes.
>

Customers are going to mostly be happy with a single /64, because most
residential customers have a single Wifi SSID that they plug
everything into. It provides a reliable and mostly error free "plug
in, switch on and it works" experience.

That doesn't mean I think it is okay for ISPs to only give a customer
a single /64. I advocate /48 for all customers for its simplicity - a
single size is much easier to manage and is either right or wrong in
all contexts.

We don't solve the problem of ISPs not giving out multiple /64s by
allowing them to continue to give customers a single /64 and then
allowing it to be further subdivided.

Doing so would be penalising those who've followed the multiple /64s
per site advice - the 57% above - and rewarding those that haven't.

Fundamentally, due to maths, we'd also be spending time solving a
problem that has no objective reason to exist in the first place.

>
>
> In many cases, I’d say universally actually, users prefer to architect their systems as they see fit,

I think you're projecting what you want and like to do onto the
majority of residential users. You're interested in technical things
and a network engineer. You'll enjoy spending your own time on
architecting your home network.

The majority of residential users aren't like you and I.

> without having to involve new requests to their ISPs. IPv4 taught us to appreciate the flexibility of CIDR. IMO, I’d leave it wide open, the prefix length, and many RFCs not related to ULA, link local, or SLAAC already allow this. In fact, even SLAAC can easily be made to accommodate various prefix/IID lengths, if it should ever come to that.
>
>
>
> (Sorry for top posting.)
>
>
>
> Bert
>
>
>
>
>
> On Tue., 11 Jun. 2019, 02:54 Templin (US), Fred L, <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jun 2019 21:51:37 -0700

> On Jun 10, 2019, at 6:20 PM, Manfredi (US), Albert E <[email-masked]> wrote:
> 

My understanding, from a number of ISP sources, is that the ISP gives the user what s/he asks for. In many cases, that is a /64.

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 11 Jun 2019 09:28:46 +0200

Fully agree, we don't need this document.

If we change the /64, then the ISPs will start allocating to customers not just a single /64, but /120 or whatever.

Regards,
Jordi
@jordipalet

El 11/6/19 6:02, "ipv6 en nombre de Mark Smith" <[email-masked] en nombre de [email-masked]> escribió:

    

    

    

    

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 11 Jun 2019 09:32:53 +0200

Hi Fred,

El 11/6/19 6:52, "ipv6 en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    

-> My experience is on the other way around. Most of the time ISPs have either:
1) A default prefix assignment size for customers, and they not allow to change it.
2) A default prefix assignment size for customers, and they allow to change it to another size, for a cost (for example from /56 to /48).
3) A different prefix assignment size depending on if you're a residential or business customers. If you want to change, even if the "link" is the same, you pay a very different price (example around 40 Euros in Spain for residential customers, while it is 200 Euros for a business customer, in both cases a 100/100 Mbit GPON).

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:05:34 +0200

> at some point the /64 boundary is relaxed) the longest IPv6 prefix 

I think the answer to the question 'how many' is related to the L2 
technology.

On WiFi we know it is about 100 or less laptops attached to an Access 
Point.  Some APs limit that to 4.  Some wifi chips in tethering 
smartphones also have a specified limit.

Alex

> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:18:25 +0200

Le 10/06/2019 à 07:34, Gyan Mishra a écrit :
> length. 

If you write one, I would like to help.

Alex

  Please let me know if you agree with the basic content and
> premise of what I have stated below so I can get started on the draft.
> 
> wasteful and that many bits should be reallocated for the prefix 
> reducing the size of the iid.
> 
> The only justification that did exist for the 64 bit iid but I don't 
> think is valid is with RFC 4941 SLAAC privacy extensions which given the 
> issue with network administrators being able to track malicious hosts 
> now with RFC4941 ends up protecting the end user with the pseudo random 
> station id but at the same time protects the attacker as well.  So in my 
> opinion network administrators and for that matter law inforcement has a 
> critical security requirement to track all addresses allocated and with 
> address changing makes that impossible to track thus creating an attack 
> vector for malicious activity.  Not good at all for IPv6 security.
> 
> would use the RFC7217 Semantically Opaque Interface Identifiers  - 
> random but stable IPv6 address that does not change unless the prefix 
> changes (Host moves to a different network)
> 
> We have the option to increase on any nibble boundary  /64, /68, /72, 
> /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124.  
> I propose in the draft that this is done on any of the three 16 bit 
> boundaries /82 /96 /112 to have a clear delineation between prefix & 
> iid  and that we would make this backwards compatible and would be 
> disabled by default similar to the ipv6-only flag per OS vendor 
> implementation and enabled only through  RFC 5175 Reserved flag bit when 
> the router sets the flag it would be cached by the host similar to the 
> other RFC 5175 flags.
> 
> new IPv6 addressing format at a major cost savings which would push them 
> to migrate towards the new standard.
> /48.
> 
> *How the new numbering schema stacks up as far ad space savings:  
> (Pretty amazing when you look at the numbers below)*
> 
> /48 Default Customer allocation = 64k /64's = Default /64 EUI64 / 
> Privacy Ext = 64 bit ssid
> 
> of  /64 subnets in a /48  ==========> Instead of  SP's allocating /48's 
> to customers  would be able to allocate /96 to customers
> /82 Default Customer allocation = 64k /96's = Equivalent to the number 
> of  /64 subnets in a /48 ==========> Instead of  SP's allocating /48's 
> to customers  would be able to allocate /82 to customers
> So this would be for the future for future SP's and Enterprises 
> migrating to IPv6 now have the option of getting smaller registered blocks.
> 
> Also existing SP's & Enterprises also have the opportunity to switch 
> gears and change to the new addressing schema to save on address space.
> 
> the their is no end in sight given the massive size of the IPv6 space 
> that at least we know that we are not being wasteful in our addressing 
> architecture.
> 
> 
> Thank you
> 
> Gyan S. Mishra
> 
> Email: [email-masked] <mailto:[email-masked]>
> 
> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> 
> 
> 
> 
> On Sun, Jun 9, 2019 at 9:25 PM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     However I would like to state that there have been many tweaks to
>     RFCs written  across the board across all IETF workgroups and cost
>     has nevet been a factor in the consideration since when you add a
>     new feature or change its really the developers doing the coding to
>     determine feasablility and cost as every draft proposed is new or
>     change that is Depricates an old RFC and there is always cost
>     involved no matter how minor the change is but just because there is
>     cost involved does not mean you don't move forward with the change
>     or move forward with the change.
> 
>     If what you are staying that the cost would out weight the benefit
>     we would have to truly do a cost benefit analysis on every draft
>     that is approved and I don't think the IETF had the man power to do so.
> 
>     Of all the IETF WGs that I have been part of for many years cost had
>     not been the factor for that reason that determines wheathet the
>     change is approved or not.
> 
>     The major factor is if the change  makes sense and if their is a
>     problem or gap or issue or problem or defect we are trying to solve
>     and if we are able to get consensus by the WG and chairs and ISG for
>     approval.
> 
>     Gyan
> 
> 
>     On Sun, Jun 9, 2019, 11:54 AM James R Cutler
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>>         On Jun 9, 2019, at 10:07 AM, Gyan Mishra
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         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.
>>
>         Where we part company is that the costs involved in changing
>         away from 64 bits is more wasteful than your proposal. The
>         especially applies to time (labor) costs, both for new RFPs,
>         design and prototyping, and deployment costs. It has take around
>         two decades to get this far with IPv6. Adding yet another detour
>         to this journey is not an improvement.
> 
>         James R. Cutler
>         [email-masked] <mailto:[email-masked]>
> Email: [email-masked] <mailto:[email-masked]>
> 
> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> 
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 16 Jun 2019 02:20:55 -0400

Alex

I will add you to the authors.

6MAN,

I have had a few requests for authors to help write the draft.  Please
reply to this thread if you are interested in authoring the draft.

I reviewed the merits of the draft to increase the prefix length with Ole &
Bob.

So as to the "how" to make this change the idea of how to make this work is
feasible and can be done by using one of the  RFC 5175 reserved flags.
This would have to be 100% backwards compatible to any existing deployments
so  they are not impacted by this change.

The variable prefix size would use the RFC7217 Semantically Opaque
Interface Identifiers  - random but stable IPv6 address that does not
change unless the prefix changes (Host moves to a different network)

We have the option to increase on any nibble boundary  /64, /68, /72, /76,
/80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124 so I am
proposing that we would make this variable and backwards compatible to any
host that does not support the new flag or existing deployments so they do
not have to change.

So basically the router would send the RA ICMPv6 type 134 with this flag
set and the host would see the flag and interpret that to allow any range
of prefix sizes sent by the router to the host for the SLAAC prefix.  We
can limit which nibbles would be acceptable or make them all work.  As the
draft is composed we can dig into that further and how much granularity we
want and how large do we want to go with the prefix and how small on the
iid.

As for the problem statement and Why ??? to make this change is really the
most complex part of the draft that having valid concrete justification to
make this change as "wasteful" is not a sound reason as the size of the
just the current global uni space  2001::/3 not including the reserved
prefixes is so tremendous enough to address the universe a good analogy on
size is IPv4 is to the earth as IPv6 is to the universe.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

One idea I thought of is related to enterprise scenario with corporate
intranets and the ability to do port scans on 64 bit iid with random iid
heuristic which I agree the privacy extension of random iid is critical for
any device directly connected to the internet but if you are within your
own corporate intranet do you really need the 64 bit iid and why not give
bits back to the prefix for that scenario.  There are ways to get around
the scan question but in general the issue becomes moreso with large
corporations where small & medium in general may have one IT team that
handles IT security, desktop and network where large corporations they are
completely separate organizations and so the IT security & desktop
organizations do not have access to the routers to access the IPv6 ND cache
to see active devices on the network.  A workaround is ping ff02::1 all
hosts to discover all hosts and that does work and could be modified to do
port scans.  There maybe other ways to get around the scan issue.

I would like to poll 6MAN as to other ideas on the Why?? to make this
change.

Thank you

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 16 Jun 2019 02:45:21 -0400

Microsoft does support stateful which does support longer prefixes as well as supports static longer prefixes however Android mobile devices and Chromebooks only support SLAAC and no roadmap or plane to ever support stateful.

So there maybe cases where the enterprises want to stay stateless but want longer prefixes for internal usage and consumption which is the gap that is not supported today that we would address with this draft.

Gyan

Sent from my iPhone

> On Jun 16, 2019, at 2:20 AM, Gyan Mishra <[email-masked]> wrote:
> 
> Alex
> 
> I have had a few requests for authors to help write the draft.  Please reply to this thread if you are interested in authoring the draft.
> 
> I reviewed the merits of the draft to increase the prefix length with Ole & Bob.
> 
> So as to the "how" to make this change the idea of how to make this work is feasible and can be done by using one of the  RFC 5175 reserved flags.  This would have to be 100% backwards compatible to any existing deployments so  they are not impacted by this change. 
> 
> RFC 7217  Semantically Opaque Interface Identifiers addresses this concern by making the SLAAC address stable so it does not change when on the same network and only changes when the host moves between networks.  This RFC eliminates the major security hole created by RFC 4941 privacy extension with the changing pseudo random iid.
> 
> The variable prefix size would use the RFC7217 Semantically Opaque Interface Identifiers  - random but stable IPv6 address that does not change unless the prefix changes (Host moves to a different network)
> 
> We have the option to increase on any nibble boundary  /64, /68, /72, /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124 so I am proposing that we would make this variable and backwards compatible to any host that does not support the new flag or existing deployments so they do not have to change.
> 
> So basically the router would send the RA ICMPv6 type 134 with this flag set and the host would see the flag and interpret that to allow any range of prefix sizes sent by the router to the host for the SLAAC prefix.  We can limit which nibbles would be acceptable or make them all work.  As the draft is composed we can dig into that further and how much granularity we want and how large do we want to go with the prefix and how small on the iid.
> 
>   Current Router Advertisement Flags Currently, the NDP Router Advertisement message contains the following one-bit flags defined in published RFCs: 
> 0 1 2 3 4 5 6 7 
>  +-+-+-+-+-+-+-+-+ 
> |M|O|H|Prf|P|R|R| 
>  +-+-+-+-+-+-+-+-+   
>  o R - Reserved - bit 7 - Prefix length flag ===========> New option = Gyan draft
> 
> As for the problem statement and Why ??? to make this change is really the most complex part of the draft that having valid concrete justification to make this change as "wasteful" is not a sound reason as the size of the just the current global uni space  2001::/3 not including the reserved prefixes is so tremendous enough to address the universe a good analogy on size is IPv4 is to the earth as IPv6 is to the universe.  
> 
> One idea I thought of is related to enterprise scenario with corporate intranets and the ability to do port scans on 64 bit iid with random iid heuristic which I agree the privacy extension of random iid is critical for any device directly connected to the internet but if you are within your own corporate intranet do you really need the 64 bit iid and why not give bits back to the prefix for that scenario.  There are ways to get around the scan question but in general the issue becomes moreso with large corporations where small & medium in general may have one IT team that handles IT security, desktop and network where large corporations they are completely separate organizations and so the IT security & desktop organizations do not have access to the routers to access the IPv6 ND cache to see active devices on the network.  A workaround is ping ff02::1 all hosts to discover all hosts and that does work and could be modified to do port scans.  There maybe other ways to get around the scan issue.
> 
> I would like to poll 6MAN as to other ideas on the Why?? to make this change.
> 
> Thank you
> 
> Gyan S. Mishra
>> On Sat, Jun 15, 2019 at 11:18 AM Alexandre Petrescu <[email-masked]> wrote:
>> 
>>

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jun 2019 01:14:58 +1000

The thing this reminds me of something that my Father taught me, which is
also well known.

"Just because you can do something doesn't mean you should."

On Sun., 16 Jun. 2019, 16:21 Gyan Mishra, <[email-masked]> wrote:

> So as to the "how" to make this change the idea of how to make this work
> is feasible and can be done by using one of the  RFC 5175 reserved flags.
> [email-masked] <alexandre.petrescu@gmail..com>> wrote:
>
>>
>>
>> > vector for malicious activity.  Not good at all for IPv6 security..
>> >
>> > the same network and only changes when the host moves between
>> networks..
>> > /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120,
>> /124..
>> > gears and change to the new addressing schema to save on address space..
>> >
>> >         two decades to get this far with IPv6.. Adding yet another
>> detour
>> >         to this journey is not an improvement..
>> >
>> >         James R. Cutler
>> >         [email-masked] <mailto:[email-masked]
>> >