This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/members-discuss@ripe.net/
[members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Previous message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Next message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Sun Apr 26 11:09:30 CEST 2020
Hi,
On Sun, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote:
> I think it is appropriate to close this discussion here.
> Elad will eventually submit his proposed al RIPE meeting or he'll write a
> RFC.
Basically, this.
The Internet (and the address distribution towards IANA and the RIRs) 
operates based on IETF standards, and as long as there is no IETF 
standard for IPv4+, it cannot be implemented in an interoperable way,
and can not be deployed.
Elad, this is your avenue: you need to demonstrate two working and
interoperating implementations for two host stacks and two router stacks.
Just claming "it is easy" is not sufficient.
I'm with Christian here: this can not work without significant changes
to the BSD socket API, to applications using this API - basically, everything
on Unix/Linux - to the Windows networking API, and to routers in the ISP
networks that need to decide "which customer is this packet sent to?" based 
on the extra bit.   And I speak with a certain background on implementing
network applications, running an ISP network, and debugging TCP/IP stacks.
Overall, as long as no implementations can be provided (source code on
github etc) this sounds like a somewhat cheap shot to make people believe 
you're going to solve their IPv4 problems if they just vote you to the 
NCC executive board.  And I hope the NCC members are smart enough to not 
vote based on glorious promises, but on track record, provable background, 
etc.
Gert Doering
        -- RIPE member
-- 
have you enabled IPv6 on something today...?
SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/698e891c/attachment.sig>
- Previous message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Next message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]