Re: For whom is IPv6? [was: Happy St Nicholas Day: Re-Launching the IPv6 ULA registry]

[David Farmer <[e-mail]>]

On Sun, Dec 13, 2020 at 22:46 Brian E Carpenter <[e-mail]>
wrote:

> On 14-Dec-20 16:13, David Farmer wrote:
> >
> >
> > On Sun, Dec 13, 2020 at 18:20 Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Let's stipulate that this is true:
> >
> >     > This is a case where a ULA-C allocation per-customer would make
> sense, if
> >     > it could be done for a non-recurring fee.
> >
> >     I see a challenge there. As sixxs and other examples have showed us,
> a
> >     pro bono service will not live for ever. How can a ULA-C registry,
> even a
> >     strictly non-profit one, live for ever if there is no annual fee?
> >
> >
> > Not to mention that an annual fee and termination for the lack of
> payment is an extremely efficient mechanism for maintaining the accuracy of
> the registry over long periods of time.  Without it or a similar periodic
> mechanism for garbage collection, information in the registry will rot over
> time and we will just rebuild the swamp.
>
> But does that matter? The only property requested is uniqueness. These
> prefixes would never be in the mythical DFZ anyway, unless I've greatly
> misunderstood the use case.


For several reasons registry accuracy is still important;

1. Someone mention leakage to the DFZ, accurate operational contact
information allows for notice of this situation.

2. The registry itself needs operational contact information for services
like reverse DNS and RPKI. I thought services were requested in addition to
uniqueness.

3. While not intended to be part of the DFZ, that doesn’t mean there is no
intent to coordinate with other networks. The registry is an effective
mechanism for this coordination, inaccurate information hinders this
coordination.

4. A large number of unused entries will distort any evaluation of the
usefulness of ULA-C, and could raise operational costs especially over
time.  Even if this is funded by an external agency, they will want to know
their money is being spent effectively and know the impact they are having.

Furthermore, nothing lasts forever, someday we will have to evaluate the
effectiveness of this and decide if it should continue, even if that is 20
or 30 years from now. A lot of cruft can build up in that kind of
timeframe, if it is not managed well from the beginning.

Don’t discount what it will take to turn the dials off of zero for
coordination and services for ULA. Also, IANA doesn’t serve the general
public, don’t discount how this would change the nature of IANA and what it
would take to accomplish it.

Thanks

    Brian
>
> > Furthermore, making that mechanism an annual fee nicely aligns with the
> need to fund the registry.
> >
> > So, if there isn’t an annual fee, not only do you need a different
> funding mechanism but a different garbage collection mechanism too. While
> not impossible, this seems like a very tall order to me.
> >
> > Thanks
> >
> >     Regards
> >        Brian
> >
> >     On 14-Dec-20 11:22, Michael Richardson wrote:
> >     >
> >     > Brian E Carpenter <[e-mail] <mailto:
> [e-mail]>> wrote:
> >     >     > Right, that's an entirely different situation and I hope it
> will be a
> >     >     > frequent one. We have several /3s spare. Should we dedicate
> a /3 to
> >     >     > that class of usage, and figure out (with IANA and the RIRs)
> how to
> >     >     > make such prefixes available for admin cost only, or even
> self-service
> >     >     > free of charge along the lines Nico suggested?
> >     >
> >     >     > (Because I'm thinking that for the full power of such mesh
> networking
> >     >     > to be available, ULA-C would not be enough.)
> >     >
> >     > Gosh, that would really be a good problem to have, wouldn't it?
> >     > That's 2^40  /48s, right?
> >     > 1,099,511,627,776, approximately 100 /48s per human.
> >     >
> >     > I don't think we need to dedicate a /3 to this problem.
> >     > It would, as David Farmer said, be dumb to replicate the
> >     > RIPE/ARIN/etc. databases and whois systems, and the like just for
> this.
> >     > David points out that Community Network allocation (a /40) is
> available
> >     > for $250/year from ARIN.
> >     >
> >     > That's still a bit painful and the definition is a bit unclear.
> >     >
> >     > here is an industrial/IT case that I know of:
> >     > The backplane of an IXIA testing chassis uses IPv4, 11.0.0.0/8 <
> http://11.0.0.0/8>.
> >     > It could use ULA, but:
> >     > a) it sometimes leaks packets and confuses people, especially IT.
> >     >    (They need whois to diagnose what is happening.
> >     >    11.0.0.0/8 <http://11.0.0.0/8> also confuses them.... WTF is
> DNIC doing inside our firewall?)
> >     > b) sometimes you want to link the chassis together across labs or
> even VPNs.
> >     >
> >     > This is a case where a ULA-C allocation per-customer would make
> sense, if
> >     > it could be done for a non-recurring fee.
> >     >
> >     > --
> >     > Michael Richardson <[e-mail] <mailto:
> [e-mail]>>   . o O ( IPv6 IøT consulting )
> >     >            Sandelman Software Works Inc, Ottawa and Worldwide
> >     >
> >     >
> >     >
> >     >
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     --------------------------------------------------------------------
> >
> > --
> > ===============================================
> > David Farmer               Email:[e-mail] <mailto:
> [e-mail]>
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE        Phone: [phone]
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
>
> --
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================