nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sun Apr 25 22:13:17 CDT 2010
On Mon, 26 Apr 2010 12:31:51 +0930
Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
> On Mon, 26 Apr 2010 09:32:30 +1000
> Matthew Palmer <mpalmer at hezmatt.org> wrote:
> > On Mon, Apr 26, 2010 at 08:20:33AM +0930, Mark Smith wrote:
> > > On Sun, 25 Apr 2010 13:21:16 -0400
> > > Richard Barnes <richard.barnes at gmail.com> wrote:
> > >
> > > > Moreover, the general point stands that Mark's problem is one of bad
> > > > ISP decisions, not anything different between IPv4/RFC1918 and IPv6.
> > >
> > > My example, although a bit convoluted to demonstrate a point, is about
> > > robustness against Internet link failure. I don't think people's
> > > internal connectivity should be dependent on their Internet link being
> > > available and being assigned global address space. That's what the
> > > global only people are saying.
> > >
> > > (how is the customer going to access the CPE webserver to enter ISP
> > > login details when they get the CPE out of the box, if hasn't got
> > > address space because it hasn't connected to the ISP ...)
> > I've been using IPv6 for about 18 seconds, and even *I* know the answer to
> > that one -- the link-local address.
> Ever tried to ping a link local address?
> If you've been using IPv6 for only 18 seconds, probably not. Try it
> some time, hopefully you'll work out what the issue with using LLs is.
To make it easier, here's a clue:
$ ip -6 route show | grep fe80
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev tun6to4 proto kernel metric 256 mtu 1472 advmss 1412 hoplimit 4294967295
fe80::/64 dev pan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
(eth1 is my wired/wireless LAN, tun6to4 is my IPv6 6to4 tunnel, and pan0 is my bluetooth LAN)
> > - Matt
> > --
> > "You are capable, creative, competent, careful. Prove it."
> > -- Seen in a fortune cookie
More information about the NANOG