Re: [v6ops] Chair decision on WGLC for draft-ietf-v6ops-dhcp-pd-per-device-04

[Nick Buraglio <[e-mail]>]

I know a lot of this discussion has been about the prefix length detail,
and while I am personally of the opinion that a /64 is reasonable, my
opinion is based on what is available, required to be supportable across
all platforms, and most importantly operationally viable in a way that can
be deployed and handed off to operations *today*.
That said, Jeremy Duncan (on the list; one of the co-authors of the 6724
update) and myself have been working on a large conference IPv6-mostly
wireless deployment and during the initial testing, we found some odd
issues that the solution provided here would have largely solved had there
been client support. We were able to work around the issue, but had this
been an available option, I suspect we would have never even seen the issue
(and had less go-around with security about device tracking).

There are real-world problems - especially at scale - that this solves, not
the least of which is neighbor scale and discovery throttling. I don't
*think* that anyone disagrees with that part, but instead have issues with
the prefix length. Given the ubiquitous nature of slaac, I see why it is
written the way it is.

Section 8 reads:






*At the time of writing the only prefix size that will allow devices   to
use SLAAC is 64 bits (see also [RFC7421]).  Choosing longer   prefixes
would require the client and any connected system to use   some other form
of address assignment, which many hosts do not   support, and therefore
limits the applicability of the proposed   solution.*

Limits, but does not preclude. If someone were to code their own solution,
this could be completely applicable. Out of the box, however, there exists
a significant impediment to deploying this operationally. Perhaps extremely
large organizations may have the developers to make it happen, but 99% do
not, and desire an out of the box solution, which is what I read this to
be.




*   For the same reasons, a prefix length of /64 or shorter is required
 to extend the network using [RFC7084] (see requirement L-2), and a
 prefix length of /64 is required to provide global connectivity for   stub
networks as per [I-D.ietf-snac-simple].*

Other examples of similar requirements. to me, this is a "solve a problem
we have right now, with current technology, and referencing current
standards requirements"  as stated in "*At the time of writing..."*



nb


On Wed, Nov 1, 2023 at 8:58 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi Owen,
>
> > So, in fact, the point of having 128 bit addresses (at least in the
> initial engineering of same) was, in fact, to use the lower 64 bits as IID
> and leave the upper 64 bits for locator/network ID.
>
> Not quite. The original expectation was to leave the upper 80 bits for
> routing and have a 48 bit IID. We only moved from /80 to /64 because we
> were effectively copying the XNS/Netware model and there was a theory that
> 64-bit Firewire MAC addresses would take over the universe.
>
> draft-odell-8+8-00.txt (October 1996) did propose a rigid /64 boundary.
>
> Regards
>     Brian Carpenter
>
> On 02-Nov-23 10:44, Delong.com wrote:
> >
> >
> >> On Nov 1, 2023, at 12:05, Lorenzo Colitti <lorenzo=
> [e-mail]> wrote:
> >>
> >> On Wed, Nov 1, 2023 at 5:28 PM Gert Doering <[e-mail] <mailto:
> [e-mail]>> wrote:
> >>
> >>     The point of having 128 bit is not to throw half of it away.
> >>
> >>
> >> Maybe we should start working on running SLAAC on IIDs shorter than 64
> bits then?
> >
> > Or maybe not…
> >
> > ISTR that the early discussion was for a 64-bit address space up to the
> point where someone pointed out the utility of 64-bit IIDs in an EUI-64
> world (which was, at the time, expected for future IEEE802 work and had
> > already hit a couple of media types such as FDDI (yes, FDDI meant
> something back then)).
> >
> > So, in fact, the point of having 128 bit addresses (at least in the
> initial engineering of same) was, in fact, to use the lower 64 bits as IID
> and leave the upper 64 bits for locator/network ID.
>
> Not quite. The original expectation was to leave the upper 80 bits for
> routing and have a 48 bit IID. We only moved from /80 to /64 because we
> were effectively copying the XNS/Netware model and there was a theory that
> 64-bit Firewire MAC addresses would take over the universe.
>
> draft-odell-8+8-00.txt (October 1996) did propose a rigid /64 boundary.
>
> > I’m sure opinions vary on this today, but is there a genuine belief that
> we need more than 2 quintillion subnets? (An admittedly rough approximation
> of 2^61 which is the number of /64s available in 2000::/3).
>
> No. The argument is different: route aggregation must be possible at all
> levels.
>
> > Unless there’s some compelling reason that’s necessary, I remain
> unconvinced that killing the /64 concept is such a good idea.
>
> That isn't the goal. The goal is to ensure that *architecturally* all our
> specifications allow for route aggregation at all levels; /64 is just a
> setting. And as we know, mobile operators have turned /64 into an axiom,
> which is quite wrong architecturally. But its direct consequence is that we
> *will* need longer prefixes downstream from this /64 bottleneck. Or
> NPTv6/NAT66.
>
> draft-bourbaki-6man-classless-ipv6 says more.
>
> (The authors of rfc6296-bis might consider whether NPTv6 will also work
> for prefixes as long as /80. I think so, there is still space for the
> checksum-neutral computation.)
>
>     Brian
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>