RE: IPv6 Confusion

["Tony Hain" <alh-ietf () tndh net>]

David Conrad wrote:
> Tony,
>
> On Feb 17, 2009, at 12:17 PM, Tony Hain wrote:
> > This being a list of network engineers, there is a strong bias
> > toward tools
> > that allow explicit management of the network. This is a fine
> > position, and
> > those tools need to exist. There are others that don't want, or need
> > to know
> > about every bit on the wire, where 'as much automation as possible'
> > is the
> > right set of tools.
>
> No question.  However, as this is a list of network engineers who are
> the folks who need to deploy IPv6 in order for others who may not care
> about every bit on the wire to make (non-internal) use of it, I'd
> think the bias displayed here something that might carry some weight.

Automated tunneling works around those who choose not to deploy native
support.

> > Infighting at the IETF kept the RA from informing the
> > end systems about DNS, and kept DHCPv6 from informing them about
> their
> > router. The result is that you have to do both DHCP & RA, when each
> > should
> > be capable of working without the other.
>
> Yeah.  Rants about the IETF should probably be directed elsewhere.

That was not a rant, just an informational observation.

> > As far as dnssec, while the question is valid, blaming the IPv6
> > design for
> > not considering something that 10+ years later is still not
> > deployed/deployable, is a bit of a stretch.
>
> Uh, no.  That's not what I was saying.  I was saying that stateless
> auto-configuration made certain assumptions about how naming and
> addressing worked that weren't necessarily well thought out (clients
> updating the reverse directly in a DNSSEC-signed environment was just
> an example).  Perhaps it's just me, but it feels like there was a
> massive case of NIH syndrome in the IPv6 working groups that network
> operators are now paying the price for.  However, as I said, rants
> about the IETF should probably be directed elsewhere.

Actually this should be flipped as a rant against the *nog community. If you
didn't participate in defining it, you can't complain about the outcome. The
only way the IETF works well is with an active feedback loop that injects
operational reality into the process. That used to exist in the joman WG,
but stopped when the *nogs splintered off and stopped participating. I can
already hear Randy complaining about being shouted down, and yes that
happens, but that is really a call for -more- active voices, not
disengagement. The bottom line is, if you want something to be defined in a
way that works for you, you have to participate in the definition. 

> > > Or, we simply continue down the path of more NATv4.
> > While this is the popular position, those that have thought about it
> > realize
> > that what works for natv4 at the edge, does not work when that nat
> > is moved
> > toward the core.
>
> Yeah, multi-layer NAT sucks.  I was amazed when I was speaking with
> some African ISPs that had to go this way today because their telecoms
> regulatory regime required them to obtain addresses from the national
> PTT and that PTT only gave them a single address.  I would argue that
> if we want to avoid this outcome (and make no mistake, there are those
> who like this outcome as it means end users are only content
> consumers, which fits into their desired business models much more
> nicely), we need to make IPv6 look more like IPv4 so that network
> operators, end users, content providers, network application
> developers, etc., have minimal change in what they do, how they do it,
> or how they pay for it. Part of that is getting familiar tools (e.g.,
> DHCP, customer provisioning, management, etc.) working the way it
> works in IPv4.  Taking advantage of all the neato features IPv6 might
> provide can come later.

People have to stand up and put money on the table if they expect things to
get fixed. The working parts of IPv6 that exist are due to the ISPs in Japan
and the US DoD putting their money where their mouth is, and they got what
they needed. The *nog community appears to be holding their breath waiting
for 1:1 parity before they start, which will never happen.

> However, I have a sneaking suspicion it might already be too late...

CGN will be deployed, but can be used as a tool to wean customers off of
IPv4. If the world goes the way of current-price==IPv6+CGN, with
IPv6+publicIPv4 costing substantially more, there will be a drop off in use
of IPv4 because the CGN breaks lots of stuff and people won't pay extra to
work around it for any longer than they need to. 

Tony