
IPv4 Declared Historic – Draft - nyan4
https://datatracker.ietf.org/doc/draft-howard-sunset4-v4historic/
======
azdle
Everyone take note that this is an individual v0 draft, it says "Type: Active
Internet-Draft (individual)" and "Intended status: Standards Track". Before
this becomes and RFC (if it ever does at all) it has to go through discussions
as an individual draft, then it has to be voted to become standards track, at
which point it will become a working group draft where it goes through more
comments, editing, and waiting, and only then does it become an official RFC.
To give you an idea of the time scale this is talking about, see that this
version of this draft expires in September.

This is in no way some proclamation that IPv4 is no more, it's more like the
obituaries that news papers have sitting around for public figures just in
case they die. The IETF isn't quick at getting RFCs published, and it
definitely won't be with something as big as this.

~~~
zurn
It's not voting exactly at the IETF, they nominally reject it[1].
Approximately it goes through the relevant working group (without voting but
by "rough consensus"), IESG, various reviews and RFC editor.

[1] “We reject kings, presidents, and voting. We believe in rough consensus
and running code” - Dave Clark, quoted by [http://arstechnica.com/tech-
policy/2011/01/25-years-of-ietf-...](http://arstechnica.com/tech-
policy/2011/01/25-years-of-ietf-setting-standards-without-kings-or-votes/) for
example

------
forgottenpass
Good. The longer we build as if v4 isn't legacy support, the more drawn-out
and uglier the already uncomfortable transition will be.

------
betaby
IPv4 reminds me non-Unicode applications from 90s Or ATM, or frame-relay or
IPX, or SNA, or 16bit DOS apps. All above were gone eventually. SAme going to
happen with IPv4, but I guess at slower rate.

~~~
Aloha
Frame Relay and ATM are still very much living, so are non-Unicode
applications, SNA and 16-bit DOS applications a little less so, IPX I think is
all but dead however.

------
__david__
It's interesting to see this looks like it was drafted by a Time Warner Cable
employee, and yet my twc internet still doesn't support IPv6. Though it gives
me hope that maybe it's coming soon?

~~~
nandhp
If your equipment is all IPv6-capable, you may just need to have swap out your
modem. Time Warner Cable has achieved 100% IPv6 availability (possibly
excluding certain phone customers):

[http://www.timewarnercable.com/en/support/faqs/faqs-
internet...](http://www.timewarnercable.com/en/support/faqs/faqs-
internet/ipv6/why-don_t-i-have-ipv6-yet-.html)

~~~
jepler
.. except no static ipv6 even for commercial / business class users? wt---

~~~
wtallis
What's the point? The addresses TWC assigns are extremely stable in my
experience. Are you trying to run a public-facing DNS server or do you have
some other need to hard-code IP addresses?

~~~
abstractbeliefs
Well, DNS needs you to "hard"code the IP addresses you are available at
against your domains.

Before you suggest DDNS, for some companies, the length of unavailability
between a changed IP and the DDNS client noticing and updating can be fatal.

~~~
pyvpx
why are they hosting services on their dynamically addressed business line?
everyone offers static addressing on business lines. it's a completely rip
off; and conveniently makes the proper route -- colocation, a dedicated
server, "the cloud" \-- more financially sound.

------
sparky_
This feels optimistically premature.

Sure, it's been superseded, and it's great to move the ball forward. But
somehow I think this legacy technology will be in use for a long, long time.

~~~
rmetzler
I think the same, IPv4 isn't going anywhere soon.

~~~
lisivka
Sorry, but containerization and SDN needs addresses. I can spawn dozen of
networks on my computer using docker/flannel/kubernetes, but I have only 1
white IPv4 address for all of them, so I need to use NAT and step-stone
server. I have no such limitation with IPv6: each host has it own white IPv6
address and addressing becomes flat. Sorry, but I have no choice, so I use
IPv6 today.

------
sergioocon
Wow, I released and RFI 12 years ago on IPv6 when I was working in a Telco,
and every vendor talked about it as a reality... I am still waiting for that
reality to be an actual one. I am still waiting for my ISP to activate IPv6 in
my WLAN at home... after all those years

------
kazinator
> _Current and future work builds on IPv6, making it better for every purpose
> than the old protocol._

Not for purposes like:

* I want the IP header I'm transmitting between these two nodes to be as small as possible

* I want a CPU and memory efficient TCP/IP stack for an embedded system.

Pretty much no successor of anything is better than its predecessor for "every
purpose", just every purpose that the speaker happens to care about.

~~~
virtuallynathan
IPv6 headers should be easier to parse than IPv4.

------
chatmasta
I know it pains neckbeards to hear this, but IPv4 is not going anywhere, as
long as it remains in the business interests of major cloud providers, and as
long as people continue to deploy NAT based firewalls as a security feature.

Re: business interests: Cloud businesses can acquire IP addresses at price
points far higher than the average developer can. Now that the ARIN address
space is exhausted, cloud providers will begin to buy more and more IPv4 space
until they have a complete monopoly and large portions of IPv4 are controlled
by just a few companies. This will price other companies out of offering cloud
services that are IPv4 compatible.

Re: security: Sure, the original intended purpose of NAT was not security, but
people _use_ it for that, and will continue to do so. If you want to put
multiple boxes behind a single IP address, IPv4 is the easiest way to do it.
In fact, IPv6 seems to be a step _backward_ in terms of security. Every device
does not need to be openly addressable from anywhere on the Internet, and
developers will always choose the path of least resistance, especially when
it's more secure.

~~~
api
_NAT is not a security feature. Please stop repeating this toxic drivel._

NAT is not the same as firewalls, and firewalls do not require NAT. NAT is
just an ugly hack to stretch IPV4's inadequate address space, and it's one
that breaks quite a few protocols and generally makes a lot of things painful
and complex.

Remember back when there were two dozen different networking layers vying for
the ability to link Docker containers? (There still are, but Docker's hype
wave has crested so you don't see them every 5 minutes on here.) With IPv6 and
no NAT, _none of that is necessary._ Just give every container a real address,
set your firewall rules accordingly, and every container anywhere can talk
directly to every other container _without any added complexity_. Give each
container host a /96 address and let it assign container IPs from the
remaining /32, for up to four billion containers per host. Since IPv6
specifies that an ISP should hand out /64's to customers, each customer can
have 4 billion container hosts.

Getting rid of NAT makes everything orders of magnitude simpler.

I do wonder about monopoly resistance. I wonder if IPv6 has been shunned by
Amazon, Google, and Microsoft clouds because they see a long term advantage in
preventing adoption. IPv6 makes peer to peer systems a lot easier to build,
and peer to peer is direct competition to the 'run absolutely everything
through the cloud' model. IPv6 could actually reduce the cloud's importance
(especially for data transit) if it were widely deployed.

~~~
chatmasta
I didn't say NAT is a security feature. I said developers use NAT to benefit
security. The security benefit of NAT is that it forces developers to assign a
predictable, private IP address to each device/container/vm/box behind its
"firewall," which the gateway can then use for enforcing QoS policies or port
whitelisting. Sure, you can do this on IPv6. But IPv6 is more complicated to
implement, because all tools support IPv4, and only some support IPv6.

~~~
api
How does that help security?

IPv6 has usability problems (I've written on this), but these are unrelated to
security in any direct way.

The reason I call it toxic is that the idea that NAT helps security is a
harmful superstition that spooks people about IPv6 adoption. It's also driven
some to actually implement IPv6 NAT, which is kind of like strapping a horse
feed bag on the front of your car.

There's a _ton_ of superstition and cargo cultism in network security, since
most people -- even developers -- don't understand much about how networks
work.

~~~
yusyusyus
NAT is so painful. Even the specs are written with grossly overloaded
terminology.

>The reason I call it toxic is that the idea that NAT helps security is a
harmful superstition that spooks people about IPv6 adoption.

In all fairness, the common NAT implementation involves L4 params and the
requisite state for ingress traffic. It makes like a filter that is "drop any"
with respect to the NAT IP address (with the exception of in-state traffic).
Further, it also limits the IP protocols available. Example, you will not
likely be doing SCTP across your NAT and certainly it would be difficult to
send directed OSPF packets during this[0] fun thing. It still leaves things to
be done (like dropping internal IP space traffic on the external IFs), but the
requisite components supply a lot.

I think I've seen the problem though. In general, network engineers have
failed to break down the components of NAT: 1) State, 2) Rewrite, 3) A filter
dropping traffic not matched by state. Fundamentally, the only thing we need
to do in IPv6 is 1) state and 2) a filter. Their failure, combined with the
packaging of components that NAT provides, feeds the valid points of the
superstition while neglecting the details (what happens when we look at too
big of a picture, or philosophical thing).

>It's also driven some to actually implement IPv6 NAT, which is kind of like
strapping a horse feed bag on the front of your car.

The ignorance of management and "netwerk sekurity esperts" aside, NAT does
have use cases in IPv6. Example, if we're performing renumbering frequently,
does it make operational sense to roll over prefixes with RAs/DHCP? Maybe the
expectation is for multiple prefix advertisement, but then which IP should be
used for internal vs. external? Should all applications always rely on DNS?
What are the implications for routing networks that may be designed with
separate number spaces? The reasons for why these things may be done are not
absolutely "wrong" or "bad design" and should not necessarily adopt a purist
model.

[0][https://tools.cisco.com/security/center/content/CiscoSecurit...](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-
sa-20130801-lsaospf)

