
IPv6 is no longer considered optional - thefox
http://www.blog.bt.com/viewpoint/index.php/2012/04/23/ipv6ietf/
======
ajb
The irony is that pretty much all the silicon out there has supported IPv6 for
the last 10 years, and what's holding it up is the software.

This is because when you design a chip, you have to take into account what
your customers will be using it for in a few years time, but for software,
it's all about what your customers want yesterday. Since IPV6 has always been
'just around the corner', it gets into the hardware but not all the software.

~~~
revelation
Its not clear what level of 'hardware' you are talking about.

For most gadgets, the only hardware related to networking you will find is a
chip that does ethernet and talks to the jack for you. Everything above (like
IP) is done in software.

~~~
ajb
I'm talking about routers, from the big devices in your datacentre/telco down
to your dsl or cable home gateway. There's only a limited amount I can say
about this ( at least, without having to think hard about I am allowed to say)
but there really is a lot of silicon out there that knows what the layout of
an IP packet is.

~~~
ashconnor
Router firmware and software is still software no?

~~~
ajb
Yes, that's right.

------
lrem
I wonder if a declaration like this will have _any_ practical impact...

------
islon
So now they consider it not optional? I guess it took so long because they
were thinking ipv4 would magically generate more ip numbers... The internet
should be all ipv6 by now.

------
drucken
Why do I get the feeling that there will never be a pure IPv6 solution.

It does not seem possible to create a pure and complete IPv6 NAT solution. But
NAT is way too useful and taken for granted to be removed. I honestly cannot
believe they did not address this specifically during the standard's process!
Why not learn from the past?

Are Teredo-like 6-within-4 solutions the only future?

~~~
lloeki
> But NAT is way too useful and taken for granted to be removed

NAT is not useful, firewalls are.

NAT merely swaps an address for another in the outgoing IP packet, recording
the connection, and doing the inverse op on incoming packets matching the
record. It's actually called _IP masquerading_ , and it does not protect you
of anything.

Without a firewall rule that drops incoming packets, outside can readily reach
your internal network with the proper route (your router already knows how to
route external/internal, since it's its very role), even with NAT. The exact
same incoming packet drop rule can readily be used with IPv6. And you can
punch holes in the firewall for your internal services the same way you always
did, you just don't need address swapping part anymore, nor "port forwarding",
since all machines have all ports to them. In fact, the firewall stack
actually gets two rules added each time you define a "port forwarding": the
firewall rule to not drop the packet, and the NAT rule to forward it. Guess
what forwards natively packets to the correct IPs? _Routing_. And that's
precisely the purpose of NAT: being able to route IPs not meant to be routed
in the first place, virtually extending the IP address space by having LAN
machines sharing one address. The thing is, every IPv6 address is routable†,
hence NAT simply has no purpose in IPv6.

The only real problem is that people have been framed to think that NAT is how
things work. The truth is, having no NAT anymore is a _bliss_. Everything is
easier, from DMZ routing to authorization to abuse handling, mostly because
many issues, limitations, and extra work vanish.

PS: and don't start me on "NAT is good at using a single IP to connect to your
machines". That's what DNS is for.

† except local-scoped addresses, but those are constrained to the link, since
they are automatically assigned by the machine itself, and made to provide
_automatic peer-to-peer link-local connectivity only_. By design, having only
a link-local address means you have no internet connectivity whatsoever.

~~~
rlpb
The problem is that firewalling is difficult for the same reason that NAT is
difficult.

For example: my SIP hardware phone has a publicly addressable IP address. I'd
like to firewall it such that it can only talk to my ISP's SIP server and
other parties authorised by it. How do I do this? The firewall must deep-
packet inspect SIP packets to work out what point-to-point RTP traffic should
be allowed, and only allow this. This difficulty does not change even in an
IPv6 world.

I wrote about this problem last year:
[http://www.synctus.com/blog/2011/04/why-ipv6-will-not-
solve-...](http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-the-
nat-problem)

~~~
lloeki
> The problem is that firewalling is difficult for the same reason that NAT is
> difficult.

The problems you exemplify are not ipv4 or ipv6 problems, they are purely
firewall problems. As you state in the article, people conflate NAT and
firewall, but I fear you are too slightly mixing them in a way in your article
(at least that's how it reads). NAT-PMP and UPnP are tools that do two things:

    
    
        - setup port forwarding for knowing where to NAT incoming packets
        - setup firewall not to drop incoming WAN packets on that port
    

Incredibly enough, drop the NAT part, and the firewall part works just fine.
Only for IPv6 it will be:

    
    
        - setup firewall not to drop incoming WAN packets on that port and for that destination
    

which is just awesome since there will be no port conflict possible, and no
port scarcity on the router. It would be downright trivial to extend NAT-
PMP/UPnP IGD daemons (if that's not done already) to support that case, and I
don't know the details but the protocols themselves might not even need to be
modified, as the simple fact of communicating over IPv4/IPv6 might just be
sufficient to gather all the required informations.

EDIT: actually the NAT-PMP draft[0] makes mention of IPv6

EDIT: a quick search for UPnP IGD IPv6 leads to a presentation[1] about IGD:2,
which includes IPv6 gateway firewall control.

[0] <http://files.dns-sd.org/draft-cheshire-nat-pmp.txt>

[1]
[http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032...](http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf)

------
TazeTSchnitzel
Let's hope device manufacturers add IPv6. Particularly for routers and phones.

------
mjwalshe
Its still a poor standard that should have died decades ago

~~~
mkup
Since you didn't propose a better standard during these decades, IPv6 is
likely to stay. Why it's poor btw?

~~~
rwmj
What they really should have done is extend IPv4 addresses using an option
header in packets, which (with a small amount of effort) provides a fall-back
and is nowhere near as disruptive as trying to enable IPv6 everywhere.

~~~
zmb_
In theory, perhaps. In reality this is not feasible because the hardware guys
would never go for it. The mere existence of an IPv4 header extension causes a
packet to be kicked out of the hardware fast path (or dropped entirely) by all
the router implementations that I know.

