North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

  • From: Mike Leber
  • Date: Wed May 30 15:28:38 2007

Correction, 3ffe:80a::/64 was the old PAIX Palo Alto exchange address.

BTW, Jeroen does have a valid beef, [email protected] used to not be handled by
our normal engineering staff.  It was somebody's part time side project.  
This has changed with the migration of our IPv6 network into our core.
Since IPv6 is available via all core routers for customers on the same
links as their IPv4 connection, all Hurricane network engineers are now
required to be able take care of issues with it.

On Wed, 30 May 2007, Mike Leber wrote:
> On Wed, 30 May 2007, Jeroen Massar wrote:
> > [let me whine again about this one more time... *sigh*]
> > [guilty parties in cc + public ml's so that every body sees again that
> > this is being sent to you so that you can't deny it... *sigh again*]
> 
> Actually appreciated, as the only sessions with 3ffe link addresses (less
> than you can count on one hand) are with networks that haven't responded
> to previous emails from us to renumber, and hopefully now something will
> be done.  It will all get sorted out anyway as we've recently completed a
> network wide core router upgrade and moved IPv6 into our core, and IPv6
> BGP sessions over tunnels are deprecated and being replaced with native
> sessions.  (BTW for observers, he isn't talking about 3ffe prefix
> announcements, he is talking about a left over 3ffe::/127 address used on
> a link.)
> 
> BTW, here is our IPv6 peering information for anybody with a IPv6 BGP
> tunnel with us, we would be happy to migrate you to native sessions (send
> email to [email protected] to get sessions setup):
> 
> NAP             Status  Speed   IPv4           IPv6
> --------------- ------- ------- -------------- ------------------------
> EQUINIX-ASH     UP      10GigE  206.223.115.37 2001:504:0:2::6939:1
> EQUINIX-CHI     UP      GigE    206.223.119.37 2001:504:0:4::6939:1
> EQUINIX-DAL     UP      GigE    206.223.118.37 2001:504:0:5::6939:1
> EQUINIX-LAX     UP      GigE    206.223.123.37 2001:504:0:3::6939:1
> EQUINIX-SJC     UP      10GigE  206.223.116.37 2001:504:0:1::6939:1
> LINX            UP      10GigE  195.66.224.21  2001:7f8:4:0::1b1b:1
> LINX            UP      GigE    195.66.226.21  2001:7f8:4:1::1b1b:2
> LoNAP           UP      GigE    193.203.5.128  2001:7f8:17::1b1b:1
> AMS-IX          UP      10GigE  195.69.145.150 2001:7f8:1::a500:6939:1
> NL-IX           UP      GigE    194.153.154.14 2001:7f8:13::a500:6939:1
> PAIX Palo Alto  UP      10GigE  198.32.176.20  2001:504:d::10
> NYIIX           UP      10GigE  198.32.160.61  2001:504:1::a500:6939:1
> LAIIX           UP      GigE    198.32.146.50  2001:504:a::a500:6939:1
> PAIX New York   PENDING
> DE-CIX          PENDING
> NOTA            PENDING
> SIX             PENDING
> 
> 
> > Iljitsch van Beijnum wrote:
> > > 
> > > On 30-mei-2007, at 13:23, Nathan Ward wrote:
> > > 
> > >>> I can't seem to reach www.ietf.org over IPv6 these days and I have to
> > >>> wait 10 seconds before I fall back to IPv4.
> > [..]
> > 
> > > I think what's going on is that packets from www.ietf.org don't make it
> > > back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and
> > > TCP sessions don't connect so it's not a PMTUD problem. So it's an
> > > actual timeout.
> > 
> > I also just started noticing this, that is, that it does not work. And
> > there is a very simple explanation for this: 6bone space.
> > 
> > As a lot of people might recall, the 6bone was shutdown on 6/6/6.
> > Still there are folks who are definitely not running anything
> > operational or who care at all about the state of their network, if
> > they did they would not be using it now would they?
> > 
> > As this is what I found on the way from $US -> $IE
> > 
> >  7  2001:470:0:1f::2  112.131 ms  108.949 ms  108.316 ms
> >  8  2001:470:0:9::2  109.864 ms  112.767 ms  111.586 ms
> >  9  3ffe:80a::c  111.118 ms  86.010 ms  86.648 ms
> > 10  2001:450:2001:1000:0:670:1708:1225  193.914 ms  194.640 ms  194.976 ms
> > 
> > And what do we see: 6bone space and still in use.
> > 
> > As a lot of places correctly filter it out, the PMTU's get dropped, as
> > they are supposed to be dropped.
> 
> Just the same as you would expect to see if somebody was using 10.0.0.0/8
> address space for a link.  Similarly discouraged, though done on occasion.
> 
> > The whois.6bone.net registry is fun of course:
> > 
> > inet6num:     3FFE:800::/24
> > netname:      ISI-LAP
> > descr:        Harry Try IPv6
> > country:      CA
> > 
> > Fortunately it still also has:
> > 
> > ipv6-site:    ISI-LAP
> > origin:       AS4554
> > descr:        LAP-EXCHANGE
> >               Los Angeles
> > country:      US
> > 
> > Which matches what GRH has on list for it: Bill.
> > 
> > Now I have a very very very simple question:
> > 
> > Can you folks finally, a year after the 6bone was supposed to be
> > completely gone, renumber from out that 6bone address space that you
> > are not supposed to use anymore?
> >
> > That most likely will resolve the issues that a lot of people are
> > seeing. Or should there be another 6/6/7 date which states that
> > de-peering networks which are still announcing/forwarding 6bone space
> > should become into effect?
> 
> Would you similarly disconnect a nonresponsive customer because they used
> a /30 from RFC1918 space on a point to point link with you?
> 
> BTW, I do agree that the links involved should be renumbered immediately.
> 
> Considering we are in the business of providing connectivity, the thought
> of tearing down the session as opposed to gracefully getting rid of them
> didn't cross our mind.
> 
> > Of course, Neustar, who are hosting www.ietf.org, might also want to
> > look for a couple of extra transit providers who can provide them with
> > real connectivity to the rest of the world.
> 
> That won't renumber Bill Manning's links if that is the problem you are
> trying to fix.
> 
> If somebody helps Bill with his IPv6 config, please remove the 3ffe prefix
> announcement as it is still there, we just happen to be filtering it.
> 
> Mike.
> 
> +----------------- H U R R I C A N E - E L E C T R I C -----------------+
> | Mike Leber           Direct Internet Connections   Voice 510 580 4100 |
> | Hurricane Electric     Web Hosting  Colocation       Fax 510 580 4151 |
> | [email protected]                                       http://www.he.net |
> +-----------------------------------------------------------------------+
> 

+----------------- H U R R I C A N E - E L E C T R I C -----------------+
| Mike Leber           Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric     Web Hosting  Colocation       Fax 510 580 4151 |
| [email protected]                                       http://www.he.net |
+-----------------------------------------------------------------------+