[Int-area] Re: questions about draft-thain-ipv8-02

[Tom Beecher <[e-mail]>]

>
> Ipv6 i recall was maybe was 1996.


https://datatracker.ietf.org/doc/rfc2460/
https://datatracker.ietf.org/doc/rfc8200/

The original draft of 2460 is from 1997. The adopted standard of 8200 was
in active work through 2017.

If the IETF doesn't want SKEs to participate they should say so.


I'm not familiar with SKE as a TLA. If you are implying anyone is telling
you that you cannot participate , that's not what is happening. But you may
want to read rfc2026 that describes the pathway from Internet-Draft to
Standard.

And while you don't have to -- you might want to ask -- why are the numbers
> of penetration in corp so low.


There are a lot of answers to this question. There are 20 years of
conversations, debates, arguments, conference presentations, etc., on the
subject of IPv6 deployment/penetration.


On Tue, Apr 28, 2026 at 2:06 PM Jamie Thain <[e-mail]> wrote:

> Tom
>
> Smartphones arrived on scene with the iphone. Around 2007.
>
> Ipv6 i recall was maybe was 1996.
>
> My point is the Internet is not well served by a flat network.
>
> The cloud about 201x something.
>
> If the IETF doesn't want SKEs to participate they should say so.
>
> Only ipv6 efforts allowed here.
>
> And while you don't have to -- you might want to ask -- why are the
> numbers of penetration in corp so low.
>
> Answer ?
>
> Jamie
>
> On Tue., Apr. 28, 2026, 2:20 p.m. Tom Beecher, <[e-mail]> wrote:
>
>> As it stands now, the work by the LISPers doesn't solve the problems of
>>> corporate/enterprise networks. The history is fascinating, but when IPv6
>>> was invented, working methods were entirely different.
>>>
>>> There were very few cell phones, for the most part, they didn't have IP
>>> addresses, and the world was one flat enterprise. Now we are stuck between
>>> the corporate IPv4 world and the SuperScalars IPv6 world. Both protocols
>>> require a hierarchical access system.
>>>
>>
>> Most of this is factually incorrect. Smartphones with internet
>> connectivity were quite ubiquitous for many years during IPv6 standards
>> development.
>>
>> There was no cloud. Now we need an easy way to identify, separate and
>>> manage them.
>>
>>
>> The challenges you describe can either be solved using the existing IP
>> versions , or are those that IP isn't even the correct place to solve them.
>>
>> And since i've built hundreds of networks. I should know the gaps.
>>
>>
>> "I know better" is unlikely to be a persuasive argument to move your
>> ideas forward. Good luck to you.
>>
>> On Tue, Apr 28, 2026 at 11:38 AM Jamie Thain <[e-mail]> wrote:
>>
>>> Tom,
>>>
>>> As it stands now, the work by the LISPers doesn't solve the problems of
>>> corporate/enterprise networks. The history is fascinating, but when IPv6
>>> was invented, working methods were entirely different.
>>>
>>> There were very few cell phones, for the most part, they didn't have IP
>>> addresses, and the world was one flat enterprise. Now we are stuck between
>>> the corporate IPv4 world and the SuperScalars IPv6 world. Both protocols
>>> require a hierarchical access system.
>>>
>>> There was no cloud. Now we need an easy way to identify, separate and
>>> manage them. And since i've built hundreds of networks. I should know the
>>> gaps.
>>>
>>> So thanks for understanding the issue and the solution.
>>>
>>> Jamie
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 28, 2026 at 11:32 AM Tom Beecher <[e-mail]> wrote:
>>>
>>>> Jamie-
>>>>
>>>> I created it to solve the many problems that neither IPv6 nor IPv4
>>>>> solves. And I believe, and was actually quite surprised that my document
>>>>> gathered any more attention beyond a brief mention, because it addresses
>>>>> these long-standing problems.  Naive I believed that the standards body
>>>>> would see that the 50 year old protocol, and the 30 year old protocol were
>>>>> not built for modern corporate environments or the cloud, and would embrace
>>>>> the need for an upgrade.
>>>>
>>>>
>>>> I would counter that submitting a 30 page document for a new internet
>>>> protocol version without understanding the development history and design
>>>> decisions of previous versions in use is exceptionally naive.
>>>>
>>>>
>>>> On Tue, Apr 28, 2026 at 9:25 AM Jamie Thain <[e-mail]> wrote:
>>>>
>>>>> Daniel,
>>>>>
>>>>> Thank-you for your insight. I didn't create IPv8 to displace IPv6. I
>>>>> created it to solve the many problems that neither IPv6 nor IPv4 solves.
>>>>> And I believe, and was actually quite surprised that my document gathered
>>>>> any more attention beyond a brief mention, because it addresses these
>>>>> long-standing problems.  Naive I believed that the standards body would see
>>>>> that the 50 year old protocol, and the 30 year old protocol were not built
>>>>> for modern corporate environments or the cloud, and would embrace the need
>>>>> for an upgrade.
>>>>>
>>>>> 1. Hence the Zone Server, a central dual homed, configuration and
>>>>> network management server. VLAN, Device or ID based.
>>>>> 2. The idea of area-codes + internet address so the internet becomes
>>>>> hierarchical rather than flat, and adds meaning.
>>>>> 3. An internal routing number of 127.x.x.x -- because RFC 1918 is not
>>>>> enough.
>>>>>
>>>>> IPv8 == ASN + IPv4     IPv8 ≠ 64 bit address.
>>>>>
>>>>> Two giant companies merge, in IPv8 they both assign themselves two
>>>>> private ASNs, say 127.100.100.100 and 127.200.200.200 and they know the
>>>>> source and destination of every one of the now 4B internal IPs they need.
>>>>> I've been through 10.x.x.x mergers when I worked at a company that made 5
>>>>> major acquisitions in 10 months.
>>>>>
>>>>> 4. That the ASNs only need a few routes to the ASNs rather than dozens
>>>>> of /24 - /16s advertised per ASN. Just advertise the ASN. In summary,
>>>>> instead of being 1.2 Million entries and climbing, each large ASN would
>>>>> generally have 8 routes, and smaller ones 2 compressing the table to about
>>>>> 350k entries.
>>>>>
>>>>> So the malarkey actually is a solution to several problems that need
>>>>> addressing in the corporate world. Identity, Management, Built-in logging,
>>>>> isolation, cloud network management, VPCs, and VPNs all needed attention.
>>>>> And a few in the internet world: route sprawl and RADIUS/Diameter
>>>>> solutions.
>>>>>
>>>>> All the best,
>>>>>
>>>>> Jamie
>>>>>
>>>>>
>>>>> On Tue, Apr 28, 2026 at 9:23 AM Daniel McLarty <daniel=
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> My opinion is that all this IPv8 malarkey that has been pining
>>>>>> everyone on this list all month is just some vibedrafted idea that serves
>>>>>> no utility. IPv6 exists and is already (finally) getting adoption.
>>>>>>
>>>>>> I would not be shocked if in a month or two one of the AI companies
>>>>>> comes out and says 'Our AI made an internet draft! Look at how smart we
>>>>>> are.' At least that is my opinion on IPv8.
>>>>>>
>>>>>> Frankly, can we please just ignore this like we do with the 10,000
>>>>>> other bad drafts submitted every year? I’m genuinely confused why this one
>>>>>> managed to capture so much attention when it doesn't even survive a basic
>>>>>> sanity check of the OSI model.
>>>>>>
>>>>>> On 4/27/26 9:23 PM, Shizhang Bi wrote:
>>>>>>
>>>>>> may someone(s) in this group shed light. thanks.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Hi Mr. Thain,
>>>>>> two questions for you around ipv8 (the v2 draft to be precise),
>>>>>> excuse me if they are stupid:
>>>>>> 1. since the ASN occupies the first 32 bits in ipv8 address, why "The
>>>>>> minimum injectable prefix at inter-AS boundaries is /16"?
>>>>>> 2. why DNS record for ipv8 (64 bits) is not named as "AA" given ipv4
>>>>>> (32 bits) is "A" and ipv6 "AAAA" (128 bits)? A8 for me (and many people as
>>>>>> well i believe) means "AAAAAAAA" ...
>>>>>>
>>>>>> thanks for your time.
>>>>>> regards,
>>>>>> bi
>>>>>>
>>>>>> _______________________________________________
>>>>>> Int-area mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Int-area mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>> _______________________________________________
>>>>> Int-area mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>