alh-ietf at tndh.net
Tue Feb 17 22:14:57 UTC 2009
Owen DeLong wrote:
> On Feb 17, 2009, at 11:28 AM, Tony Hain wrote:
> > While people frequently claim that auto-config is optional, there are
> > implementations (including OS-X) that don't support anything else at
> > this
> > point. The basic message is that you should not assume that the host
> > implementations will conform to what the network operator would
> > prefer, and
> > you need to test.
> I can configure OS-X statically, so, that simply isn't true.
> What is true is that there are many implementations which do not (yet)
> support DHCPv6. That is not the same as "don't support anything
Fair enough about OS-X, but that is not the only non-dhcpv6 implementation
out there. How exactly do you configure a static address on a sensor with no
My point was 'don't assume', & test.
> > One last comment (because I hear "just more bits" a lot in the *nog
> > community)... Approach IPv6 as a new and different protocol. If you
> > approach
> > it as "IPv4 with more bits", you will trip over the differences and
> > pissed off. If you approach it as a "different protocol with a name
> > that
> > starts with IP" and runs alongside IPv4 (like we used to do with
> > decnet,
> > sna, appletalk...), you will be comforted in all the similarities.
> > You will
> > also hear lots of noise about 'lack of compatibility', which is just
> > another
> > instance of refusing to recognize that this is really a different
> > protocol.
> > At the end of the day, it is a packet based protocol that moves
> > payloads
> > around.
> The problem here, IMHO, stems from the fact that unlike DECnet,
> Appletalk, SNA, et. al., IPv6 is intended as a replacement for
> IPv4. (None of the other protocols was ever intended to replace
> any of the others).
> As a replacement, the IETF realized that at the current scale of the
> internet when they began designing IPv6, a flag day conversion
> (like what happened when we went to IPv4) was not possible.
> Unfortunately, the migration plan set forth by the IETF made many
> assumptions (especially on vendor preparedness and rate of
> adoption prior to IPv4 runout) that have not proven out, so, the
> "Everyone who has IPv4 starts running dual-stack before we
> need any IPv6 only connectivity" plan is not going to prove out.
> More unfortunately, there is no real contingency plan for how
> migration happens absent that scenario and we are, therefore,
> in for some interesting times ahead.
Whine, whine, whine... we are where we are, and no amount of whining will
change the fact that people outside of Japan chose not to think ahead. The
primary point of dual-stack was to decouple the requirement for the end
systems to change all the apps at once. Most of the *nog community doesn't
get, or care to get, the costs of the end system operations staff because
they are focused on the costs related to moving the bits around. There are
tunneling functions defined, so you don't have to get 'dual-stack
everywhere' before you can take another step. Those are not as 'efficient'
as dual-stack when moving the bits around, and require operational
management, but that is a cost trade-off that can be made. People that
insist on delivering only one version will force unnatural acts at the edge,
while delivering both will allow people to move at their own pace.
Like it or not, the end systems are moving without the *nog community. Fire
up uTorrent and see how many 6to4 & teredo connected peers you end up with
(I am generally seeing about 1/4-1/3 of the set). This is 'real dual-stack
at the edge', and works around the laggard ISP deployments. The Internet was
built by tunneling over the laggard telco's using the voice technology
available, and the next generation of it will be built the same way if the
*nog community buries its head in the same dark place that the telco's did.
More information about the NANOG