Re: Market forces

On Tue, 10 Nov 2020, 10:12 Kerry Lynn, <kerlyn@ieee.org> wrote:

> On Mon, Nov 9, 2020 at 4:29 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>>
>> On Mon, Nov 9, 2020 at 3:22 PM Ted Lemon <mellon@fugue.com> wrote:
>>
>>> On Nov 9, 2020, at 2:47 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>>>
>>> I think the current and existing need that wouldn't be being satisfied
>>> with a single /64 are things like a guest WIFI SSID in the home, or perhaps
>>> a kids SSID where Internet access policy can be applied.
>>>
>>>
>>> That’s true, but the same caveat applies: right now, the ISP is giving
>>> the customer an IPv4 address, and so they can just do NAT. If IPv6 doesn’t
>>> work because they gave out a /64, right now they feel no pain. Later on,
>>> when they are trying to economize on IPv4 support, the pain will become
>>> more apparent, and then it’ll seem obvious and cheap to start giving out
>>> narrower PDs.
>>>
>>
>>    Or if the IID 64 bit boundary is eliminated the /64 would be
>> sufficient and could be sub divided.  Now there is not any dependency on PD
>> and even today broadband operators are still giving out /64 and not /56 or
>> larger.  Without going down the painful NAT ULA path it makes sense to
>> easily solve the single /64 allocation issue which exists for 3GPP PDP but
>> also exists for wired broadband only getting a /64 via PD.  Now they wont
>> have to wait for providers to make a change as they can now can
>> autonomously do their own segmentation.
>>
>
> So, dumb question, but would it make sense to consider some local
> coordination
> mechanism that assigns "subnet" meaning to the most significant bits of
> the IIDs
> on a link? RFC 7136 basically says that IIDs have no structure, RFC 8065
> says
> we'd like to have at least 46 bits of entropy for IIDs used in global
> addresses and
> ideally ~59. Other RFCs have defined privacy IIDs, etc. RFC 6282 allows for
> compression of arbitrary prefixes; no /64 architectural constraint there.
>

Question is, what does all that effort and cost save when the literal
minimum ISPs and carriers get from an RIR is 4 billion /64s or a /32.

The IETF, implementors and operators would spend millions of dollars in
terms of time and effort to make these changes.

Handing out a single /64 instead of many is saving so little cost that the
ISP or carrier would save more money by spending time finding lost ball
point pens.

(If I recall a calculation I did a few years ago correctly, each /48 costs
$0.03 per year from APNIC in the first year (i.e. including new member
fees) from the most expensive minimum of a /32. Cheaper after that. That's
more than 10 times cheaper than buying one postage stamp per customer per
year.)

Regards,
Mark.

> Kerry
>
>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>