ANNOUNCE: Enhanced IP v1.4

ANNOUNCE: Enhanced IP v1.4

[Sam Patton]

Hello!

If you do not know what Enhanced IP is, read this post on netdev first:

https://www.spinics.net/lists/netdev/msg327242.html


The Enhanced IP project presents:

             Enhanced IP v1.4

The Enhanced IP (EnIP) code has been updated.  It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.

Interested in seeing Enhanced IP in the Linux kernel, read on.  Not interested in seeing Enhanced IP in the Linux kernel read on.

Here's the value proposition: if the Internet community wants to pass IP option 26 in the fast path (a scriptable single command enables this for Juniper and Cisco ISPs). Because this is easier than repeering globally(IPv6), this could in a relatively short period of time become a wide-spread option for use of IP option 26 WAN support.  Further, for experimentation to begin with EnIP, it is not necessary for IP option 26 to be passed in the fast path.  Quickly enabling WAN support is something IPv6 cannot do.  Yes, NATs have to be upgraded.  This is not optimal.    All that being said, the protocol is much much simpler to understand than IPv6.  It is an evolution (similar to how CIDR and NAT became pervasive over time in the 1990's).  We have a lot of users who want to try the technology out but most of them are not patch your kernel kinds of people.  It would work a lot better if Enhanced IP was an option available in standard kernels.

We are new to the Linux kernel community and would take advice on the code.  If you look at our repository you will find that every file we update has a comment with the phrase "enhanced ip" so it is easy to see where we have made changes.  We are maintaining separate patches across five kernels at the moment.  Each new kernel requires a seperate porting process.  It takes 30 minutes-1 hour to get all the patch points reinstalled and a little more time to test.  We are especially interested in ideas people might have about integrating Enhanced IP with the IPv4 icmp code.  I have been able to shim the rest of the code into the existing tcp/udp/ipv4 code base without much trouble.  However, the icmp code is a different animal and I would welcome help from another developer(e.g. code patches).  At present you can do tcp and udp sockets only. If a message such as an icmp port unreachable needs to be sent to an EnIP address it does not work.  We are also working on the process by which we will accept patches to EnIP.  We were thinking about adopting the OpenWRT process but would certainly be willing to listen to other arguments based on experience.  Enhanced IP is a hobby project, so we're not looking to come up with our own process.  Rather, we would happily adopt a simple/terse process.

We've used Apache, samba, and ssh/scp over EnIP.  Basically, anything that uses getaddrinfo followed by connect should work fine.  E.g. we think all the code that has already been ported to use getaddrinfo pattern for IPv6 compatibility should also work with EnIP.

Our web site:
http://www.enhancedip.org/

Our git:
git clone https://github.com/EnIP/enhancedip.git

Our test virtual machines (write kernel code with VMs to simulate end to
end EnIP connections):
http://www.enhancedip.org/ENIP/

Thank you for your time.

-Sam Patton

Re: ANNOUNCE: Enhanced IP v1.4

[Willy Tarreau]

Hello Sam,

On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
> Hello!
> 
> If you do not know what Enhanced IP is, read this post on netdev first:
> 
> https://www.spinics.net/lists/netdev/msg327242.html
> 
> 
> The Enhanced IP project presents:
> 
>              Enhanced IP v1.4
> 
> The Enhanced IP (EnIP) code has been updated.  It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
(...) First note, please think about breaking your lines if you want your
mails to be read by the widest audience, as for some of us here, reading
lines wider than a terminal is really annoying, and often not considered
worth spending time on them considering there are so many easier ones
left to read.

> Interested in seeing Enhanced IP in the Linux kernel, read on.  Not
> interested in seeing Enhanced IP in the Linux kernel read on.
(...)

So I personally find the concept quite interesting. It reminds me of the
previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless.
Here the fact that you decide to consider the IPv4 address as a network opens
new perspectives. For containerized environments it could be considered that
each server, with one IPv4, can host 2^32 guests and that NAT is not needed
anymore for example. It could also open the possibility that enthousiasts
can more easily host some services at home behind their ADSL line without
having to run on strange ports.

However I think your approach is not the most efficient to encourage adoption.
It's important to understand that there will be little incentive for people
to patch their kernels to run some code if they don't have the applications
on top of it. The kernel is not the end goal for most users, the kernel is
just the lower layer needed to run applications on top. I looked at your site
and the github repo, and all I could find was a pre-patched openssh, no simple
explanation of what to change in an application.

What you need to do first is to *explain* how to modify userland applications
to support En-IP, provide an echo server and show the parts which have to be
changed. Write a simple client and do the same. Provide your changes to
existing programs as patches, not as pre-patched code. This way anyone can
use your patches on top of other versions, and can use these patches to
understand what has to be modified in their applications.

Once applications are easy to patch, the incentive to install patched kernels
everywhere will be higher. For many enthousiasts, knowing that they only have
to modify the ADSL router to automatically make their internal IoT stuff
accessible from outside indeed becomes appealing.

Then you'll need to provide patches for well known applications like curl,
wget, DNS servers (bind...), then browsers.

In my case I could be interested in adding support for En-ip into haproxy,
and only once I don't see any showstopped in doing this, I'd be willing to
patch my kernel to support it.

Last advice, provide links to your drafts in future e-mails, they are not
easy to find on your site, we have to navigate through various pages to
finally find them.

Regards,
Willy

Re: ANNOUNCE: Enhanced IP v1.4

[Sam Patton]

Hello Willy, netdev,

Thank you for your reply and advice.  I couldn't agree more with you
about containers and the exciting prospects there,

as well as the ADSL scenario you mention.

As far as application examples, check out this simple netcat-like
program I use for testing:

https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c

Lines 61-67 show how to connect directly via an EnIP address.  The
netcat-like application uses

a header file called eip.h.  You can look at it here:

https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h

EnIP makes use of IPv6 AAAA records for DNS lookup.  We simply put
2001:0101 (which is an IPv6 experimental prefix) and

then we put the 64-bit EnIP address into the next 8 bytes of the
address.  The remaining bytes are set to zero.

In the kernel, if you want to see how we convert the IPv6 DNS lookup
into something connect() can manage,

check out the add_enhanced_ip() routine found here:

https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c

The reason we had to do changes for openssh and not other applications
(that use DNS) is openssh has a check to

see if the socket is using IP options.  If the socket does, sshd drops
the connection.  I had to work around that to get openssh working

with EnIP.  The result: if you want to connect the netcat-like program
with IP addresses you'll end up doing something like the

example above.  If you're using DNS (getaddrinfo) to connect(), it
should just work (except for sshd as noted).

Here's the draft experimental RFC:
https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03

I'll also note that I am doing this code part time as a hobby for a long
time so I appreciate your help and support.  It would be really

great if the kernel community decided to pick this up, but if it's not a
reality please let me know soonest so I can move on to a

different hobby.  :)

Thank you.

Sam Patton

On 6/2/18 1:57 AM, Willy Tarreau wrote:
> Hello Sam,
>
> On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
>> Hello!
>>
>> If you do not know what Enhanced IP is, read this post on netdev first:
>>
>> https://www.spinics.net/lists/netdev/msg327242.html
>>
>>
>> The Enhanced IP project presents:
>>
>>              Enhanced IP v1.4
>>
>> The Enhanced IP (EnIP) code has been updated.  It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
> (...) First note, please think about breaking your lines if you want your
> mails to be read by the widest audience, as for some of us here, reading
> lines wider than a terminal is really annoying, and often not considered
> worth spending time on them considering there are so many easier ones
> left to read.
>
>> Interested in seeing Enhanced IP in the Linux kernel, read on.  Not
>> interested in seeing Enhanced IP in the Linux kernel read on.
> (...)
>
> So I personally find the concept quite interesting. It reminds me of the
> previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless.
> Here the fact that you decide to consider the IPv4 address as a network opens
> new perspectives. For containerized environments it could be considered that
> each server, with one IPv4, can host 2^32 guests and that NAT is not needed
> anymore for example. It could also open the possibility that enthousiasts
> can more easily host some services at home behind their ADSL line without
> having to run on strange ports.
>
> However I think your approach is not the most efficient to encourage adoption.
> It's important to understand that there will be little incentive for people
> to patch their kernels to run some code if they don't have the applications
> on top of it. The kernel is not the end goal for most users, the kernel is
> just the lower layer needed to run applications on top. I looked at your site
> and the github repo, and all I could find was a pre-patched openssh, no simple
> explanation of what to change in an application.
>
> What you need to do first is to *explain* how to modify userland applications
> to support En-IP, provide an echo server and show the parts which have to be
> changed. Write a simple client and do the same. Provide your changes to
> existing programs as patches, not as pre-patched code. This way anyone can
> use your patches on top of other versions, and can use these patches to
> understand what has to be modified in their applications.
>
> Once applications are easy to patch, the incentive to install patched kernels
> everywhere will be higher. For many enthousiasts, knowing that they only have
> to modify the ADSL router to automatically make their internal IoT stuff
> accessible from outside indeed becomes appealing.
>
> Then you'll need to provide patches for well known applications like curl,
> wget, DNS servers (bind...), then browsers.
>
> In my case I could be interested in adding support for En-ip into haproxy,
> and only once I don't see any showstopped in doing this, I'd be willing to
> patch my kernel to support it.
>
> Last advice, provide links to your drafts in future e-mails, they are not
> easy to find on your site, we have to navigate through various pages to
> finally find them.
>
> Regards,
> Willy

Re: ANNOUNCE: Enhanced IP v1.4

[Willy Tarreau]

On Sat, Jun 02, 2018 at 12:17:12PM -0400, Sam Patton wrote:
> As far as application examples, check out this simple netcat-like
> program I use for testing:
> 
> https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c
> 
> Lines 61-67 show how to connect directly via an EnIP address.  The
> netcat-like application uses
> 
> a header file called eip.h.

OK so basically we need to use a new address structure (which makes sense),
however I'm not sure I understand how the system is supposed to know it has
to use EnIP instead of IPv4 if the sin_family remains the same :

...
   memset(&serv_addr, 0, sizeof(struct sockaddr_ein));
   serv_addr.sin_family= AF_INET;
   serv_addr.sin_port = htons(portno);
   serv_addr.sin_addr1=inet_addr(argv[1]);
   serv_addr.sin_addr2=inet_addr(argv[2]);

   if (connect(sockfd,(struct sockaddr *) &serv_addr,sizeof(serv_addr)) < 0) 
	error("ERROR connecting");
...

Does it solely rely on the 3rd argument to connect() to know that it
may read sin_addr2 ? If so, that sounds a bit fragile to me because I
*think* (but could be wrong) that right now any size at least as large
as sockaddr_in work for IPv4 (typically I think if you pass a struct
sockaddr_storage with its size it should work). So there would be a
risk of breaking applications if this is the case.

I suspect that using a different family would make things more robust
and more friendly to applications. But that's just a first opinion,
you have worked longer than me on this.

>  You can look at it here:
> 
> https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h

Thank you. There's a problem with your #pragma pack there, it will
propagate to all struct declared after this file is included and
will force all subsequent structs to be packed. It would be preferable
to use __attribute__((packed)) on the struct or to use pragma pack()
safely (I've just seen it supports push/pop options).

> EnIP makes use of IPv6 AAAA records for DNS lookup.  We simply put
> 2001:0101 (which is an IPv6 experimental prefix) and
> 
> then we put the 64-bit EnIP address into the next 8 bytes of the
> address.  The remaining bytes are set to zero.

Does this require a significant amount of changes to the libc ?

> In the kernel, if you want to see how we convert the IPv6 DNS lookup
> into something connect() can manage,
> 
> check out the add_enhanced_ip() routine found here:
> 
> https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c

Hmmm so both IPv4 and IPv6 addresses are supported and used together.
So that just makes me think that if in the end you need a little bit
of IPv6 to handle this, why not instead define a new way to map IPv6 to
Enhanced IPv4 ? I mean, you'd exclusively use AF_INET6 in applications,
within a dedicated address range, allowing you to naturally use all of
the IPv6 ecosystem in place in userland, but use IPv4 over the wire.
This way applications would possibly require even less modififications,
if any at all because they'd accept/connect/send/receive data for IPv6
address families that they all deal with nowadays, but this would rely
on an omni-present IPv4 infrastructure.

> The reason we had to do changes for openssh and not other applications
> (that use DNS) is openssh has a check to
> 
> see if the socket is using IP options.  If the socket does, sshd drops
> the connection.  I had to work around that to get openssh working

OK. They possibly do this to avoid source-routing.

> with EnIP.  The result: if you want to connect the netcat-like program
> with IP addresses you'll end up doing something like the
> 
> example above.  If you're using DNS (getaddrinfo) to connect(), it
> should just work (except for sshd as noted).
> 
> Here's the draft experimental RFC:
> https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03

Yep I've found it on the site.

> I'll also note that I am doing this code part time as a hobby for a long
> time so I appreciate your help and support.  It would be really
> 
> great if the kernel community decided to pick this up, but if it's not a
> reality please let me know soonest so I can move on to a
> 
> different hobby.  :)

I *personally* think there is some value in what you're experimenting
with, and doing it as a hobby can leave you with the time needed to
collect pros and cons from various people. I'm just thinking that in
order to get some adoption, you need to be extremely careful not to
break any of the IPv4 applications developed in the last 38 years,
and by this, AF_INET+sizeof() scares me a little bit.

Regards,
Willy

Re: ANNOUNCE: Enhanced IP v1.4

[Tom Herbert]

On Sat, Jun 2, 2018 at 9:17 AM, Sam Patton <sam@enhancedip.org> wrote:
> Hello Willy, netdev,
>
> Thank you for your reply and advice.  I couldn't agree more with you
> about containers and the exciting prospects there,
>
> as well as the ADSL scenario you mention.
>
> As far as application examples, check out this simple netcat-like
> program I use for testing:
>
> https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c
>
> Lines 61-67 show how to connect directly via an EnIP address.  The
> netcat-like application uses
>
> a header file called eip.h.  You can look at it here:
>
> https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h
>
> EnIP makes use of IPv6 AAAA records for DNS lookup.  We simply put
> 2001:0101 (which is an IPv6 experimental prefix) and
>
> then we put the 64-bit EnIP address into the next 8 bytes of the
> address.  The remaining bytes are set to zero.
>
> In the kernel, if you want to see how we convert the IPv6 DNS lookup
> into something connect() can manage,
>
> check out the add_enhanced_ip() routine found here:
>
> https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c
>
> The reason we had to do changes for openssh and not other applications
> (that use DNS) is openssh has a check to
>
> see if the socket is using IP options.  If the socket does, sshd drops
> the connection.  I had to work around that to get openssh working
>
> with EnIP.  The result: if you want to connect the netcat-like program
> with IP addresses you'll end up doing something like the
>
> example above.  If you're using DNS (getaddrinfo) to connect(), it
> should just work (except for sshd as noted).
>
> Here's the draft experimental RFC:
> https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03
> I'll also note that I am doing this code part time as a hobby for a long
> time so I appreciate your help and support.  It would be really
>
> great if the kernel community decided to pick this up, but if it's not a
> reality please let me know soonest so I can move on to a
>
Hi Sam,

This is not an inconsequential mechanism that is being proposed. It's
a modification to IP protocol that is intended to work on the
Internet, but it looks like the draft hasn't been updated for two
years and it is not adopted by any IETF working group. I don't see how
this can go anywhere without IETF support. Also, I suggest that you
look at the IPv10 proposal since that was very similar in intent. One
of the reasons that IPv10 shot down was because protocol transition
mechanisms were more interesting ten years ago than today. IPv6 has
good traction now. In fact, it's probably the case that it's now
easier to bring up IPv6 than to try to make IPv4 options work over the
Internet.

Tom


> different hobby.  :)
>
> Thank you.
>
> Sam Patton
>
> On 6/2/18 1:57 AM, Willy Tarreau wrote:
>> Hello Sam,
>>
>> On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote:
>>> Hello!
>>>
>>> If you do not know what Enhanced IP is, read this post on netdev first:
>>>
>>> https://www.spinics.net/lists/netdev/msg327242.html
>>>
>>>
>>> The Enhanced IP project presents:
>>>
>>>              Enhanced IP v1.4
>>>
>>> The Enhanced IP (EnIP) code has been updated.  It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers.
>> (...) First note, please think about breaking your lines if you want your
>> mails to be read by the widest audience, as for some of us here, reading
>> lines wider than a terminal is really annoying, and often not considered
>> worth spending time on them considering there are so many easier ones
>> left to read.
>>
>>> Interested in seeing Enhanced IP in the Linux kernel, read on.  Not
>>> interested in seeing Enhanced IP in the Linux kernel read on.
>> (...)
>>
>> So I personally find the concept quite interesting. It reminds me of the
>> previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless.
>> Here the fact that you decide to consider the IPv4 address as a network opens
>> new perspectives. For containerized environments it could be considered that
>> each server, with one IPv4, can host 2^32 guests and that NAT is not needed
>> anymore for example. It could also open the possibility that enthousiasts
>> can more easily host some services at home behind their ADSL line without
>> having to run on strange ports.
>>
>> However I think your approach is not the most efficient to encourage adoption.
>> It's important to understand that there will be little incentive for people
>> to patch their kernels to run some code if they don't have the applications
>> on top of it. The kernel is not the end goal for most users, the kernel is
>> just the lower layer needed to run applications on top. I looked at your site
>> and the github repo, and all I could find was a pre-patched openssh, no simple
>> explanation of what to change in an application.
>>
>> What you need to do first is to *explain* how to modify userland applications
>> to support En-IP, provide an echo server and show the parts which have to be
>> changed. Write a simple client and do the same. Provide your changes to
>> existing programs as patches, not as pre-patched code. This way anyone can
>> use your patches on top of other versions, and can use these patches to
>> understand what has to be modified in their applications.
>>
>> Once applications are easy to patch, the incentive to install patched kernels
>> everywhere will be higher. For many enthousiasts, knowing that they only have
>> to modify the ADSL router to automatically make their internal IoT stuff
>> accessible from outside indeed becomes appealing.
>>
>> Then you'll need to provide patches for well known applications like curl,
>> wget, DNS servers (bind...), then browsers.
>>
>> In my case I could be interested in adding support for En-ip into haproxy,
>> and only once I don't see any showstopped in doing this, I'd be willing to
>> patch my kernel to support it.
>>
>> Last advice, provide links to your drafts in future e-mails, they are not
>> easy to find on your site, we have to navigate through various pages to
>> finally find them.
>>
>> Regards,
>> Willy
>

Re: ANNOUNCE: Enhanced IP v1.4

[Eric Dumazet]

On 06/03/2018 01:37 PM, Tom Herbert wrote:

> This is not an inconsequential mechanism that is being proposed. It's
> a modification to IP protocol that is intended to work on the
> Internet, but it looks like the draft hasn't been updated for two
> years and it is not adopted by any IETF working group. I don't see how
> this can go anywhere without IETF support. Also, I suggest that you
> look at the IPv10 proposal since that was very similar in intent. One
> of the reasons that IPv10 shot down was because protocol transition
> mechanisms were more interesting ten years ago than today. IPv6 has
> good traction now. In fact, it's probably the case that it's now
> easier to bring up IPv6 than to try to make IPv4 options work over the
> Internet.

+1

Many hosts do not use IPv4 anymore.

We even have the project making IPv4 support in linux optional.

Re: ANNOUNCE: Enhanced IP v1.4

[Willy Tarreau]

On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
> 
> 
> On 06/03/2018 01:37 PM, Tom Herbert wrote:
> 
> > This is not an inconsequential mechanism that is being proposed. It's
> > a modification to IP protocol that is intended to work on the
> > Internet, but it looks like the draft hasn't been updated for two
> > years and it is not adopted by any IETF working group. I don't see how
> > this can go anywhere without IETF support. Also, I suggest that you
> > look at the IPv10 proposal since that was very similar in intent. One
> > of the reasons that IPv10 shot down was because protocol transition
> > mechanisms were more interesting ten years ago than today. IPv6 has
> > good traction now. In fact, it's probably the case that it's now
> > easier to bring up IPv6 than to try to make IPv4 options work over the
> > Internet.
> 
> +1
> 
> Many hosts do not use IPv4 anymore.
> 
> We even have the project making IPv4 support in linux optional.

I agree on these points, but I'd like to figure what can be done to put
a bit more pressure on ISPs to *always* provide IPv6. It's still very
hard to have decent connectivity at home and without this it will continue
to be marginalize.

I do have IPv6 at home (a /48, waste of addressing space, I'd be fine
with less), there's none at work (I don't even know if the ISP supports
it, at least it was never ever mentioned so probably they don't know
about this), and some ISPs only provide a /64 which is as ridiculous
as providing a single address as it forces the end user to NAT thus
breaking the end-to-end principle. Ideally with IoT at the door, every
home connection should have at least a /60 and enterprises should have
a /56, and this by default, without having to request anything.

Maybe setting up a public list of ISPs where users don't have at least
a /60 by default could help, but I suspect that most of them will
consider that as long as their competitors are on the list there's no
emergency.

Willy

答复: ANNOUNCE: Enhanced IP v1.4

[PKU.孙斌]

On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
> 
> 
> On 06/03/2018 01:37 PM, Tom Herbert wrote:
> 
> > This is not an inconsequential mechanism that is being proposed. It's
> > a modification to IP protocol that is intended to work on the
> > Internet, but it looks like the draft hasn't been updated for two
> > years and it is not adopted by any IETF working group. I don't see how
> > this can go anywhere without IETF support. Also, I suggest that you
> > look at the IPv10 proposal since that was very similar in intent. One
> > of the reasons that IPv10 shot down was because protocol transition
> > mechanisms were more interesting ten years ago than today. IPv6 has
> > good traction now. In fact, it's probably the case that it's now
> > easier to bring up IPv6 than to try to make IPv4 options work over the
> > Internet.
> 
> +1
> 
> Many hosts do not use IPv4 anymore.
> 
> We even have the project making IPv4 support in linux optional.

I guess then Linux kernel wouldn't be able to boot itself without IPv4 built in, e.g., when we only have old L2 links (without the IPv6 frame type)...

Re: 答复: ANNOUNCE: Enhanced IP v1.4

[Eric Dumazet]

On 06/03/2018 10:58 PM, PKU.孙斌 wrote:
> On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
>>
>>
>> On 06/03/2018 01:37 PM, Tom Herbert wrote:
>>
>>> This is not an inconsequential mechanism that is being proposed. It's
>>> a modification to IP protocol that is intended to work on the
>>> Internet, but it looks like the draft hasn't been updated for two
>>> years and it is not adopted by any IETF working group. I don't see how
>>> this can go anywhere without IETF support. Also, I suggest that you
>>> look at the IPv10 proposal since that was very similar in intent. One
>>> of the reasons that IPv10 shot down was because protocol transition
>>> mechanisms were more interesting ten years ago than today. IPv6 has
>>> good traction now. In fact, it's probably the case that it's now
>>> easier to bring up IPv6 than to try to make IPv4 options work over the
>>> Internet.
>>
>> +1
>>
>> Many hosts do not use IPv4 anymore.
>>
>> We even have the project making IPv4 support in linux optional.
> 
> I guess then Linux kernel wouldn't be able to boot itself without IPv4 built in, e.g., when we only have old L2 links (without the IPv6 frame type)...



*Optional* means that a CONFIG_IPV4 would be there, and some people could build a kernel with CONFIG_IPV4=n,

Like IPv6 is optional today.

Of course, most distros will select CONFIG_IPV4=y  (as they probably select CONFIG_IPV6=y today)

Do not worry, IPv4 is not dead, but I doubt Enhanced IP v1.4 has any chance,
it is at least 10 years too late.

Re: 答复: ANNOUNCE: Enhanced IP v1.4

[Tom Herbert]

On Mon, Jun 4, 2018 at 6:02 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 06/03/2018 10:58 PM, PKU.孙斌 wrote:
>> On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
>>>
>>>
>>> On 06/03/2018 01:37 PM, Tom Herbert wrote:
>>>
>>>> This is not an inconsequential mechanism that is being proposed. It's
>>>> a modification to IP protocol that is intended to work on the
>>>> Internet, but it looks like the draft hasn't been updated for two
>>>> years and it is not adopted by any IETF working group. I don't see how
>>>> this can go anywhere without IETF support. Also, I suggest that you
>>>> look at the IPv10 proposal since that was very similar in intent. One
>>>> of the reasons that IPv10 shot down was because protocol transition
>>>> mechanisms were more interesting ten years ago than today. IPv6 has
>>>> good traction now. In fact, it's probably the case that it's now
>>>> easier to bring up IPv6 than to try to make IPv4 options work over the
>>>> Internet.
>>>
>>> +1
>>>
>>> Many hosts do not use IPv4 anymore.
>>>
>>> We even have the project making IPv4 support in linux optional.
>>
>> I guess then Linux kernel wouldn't be able to boot itself without IPv4 built in, e.g., when we only have old L2 links (without the IPv6 frame type)...
>
>
>
> *Optional* means that a CONFIG_IPV4 would be there, and some people could build a kernel with CONFIG_IPV4=n,
>
> Like IPv6 is optional today.
>
> Of course, most distros will select CONFIG_IPV4=y  (as they probably select CONFIG_IPV6=y today)
>
> Do not worry, IPv4 is not dead, but I doubt Enhanced IP v1.4 has any chance,
> it is at least 10 years too late.

There's also https://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/.
We're reaching the point where it's the transition mechnanisms that
are hampering IPv6 adoption.

Tom

Re: ANNOUNCE: Enhanced IP v1.4

[Bjørn Mork]

Willy Tarreau <w@1wt.eu> writes:

> I agree on these points, but I'd like to figure what can be done to put
> a bit more pressure on ISPs to *always* provide IPv6.

Most ISPs are in it for the money.  So what you can do is either to make
it more expensive to provide IPv4-only services or more profitable to
provide dual-stack services.  Making IPv4 more expensive is probably
hard.  Even ISPs having to buy address space still figure it is cheaper
than IPv6 with NAT64 or other CGN solutions.

So what you need to do is simply to convince enough of your friends to
pay the price of IPv6.

The fact is that adding IPv6 still has real costs and no real benefit
for an ISP.  There just aren't enough geeks voting with their wallet to
make a difference.  And even if "everything" supports IPv6, there will
always be an extra set of bugs and additional operational problems with
*any* optional feature you enable. IPv6 is no exception. Enthusiasts
within the ISPs is the only reason there is any ISP providing dual-stack
services at all.

> I do have IPv6 at home (a /48, waste of addressing space, I'd be fine
> with less),

Any reason you would want less?  Any reason the ISP should give you
less?

> Maybe setting up a public list of ISPs where users don't have at least
> a /60 by default could help, but I suspect that most of them will
> consider that as long as their competitors are on the list there's no
> emergency.

Exactly.  And the number of users using the list as the primary
parameter for selecting an ISP would be close to 0.  The critical part
is not the list, but making large enough groups of users consider IPv6
an important parameter when selecting ISPs.

Disclaimer: I work for an ISP providing dual-stack services on multiple
access technologies, in a market where no other major ISP does that.  We
have done it for 6 years now, and haven't see any tendency that end
users prefer us over competitors based on IPv6.  Media interest is none.
IPv6 is not even mentioned in articles claiming to compare services.


Bjørn

Re: ANNOUNCE: Enhanced IP v1.4

[Willy Tarreau]

On Tue, Jun 05, 2018 at 02:33:03PM +0200, Bjørn Mork wrote:
> > I do have IPv6 at home (a /48, waste of addressing space, I'd be fine
> > with less),
> 
> Any reason you would want less?  Any reason the ISP should give you
> less?

What I mean is that *if* the availability of /48 networks was an issue
for some ISPs, I'd be fine with less because I don't plan to deploy 64k
networks at home, though I already have ~9 around the firewall and don't
expect to go much further.

> > Maybe setting up a public list of ISPs where users don't have at least
> > a /60 by default could help, but I suspect that most of them will
> > consider that as long as their competitors are on the list there's no
> > emergency.
> 
> Exactly.  And the number of users using the list as the primary
> parameter for selecting an ISP would be close to 0.  The critical part
> is not the list, but making large enough groups of users consider IPv6
> an important parameter when selecting ISPs.

In fact the IoT trend could play a role here by letting users know that
they can remotely access their fridge and whatever stupid device they've
deployed. But the reality is the opposite : some gateway services are/will
be offered at a paid price to make these devices remotely accessible, and
the claimed security provided by this gateway will be presented as a real
benefit compared to the risks of anyone directly accessing your private
life over IPv6. So I'm not getting much hopes for the future in this area
either.

Willy