IPv6 Deployment for the LAN

Tony Hain alh-ietf at tndh.net
Thu Oct 22 19:41:20 UTC 2009

David Conrad wrote:
> > Ok, lets start with not breaking the functionality we have today
> > in IPv4.  Once you get that working again we can look at new
> > ideas (like RA) that might have utility. Let the new stuff live/die
> on
> > it's own merits.  The Internet is very good at sorting out the useful
> > technology from the crap.
> Right.  I'll admit some confusion here.  If the IETF, due to religion
> or aesthetics, is blocking attempts at making DHCPv6 do what network
> operators _need_ (as opposed to want), why haven't network operators
> routed around the problem and gone and funded folks like ISC,
> NLNetLabs, Cisco, Juniper, et al., to implement what they need?
> > At conferences I keep hearing "It would be great if the IETF had
> > more operator input."  Yet whenever we try to provide operationally
> > useful advice we are ridiculed for not being smart enough to know
> > how things should work.
> >
> > How do we fix that?
> You seem to be asking "how do we make people not stupid".  Folks tend
> to simplify reality so that it fits their world view.  Stupid people
> attempt to force that simplified reality onto others.  You can either
> play their game, attempting to get them to understand reality is often
> more complicated than we'd like, or route around them.  Or you can post
> to NANOG... :-)

The root of the argument I see in this entire thread is the assumption that
'what we have for IPv4 has *always* been there'. There is lots of finger
pointing at the IETF for failure to define 15 years ago, what we have
evolved as the every-day assumptions about the IPv4 network of today. SLAAC
was presented specifically to deal with the DHCP failure modes of the time,
and the very real possibility that DHCP might not make it as a technology
that operators would want to deploy. While lots of evolution happened in the
DHCP space to deal with changing operational requirements, it is still a
complex approach (which may be why it is favored by those that like to
maintain a high salary).  To be fair, there were failures in the IETF, as
the SLAAC and DCHP sides couldn't get out of each other's way; so now
instead of having 2 independent models for provisioning, we have 2
interdependent models. RFC 5006 is one step at breaking that
interdependence, and more are needed on the DHCPv6 side, yet these steps
can't happen if people sit in the corner and do the 'they won't listen to
me' routine. 

For those that insist that DHCP is 'the only way to know who is using an
address', have you considered dDNS? Oh wait, that moves the trust point to a
different service that in the enterprise is typically run by the host admin,
not the network admin, or in the SP case crosses the trust boundary in the
wrong direction ... my bad. Seriously, there are ways to figure this out, as
Ron Broersma pointed out on Monday. I am not arguing for one model over the
other, as they each have their benefits and trade-offs. The real issue here
is that some people are so locked into one approach that they refuse to even
consider that there might be an alternative way to achieve the same goal, or
that the actual goal will change over time in the face of external

IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no
different. The fact that there is not functional parity between the
operational aspects is due to operators insisting until very recently that
'the only thing that matters is IPv4'. It should not be a surprise that IPv4
is where the majority of the work in the IETF happened. Despite my attempts
to get the IETF to stop wasting effort on what is clearly a dead-end, this
is still true today. As drc points out, you can continue to post complaints
on the nanog list, or if you want real change make sure your vendors get a
clear message about IPv6 being the priority, then make your point on the
appropriate IETF WG list.

At the end of the day, the way networks are operated today is not the way
they will be operated in 5 years, just as it is not the same as they way
they were operated 5 year ago. Asserting a snap-shot perspective about
'requirements' has its place, but everyone needs to recognize that this is
an evolving environment. Changing the base protocol version is just one more
step on that evolutionary path. 


More information about the NANOG mailing list