Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

On 08-03-2017 00:27, Dennis Bohn wrote:


In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.

AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
try to figure something out, a coincidence that this is in reply to Jakob
from Cisco but is based on what he wrote)  relies on Link Local addresses.
I didn't understand why link locals should be there in the first place
seemed klugey and have googled, looked at rfcs and tried to understand why
link local addresses were baked into V6. The only thing I found was that it
enabled interfaces on point to point links to be unaddressed in V6. (To
save address space!??) Can anyone point me in a direction to understand the
reasoning for link local addressing?

dennis


Many features of IPv6 depends on link local. Take a look at the routing 
table of your computer - you will find that most routes have a next hop 
with a link local address. Many buildin protocols, such as RA and 
DHCPv6, use link local to communicate without depending on any 
configuration.


Many protocols with automatic discovery will use link local - why would 
you want your printer or local NAS server to use a public IP when link 
local works? In fact, you may prefer the printer to be only on link 
local so it can not be accessed from outside. The public IP is something 
your ISP assigns to you, so using that unnecessary only makes your setup 
vulnerable to problems if the internet is down. You could assign an ULA 
prefix https://en.wikipedia.org/wiki/Unique_local_address for your 
network but most people wont.


Regards,

Baldur

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

EZIP has no transition strategy and is not backwards compatible with 
IPv4. The scheme is unworkable.


It is not possible to dual stack EZIP because it pretends to be IPv4.

The author of EZIP should demonstrate a working prototype. We need to 
see a setup with two clients on a shared external IP address. Then 
demonstrate that the clients can access an EZIP enabled site and also 
that the clients can access unmodified IPv4 sites such as Google.com and 
Facebook.com.


The later test will fail and there is no fix. EZIP requires a big bang 
transition where the whole world implements EZIP on the same day.


EZIP embeds extra address information in IP option headers. The remote 
site needs to take that extra address information and send back in the 
replies. The remote site needs to read the extra "source EZIP" option 
header and put that as an "destination EZIP" option header on reply 
packets. Legacy IPv4 sites do not know the meaning the extra option 
headers and can not do send them back. Packets will arrive at the EZIP 
gateway without option headers. The EZIP gateway will have no option 
other than to drop the packets, because without option headers nothing 
will differentiate the multiple clients behind the gateway.


The EZIP gateway could fall back to NAT when the remote site does not 
have EZIP support. However no method is provided that can tell the EZIP 
gateway wether the remote has EZIP support or not. Since the EZIP 
gateway works on the IP level, we can not use some DNS tricks like 
NAT64/DNS64.


Regards,

Baldur


On 07-03-2017 18:46, Jakob Heitz (jheitz) wrote:

1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f.

Some higher layer protocols embed IP addresses into their data.

These points make changing IP so difficult.

In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.
Thakfully, site local was deprecated.

Thanks,
Jakob.


Date: Mon, 6 Mar 2017 22:00:45 +0100
From: Baldur Norddahl 
To: nanog@nanog.org
Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
Message-ID: <5645714e-e468-4655-34cf-6e70aa7cf...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

That proposal is far too wordy. Here is the executive summary:

Encode extra address bits in extension headers. Add a network element
near the destination that converts such that the destination IP of a
packet to IP a.b.c.d with extension header containing e.f is translated
to 192.168.e.f. In the reverse direction translate source address
192.168.e.f to a.b.c.d and add option header with e.f.

Executive summary end.

As far as I can tell, the only advantage of this proposal over IPv6 is
that the network core does not need to be changed. You could communicate
with someone that had an EZIP address regardless that your ISP did
nothing to support EZIP.

The disadvantage is that every single server out there would need to be
changed so it does not just drop the option headers on the reply
packets. All firewalls updated so they do not block packets with option
headers. All applications updated so they understand a new address format.

Servers and applications could also confuse TCP or UDP streams that are
apparently from the same source, same port numbers, only thing that
differentiates the streams is some option header that the server does
not understand.

The customers of the ISP that deploys EZIP would not need to update
anything (unless they need to communicate with other poor souls that got
assigned EZIP addresses), however everyone else would. This is not a
good balance. The customers would experience an internet where almost
nothing works. It would be magnitudes worse than the experience of an
IPv6 only network with NAT64.

It is a fix for the wrong problem. Major ISPs have IPv6 support now. It
is the sites (=servers) that are lacking. If Twitter did not deploy IPv6
why would you expect them to deploy EZIP? Why would some old forgotten
site with old song texts in some backwater country somewhere?

We already have better solutions such as CGN with dual stack, NAT64,
DS-Lite, MAP etc.

None of that is discussed in the RFC. Is the author aware of it?

Regards,

Baldur

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Mike Jones]

On 7 March 2017 at 23:27, Dennis Bohn  wrote:

> >
> >
> > In addition, IPv6 has link local addresses.
> > This one seemingly insignificant detail causes so much code churn
> > and is probably responsible for 10 years of the IPv6 drag.
>
> AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
> try to figure something out, a coincidence that this is in reply to Jakob
> from Cisco but is based on what he wrote)  relies on Link Local addresses.
> I didn't understand why link locals should be there in the first place
> seemed klugey and have googled, looked at rfcs and tried to understand why
> link local addresses were baked into V6. The only thing I found was that it
> enabled interfaces on point to point links to be unaddressed in V6. (To
> save address space!??) Can anyone point me in a direction to understand the
> reasoning for link local addressing?
>

So you can print whilst your Internet connection is down. IPv6 allowed
people to rethink IPv4 assumptions, and they realised that a lot of IPv4
things were hacks to work around a lack of functionality in the protocol.
NAT has polluted peoples minds when it comes to the distinctions between
local and global addressing.

Why would you use a global address, with an extra code check to make sure
it is on a directly attached interface, to point a route at? "Router 2 on
interface B" makes more sense to me than "Router with global address 12345"
in this context.

I would also have loved it if the all-routers-anycast thing had been better
defined rather than deprecated. One of the potential default behaviours
could have been fe80:: as a default gateway on every segment, with a
logical meaning of "All upstream routers on this interface".

- Mike

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[valdis . kletnieks]

On Tue, 07 Mar 2017 18:27:06 -0500, Dennis Bohn said:

> AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
> try to figure something out, a coincidence that this is in reply to Jakob
> from Cisco but is based on what he wrote)  relies on Link Local addresses.
> I didn't understand why link locals should be there in the first place
> seemed klugey and have googled, looked at rfcs and tried to understand why
> link local addresses were baked into V6. The only thing I found was that it
> enabled interfaces on point to point links to be unaddressed in V6. (To
> save address space!??) Can anyone point me in a direction to understand the
> reasoning for link local addressing?

Because there are a lot of corner cases where you may want to talk to the
network before you find out what your network address is.  And if it's a
stand-alone network, it may not *have* a well-define network prefix to use
for SLAAC auto-config addressing.

Think about all the places in IPv4 where you toss packets on the net with your
MAC address or a bogus placeholder IP address because you don't have an IP
address yet (ARP, DHCP for starters).  Link-Local is basically the same thing
in the IPv6 world.



pgpXi70hICXMR.pgp
Description: PGP signature

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Dennis Bohn]

>
>
> In addition, IPv6 has link local addresses.
> This one seemingly insignificant detail causes so much code churn
> and is probably responsible for 10 years of the IPv6 drag.

AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
try to figure something out, a coincidence that this is in reply to Jakob
from Cisco but is based on what he wrote)  relies on Link Local addresses.
I didn't understand why link locals should be there in the first place
seemed klugey and have googled, looked at rfcs and tried to understand why
link local addresses were baked into V6. The only thing I found was that it
enabled interfaces on point to point links to be unaddressed in V6. (To
save address space!??) Can anyone point me in a direction to understand the
reasoning for link local addressing?

dennis

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Mark Andrews]

In message <608f5c96-3134-9cdf-6f93-41d14d371...@2mbit.com>, Brielle Bruns writ
es:
> On 3/6/17 10:16 AM, valdis.kletni...@vt.edu wrote:
> > On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:
> >
> >> routing hardware layer that will be hit & miss. Nevertheless, since much o
> f
> >> the world is still IPv4 dependent, it just could take off.
> >
> > For it to "take off", the very same people who have dragged their heels
> > deploying IPv6 will need to suddenly jump up and upgrade all their gear
> > and personnel to support a *third* protocol.
> >
> > Oh, and you're going to need support buy-in from *at least* Microsoft, Appl
> e,
> > Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.
> >
> > What's the business case for all these stakeholders to buy into EZIP?  For
> > both the "We already do IPv6" and "We don't do IP6v" cases?
> >
> 
> 
> Lets not even get into the fact that we still can't fully utilize things 
> like already established standards such as ECN, EDNS, and PMTUD 
> effectively because firewall and security vendors still can't extricate 
> their heads from backside and handle basic functionality of IPv4 without 
> throwing the packets on the floor.

While this is a Checkpoint example and Checkpoint are in the process of
addressing this the issue is in no way limited to Checkpoint.

Firewall R75.20 Administration Guide 20 May 2012

DNS verification of EDNS queries is supported. This allows use of
BIND. EDNS headers are allowed if they contain all zeros, other
than the field that controls the packet length (maximum payload
size).

BIND had the ability to send send and answer EDNS options for years
by then so it should have read if it was honest:

DNS verification of EDNS queries is supported.  EDNS headers are
allowed if they contain all zeros, other than the field that controls
the packet length (maximum payload size).  This breaks EDNS version
negotiation and prevents the use of EDNS options by BIND and other
name servers. This also breaks the ability to use new EDNS flags
as specified by the IETF.

db30f4bdcb (Mark Andrews   2008-04-03 02:01:08 +  6809)
2353.   [func]  Add support for Name Server ID (RFC 5001).
 'dig +nsid' requests NSID from server.
 'request-nsid yes;' causes recursive server to send
 NSID requests to upstream servers.  Server responds
 to NSID requests with the string configured by
 'server-id' option.  [RT #17091]

These sorts of checks should have never been there in the first
place RFC 2671 already defined what to do with EDNS version != 0
queries which is to return a BADVERS error code.  What purpose did
blocking version != 0 serve?

Similarly for EDNS flags.  These are supposed to be ingored if you
don't support them.  What purpose does blocking these flags serve?

RFC 6891 should have bumped the EDNS version number but it was
impractical to do that because firewall vendors decided that only
EDNS version 0 queries are valid rather than letting the nameserver
perform EDNS version negotiation.  RFC 6891 cleaned up the handling
of unknown EDNS options (it was under specified) and bumping the
EDNS version number would, in theory, give consistent handling
(ignore unknown options) in EDNS(1) queries.

You are buying this stuff.  You need to understand what it is doing
and the vendors need to be clear about how it is breaking stuff.

Mark

> If the average 'security' device these days chokes and drops a packet 
> due to not recognizing the ECN option, what makes anyone think shoving 
> more special stuff in the headers just for IoT crap is a good idea?
> 
> Wouldn't it just be easier to use IPv6 tunneled over Teredo?
> 
> Oh wait, that would require the IoT vendors to actually build decent 
> products with software that works.
> 
> 
> -- 
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Jakob Heitz (jheitz)]

1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f.

Some higher layer protocols embed IP addresses into their data.

These points make changing IP so difficult.

In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.
Thakfully, site local was deprecated.

Thanks,
Jakob.

> Date: Mon, 6 Mar 2017 22:00:45 +0100
> From: Baldur Norddahl 
> To: nanog@nanog.org
> Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
> Message-ID: <5645714e-e468-4655-34cf-6e70aa7cf...@gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> That proposal is far too wordy. Here is the executive summary:
> 
> Encode extra address bits in extension headers. Add a network element
> near the destination that converts such that the destination IP of a
> packet to IP a.b.c.d with extension header containing e.f is translated
> to 192.168.e.f. In the reverse direction translate source address
> 192.168.e.f to a.b.c.d and add option header with e.f.
> 
> Executive summary end.
> 
> As far as I can tell, the only advantage of this proposal over IPv6 is
> that the network core does not need to be changed. You could communicate
> with someone that had an EZIP address regardless that your ISP did
> nothing to support EZIP.
> 
> The disadvantage is that every single server out there would need to be
> changed so it does not just drop the option headers on the reply
> packets. All firewalls updated so they do not block packets with option
> headers. All applications updated so they understand a new address format.
> 
> Servers and applications could also confuse TCP or UDP streams that are
> apparently from the same source, same port numbers, only thing that
> differentiates the streams is some option header that the server does
> not understand.
> 
> The customers of the ISP that deploys EZIP would not need to update
> anything (unless they need to communicate with other poor souls that got
> assigned EZIP addresses), however everyone else would. This is not a
> good balance. The customers would experience an internet where almost
> nothing works. It would be magnitudes worse than the experience of an
> IPv6 only network with NAT64.
> 
> It is a fix for the wrong problem. Major ISPs have IPv6 support now. It
> is the sites (=servers) that are lacking. If Twitter did not deploy IPv6
> why would you expect them to deploy EZIP? Why would some old forgotten
> site with old song texts in some backwater country somewhere?
> 
> We already have better solutions such as CGN with dual stack, NAT64,
> DS-Lite, MAP etc.
> 
> None of that is discussed in the RFC. Is the author aware of it?
> 
> Regards,
> 
> Baldur
> 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 9:13 PM, Brielle Bruns  wrote:
> Lets not even get into the fact that we still can't fully utilize things
> like already established standards such as ECN, EDNS, and PMTUD effectively
> because firewall and security vendors still can't extricate their heads from
> backside and handle basic functionality of IPv4 without throwing the packets
> on the floor.

PMTUD is broken as designed, the one thing about TCP which directly
violates the end-to-end principle.

-Bill

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Brielle Bruns]

On 3/6/17 10:16 AM, valdis.kletni...@vt.edu wrote:

On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:


routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off.


For it to "take off", the very same people who have dragged their heels
deploying IPv6 will need to suddenly jump up and upgrade all their gear
and personnel to support a *third* protocol.

Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

What's the business case for all these stakeholders to buy into EZIP?  For
both the "We already do IPv6" and "We don't do IP6v" cases?




Lets not even get into the fact that we still can't fully utilize things 
like already established standards such as ECN, EDNS, and PMTUD 
effectively because firewall and security vendors still can't extricate 
their heads from backside and handle basic functionality of IPv4 without 
throwing the packets on the floor.


If the average 'security' device these days chokes and drops a packet 
due to not recognizing the ECN option, what makes anyone think shoving 
more special stuff in the headers just for IoT crap is a good idea?


Wouldn't it just be easier to use IPv6 tunneled over Teredo?

Oh wait, that would require the IoT vendors to actually build decent 
products with software that works.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Mark Andrews]

In message <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180>, "Bob 
Evans" writes:
> I have had ipv4 transit with ATT for years (one provider of many)and
> the order originally placed was for both ipv4 and 6yep still waiting.
> 
> Thank You
> Bob Evans
> CTO

Cancel your service and say it is because they failed to deliver
IPv6.  If they try to fight you for breaking the contract they don't
have a leg to stand on because they have failed to deliver on their
part of the contract.

I more people did this you would see IPv6 move up the priority stack.

Mark

> > On 3/6/17 14:04, Dennis Burgess wrote:
> >> Well try to get ATT to announce IPv6 though our AS!  Lol Been on the
> >> phone with the for over a month.  Still no ETA :(
> >
> >
> > Requests driven from the sales side should have the best results.
> >
> > Before Charter's sales turned into a hole of poor service, I had a
> > account manager that actually cared about the whole picture. I told him
> > the reason nobody before him was able to sell to us is because we have
> > requirements that need to be deliverable (no native IPv6 no sale), can't
> > deal in promises. Of course he's no longer there and I'm back to idiots
> > that just want to see how high of a price they can get you to sign for,
> > especially if you're already a customer there's no need to pretend to
> > care further.
> >
> > ~Seth
> >
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Bob Evans]

I have had ipv4 transit with ATT for years (one provider of many)and
the order originally placed was for both ipv4 and 6yep still waiting.

Thank You
Bob Evans
CTO




> On 3/6/17 14:04, Dennis Burgess wrote:
>> Well try to get ATT to announce IPv6 though our AS!  Lol Been on the
>> phone with the for over a month.  Still no ETA :(
>
>
> Requests driven from the sales side should have the best results.
>
> Before Charter's sales turned into a hole of poor service, I had a
> account manager that actually cared about the whole picture. I told him
> the reason nobody before him was able to sell to us is because we have
> requirements that need to be deliverable (no native IPv6 no sale), can't
> deal in promises. Of course he's no longer there and I'm back to idiots
> that just want to see how high of a price they can get you to sign for,
> especially if you're already a customer there's no need to pretend to
> care further.
>
> ~Seth
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Carsten Bormann]

On 6 Mar 2017, at 22:00, Baldur Norddahl  wrote:
> 
> Encode extra address bits in extension headers. Add a network element near 
> the destination that converts such that the destination IP of a packet to IP 
> a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In 
> the reverse direction translate source address 192.168.e.f to a.b.c.d and add 
> option header with e.f.

6to4 essentially did this already.  The main problem with 6to4 that made us 
stop using it was communicating to non-6to4 (“native”) IPv6 addresses; if you 
don’t want that, you have running code for both router and host side and plenty 
of gear that already works.

(All this is still complete nonsense in the face of accelerating native IPv6 
adoption; I write this just to show that the idea already has been implemented 
out there.)

Grüße, Carsten

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Seth Mattinen]

On 3/6/17 14:04, Dennis Burgess wrote:

Well try to get ATT to announce IPv6 though our AS!  Lol Been on the phone with 
the for over a month.  Still no ETA :(



Requests driven from the sales side should have the best results.

Before Charter's sales turned into a hole of poor service, I had a 
account manager that actually cared about the whole picture. I told him 
the reason nobody before him was able to sell to us is because we have 
requirements that need to be deliverable (no native IPv6 no sale), can't 
deal in promises. Of course he's no longer there and I'm back to idiots 
that just want to see how high of a price they can get you to sign for, 
especially if you're already a customer there's no need to pretend to 
care further.


~Seth

RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Dennis Burgess]

Well try to get ATT to announce IPv6 though our AS!  Lol Been on the phone with 
the for over a month.  Still no ETA :(  


Dennis Burgess - Network Solution Engineer - Consultant 
MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270
E-Mail: dmburg...@linktechs.net 


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bob Evans
Sent: Monday, March 6, 2017 3:34 PM
To: William Herrin 
Cc: nanog@nanog.org
Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

I think only 22% of networks with an AS announce IPv6 space.  Is that correct ?

Thank You
Bob Evans
CTO




> On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl 
>  wrote:
>> Major ISPs have IPv6 support now. It is the sites (=servers) that are 
>> lacking.
>
> Hi Baldur,
>
> Not exactly. My Verizon FiOS does not support IPv6. Neither does my 
> Cox Cable Internet. My Verizon Wireless service supports IPv6 but my 
> AT&T Wireless service does not.
>
> All four of these entities have IPv6 somewhere in their networks but 
> that's not at all the same thing as saying they "have IPv6 support."
>
> IPv6 deployment has gathered some momentum, enough that it's unlikely 
> to sputter out, but it's still laughably weak.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us 
> Dirtside Systems . Web: <http://www.dirtside.com/>
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Bob Evans]

I think only 22% of networks with an AS announce IPv6 space.  Is that
correct ?

Thank You
Bob Evans
CTO




> On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl
>  wrote:
>> Major ISPs have IPv6 support now. It is
>> the sites (=servers) that are lacking.
>
> Hi Baldur,
>
> Not exactly. My Verizon FiOS does not support IPv6. Neither does my
> Cox Cable Internet. My Verizon Wireless service supports IPv6 but my
> AT&T Wireless service does not.
>
> All four of these entities have IPv6 somewhere in their networks but
> that's not at all the same thing as saying they "have IPv6 support."
>
> IPv6 deployment has gathered some momentum, enough that it's unlikely
> to sputter out, but it's still laughably weak.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl
 wrote:
> Major ISPs have IPv6 support now. It is
> the sites (=servers) that are lacking.

Hi Baldur,

Not exactly. My Verizon FiOS does not support IPv6. Neither does my
Cox Cable Internet. My Verizon Wireless service supports IPv6 but my
AT&T Wireless service does not.

All four of these entities have IPv6 somewhere in their networks but
that's not at all the same thing as saying they "have IPv6 support."

IPv6 deployment has gathered some momentum, enough that it's unlikely
to sputter out, but it's still laughably weak.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

That proposal is far too wordy. Here is the executive summary:

Encode extra address bits in extension headers. Add a network element 
near the destination that converts such that the destination IP of a 
packet to IP a.b.c.d with extension header containing e.f is translated 
to 192.168.e.f. In the reverse direction translate source address 
192.168.e.f to a.b.c.d and add option header with e.f.


Executive summary end.

As far as I can tell, the only advantage of this proposal over IPv6 is 
that the network core does not need to be changed. You could communicate 
with someone that had an EZIP address regardless that your ISP did 
nothing to support EZIP.


The disadvantage is that every single server out there would need to be 
changed so it does not just drop the option headers on the reply 
packets. All firewalls updated so they do not block packets with option 
headers. All applications updated so they understand a new address format.


Servers and applications could also confuse TCP or UDP streams that are 
apparently from the same source, same port numbers, only thing that 
differentiates the streams is some option header that the server does 
not understand.


The customers of the ISP that deploys EZIP would not need to update 
anything (unless they need to communicate with other poor souls that got 
assigned EZIP addresses), however everyone else would. This is not a 
good balance. The customers would experience an internet where almost 
nothing works. It would be magnitudes worse than the experience of an 
IPv6 only network with NAT64.


It is a fix for the wrong problem. Major ISPs have IPv6 support now. It 
is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 
why would you expect them to deploy EZIP? Why would some old forgotten 
site with old song texts in some backwater country somewhere?


We already have better solutions such as CGN with dual stack, NAT64, 
DS-Lite, MAP etc.


None of that is discussed in the RFC. Is the author aware of it?

Regards,

Baldur




Den 06/03/2017 kl. 09.08 skrev Joly MacFie:

To say that Mr. Chen's EZIP proposal has not, thus far, been received with
open arms by the networking community would be an understatement. It is
seen as delaying the inevitable and introducing an impractical extra
routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
to give him the opportunity to expound on its merits.
​ We'd welcome some expert respondents.​

​See: ​
https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00


​==========​

WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen

On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter
(ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y.
Chen, VP of Engineering, Avinta Communications, will present his EzIP
proposal to reinvigorate the diminishing pool of IPv4 addresses.
​Optional registration
  at the link below. This will be recorded.

What: WEBINAR: Can We Make IPv4 Great Again?
When: Tuesday March 8 2017 Noon EST | 17:00 UTC
Register + info: https://www.meetup.com/isoc-ny/events/238164448/
Computer: https://zoom.us/j/914492141
Phone: http://bit.ly/zoomphone
​ ​
ID: 914 492 141
Twitter: #ezip

​​










Permalink

http://isoc-ny.org/p2/9031








--
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Leo Bicknell]

In a message written on Mon, Mar 06, 2017 at 12:16:32PM -0500, 
valdis.kletni...@vt.edu wrote:
> Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
> Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

Valdis is just spouting a bunch of fake requirements.  It's all
lies folks.  I mean the thing is called "EZIP", the EZ is right in
the name.  We're going to drain that IETF swamp of all their so-called
experts and make sure simple proposals like this that regular people
can understand get a fair shot.  It's going to change the Internet,
bigly.

And, what about the e-mails?  I mean, come on, what are those SMTP
people hiding?

[For the humor impared, it's a joke folks.]

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


signature.asc
Description: PGP signature

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[valdis . kletnieks]

On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:

> routing hardware layer that will be hit & miss. Nevertheless, since much of
> the world is still IPv4 dependent, it just could take off.

For it to "take off", the very same people who have dragged their heels
deploying IPv6 will need to suddenly jump up and upgrade all their gear
and personnel to support a *third* protocol.

Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

What's the business case for all these stakeholders to buy into EZIP?  For
both the "We already do IPv6" and "We don't do IP6v" cases?


pgp_q5lYaF_Pe.pgp
Description: PGP signature

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Joly MacFie]

I believe that. However it behooves us to give any of our members' ideas a
fair hearing. I'm hoping he'll get some good push back in the session.

Joly MacFie
j...@punkcast.com 218 565 9365

On Mar 6, 2017 11:14 AM, "William Herrin"  wrote:

> On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie  wrote:
> > To say that Mr. Chen's EZIP proposal has not, thus far, been received
> with
> > open arms by the networking community would be an understatement. It is
> > seen as delaying the inevitable and introducing an impractical extra
> > routing hardware layer that will be hit & miss. Nevertheless, since much
> of
> > the world is still IPv4 dependent, it just could take off. ISOC-NY is
> happy
> > to give him the opportunity to expound on its merits.
> > We'd welcome some expert respondents.
> >
> > See:
> > https://tools.ietf.org/html/draft-chen-ati-ipv4-with-
> adaptive-address-space-00
>
> Hi Joly,
>
> If something like this was going to happen, we could have expanded the
> v4 address space to 64 bits with IPxl:
> http://bill.herrin.us/network/ipxl.html
>
> At this point IPv6 has enough momentum that it can be safely expected
> to happen. That means all proposals for extending the IPv4 address
> space are basically dead in the water, especially complicated ones.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie  wrote:
> To say that Mr. Chen's EZIP proposal has not, thus far, been received with
> open arms by the networking community would be an understatement. It is
> seen as delaying the inevitable and introducing an impractical extra
> routing hardware layer that will be hit & miss. Nevertheless, since much of
> the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
> to give him the opportunity to expound on its merits.
> We'd welcome some expert respondents.
>
> See:
> https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00

Hi Joly,

If something like this was going to happen, we could have expanded the
v4 address space to 64 bits with IPxl:
http://bill.herrin.us/network/ipxl.html

At this point IPv6 has enough momentum that it can be safely expected
to happen. That means all proposals for extending the IPv4 address
space are basically dead in the water, especially complicated ones.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Joly MacFie]

To say that Mr. Chen's EZIP proposal has not, thus far, been received with
open arms by the networking community would be an understatement. It is
seen as delaying the inevitable and introducing an impractical extra
routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
to give him the opportunity to expound on its merits.
​ We'd welcome some expert respondents.​

​See: ​
https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00


​==========​

WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen

On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter
(ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y.
Chen, VP of Engineering, Avinta Communications, will present his EzIP
proposal to reinvigorate the diminishing pool of IPv4 addresses.
​Optional registration
 at the link below. This will be recorded.

What: WEBINAR: Can We Make IPv4 Great Again?
When: Tuesday March 8 2017 Noon EST | 17:00 UTC
Register + info: https://www.meetup.com/isoc-ny/events/238164448/
Computer: https://zoom.us/j/914492141
Phone: http://bit.ly/zoomphone
​ ​
ID: 914 492 141
Twitter: #ezip

​​










Permalink

http://isoc-ny.org/p2/9031








--
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-