Subject: Re: RE: RE: one data point regarding native IPv6 support

From: [email-masked] (Noel Chiappa)
Date: Mon, 13 Jun 2011 11:41:36 -0400 (EDT)

> From: Cameron Byrne <[email-masked]>

    > The data (ripe ...) overwhelming proves default-on 6to4 clients +
    > thinly deployed relays = unreliable ipv6 and ipv6 deployment obstacle.

And how is making the protocol historic going to affect broken stuff that's
already been deployed (which is what is causing those observed problems) - or,
to put it more precisely, how is changing the protocol's label going to have
_more_ effect (i.e. above and beyond) than putting out a document which says
'here are some problems with using this, don't use this unless you know what
you're doing'?

    > I believe there is data to show this time is different (iana and apnic
    > are exhausted, successful v6day, docsis 3.0 and LTE deployment ...

I am personally dubious, since although technically we're now formally out of
space, I suspect we're just going to transition from a period in which it was
somewhat difficult to get IPv4 space [convincing an RIR you needed it] to
more difficult [acquiring space from a current holder] - that is, for those
organizations which don't already have space stockpiled. And that, along with
somewhat greater use of NAT - which has, of course, been keeping the Internet
functional for well over a decade) - will be the approach the market prefers.

We'll see, though, won't we?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 27 Jun 2011 16:41:06 -0400 (EDT)

> From: Ole Troan <[email-masked]>

    >> IPv6 Neighbour Discovery is just the thing. I gather it's turned
    >> off on 6to4 links

    > IPv6 Neighbour Discovery requires a multicast capable link and
    > support for link-local addresses.

Well, RFC-4861 does say:

  Unless specified otherwise ... this document applies to all link types.
  ... it is possible that on some link types (e.g., Non-Broadcast
  Multi-Access (NBMA) links), alternative protocols or mechanisms to
  implement those services will be specified ... services described in
  this document that are not directly dependent on multicast, such as
  Redirects, Next-hop determination, Neighbor Unreachability Detection,
  etc., are expected to be provided as specified in this document. 

6to4 (especially anycast 6to4) should/would be considered an NBMA link,
and the spec does say (for such links):

  Redirect, Neighbor Unreachability Detection and next-hop determination
  should be implemented as described in this document.

So I don't see that it's wildly inappropriate.

    > NUD could be made to work, but I don't think NUD is any better than
    > any other connectivity test. e.g. a "BFD echo" style one as

I only suggested doing reachability detection by turning on ND as an simple,
easy way to do it - one would avoid having to write a bunch of code (which one
would have to, in order to use, say, an ICMPv6 ping based mechaniam).

But this isn't the right place for a detailed discussion - which is probably
OBE anyway - so I will leave it there.

	Noel