Re: IPv6 prefix lengths

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" <ipv6-bounces@ietf.org en nombre de markzzzsmith@gmail.com> escribió:

    On Tue, 11 Jun 2019 at 11:20, Manfredi (US), Albert E
    <albert.e.manfredi@boeing.com> 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
    >
    >
    >
    >
    >
    > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mark Smith
    > Sent: Monday, June 10, 2019 20:32
    > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
    > Cc: 6man WG <ipv6@ietf.org>
    > Subject: Re: IPv6 prefix lengths - how long?
    >
    >
    >
    >
    >
    > On Tue., 11 Jun. 2019, 02:54 Templin (US), Fred L, <Fred.L.Templin@boeing.com> 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.
    >
    > 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
    >
    >
    >
    >
    >
    > 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
    > 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
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

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