From ryan at u13.net  Sat Aug  8 03:51:17 2009
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 07 Aug 2009 21:51:17 -0400
Subject: IPv6 cogentco.com
Message-ID: <4A7CDA15.604@u13.net>

ryan at vps-mon01:~$ host cogentco.com
cogentco.com has address 38.100.128.10
cogentco.com has IPv6 address 2001:550:1::cc01

Can anyone actually reach them via the v6 address?  I get timeouts from 
anywhere I have tried it so far (various points on Hurricane Electric's 
network).

From md at Linux.IT  Sat Aug  8 03:55:14 2009
From: md at Linux.IT (Marco d'Itri)
Date: Sat, 8 Aug 2009 03:55:14 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <4A7CDA15.604@u13.net>
References: <4A7CDA15.604@u13.net>
Message-ID: <20090808015514.GA31011@bongo.bofh.it>

On Aug 08, Ryan Rawdon <ryan at u13.net> wrote:

> Can anyone actually reach them via the v6 address?  I get timeouts from  
Yes, but they still do not have a complete routing table (nor did they
deliver "experimental IPv6" by the end of june as the salesperson
announced us).

-- 
ciao,
Marco

From lambert at psc.edu  Sat Aug  8 04:50:02 2009
From: lambert at psc.edu (Michael Lambert)
Date: Fri, 7 Aug 2009 22:50:02 -0400
Subject: IPv6 cogentco.com
In-Reply-To: <4A7CDA15.604@u13.net>
References: <4A7CDA15.604@u13.net>
Message-ID: <1DA9967F-FF2C-4750-8800-F72DBCE9A596@psc.edu>

On 7 Aug 2009, at 21:51, Ryan Rawdon wrote:

> ryan at vps-mon01:~$ host cogentco.com
> cogentco.com has address 38.100.128.10
> cogentco.com has IPv6 address 2001:550:1::cc01
>
> Can anyone actually reach them via the v6 address?  I get timeouts  
> from anywhere I have tried it so far (various points on Hurricane  
> Electric's network).

Yep.  We're getting them via Global Crossing:

pscnoc at bar> show route 2001:550:1::cc01 table inet6.0

inet6.0: 2124 destinations, 4181 routes (2123 active, 0 holddown, 1  
hidden)
+ = Active Route, - = Last Active, * = Both

2001:550::/32      *[BGP/170] 01:39:13, MED 3790, localpref 60, from  
2001:5e8:0:1::1:fd
                       AS path: 11537 3549 174 I
                     > to fe80::2d0:63ff:fec5:ea80 via ge-1/2/0.1
                     [BGP/170] 1d 22:37:15, MED 5541, localpref 50,  
from 2001:5e8::5
                       AS path: 3549 174 I
                     > to fe80::205:8501:407:881f via ge-4/3/0.0

Michael


From ryan at u13.net  Sat Aug  8 04:53:09 2009
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 07 Aug 2009 22:53:09 -0400
Subject: IPv6 cogentco.com
In-Reply-To: <1DA9967F-FF2C-4750-8800-F72DBCE9A596@psc.edu>
References: <4A7CDA15.604@u13.net>
	<1DA9967F-FF2C-4750-8800-F72DBCE9A596@psc.edu>
Message-ID: <4A7CE895.1020906@u13.net>

Thanks to everyone for the on and off-list replies.  It sounds like it 
must be a HE-specific issue (or Cogent is in the DFZ without a route to 
HE for some reason).

Ryan

On 8/7/09 10:50 PM, Michael Lambert wrote:
> On 7 Aug 2009, at 21:51, Ryan Rawdon wrote:
>
>> ryan at vps-mon01:~$ host cogentco.com
>> cogentco.com has address 38.100.128.10
>> cogentco.com has IPv6 address 2001:550:1::cc01
>>
>> Can anyone actually reach them via the v6 address?  I get timeouts 
>> from anywhere I have tried it so far (various points on Hurricane 
>> Electric's network).
>
> Yep.  We're getting them via Global Crossing:
>
> pscnoc at bar> show route 2001:550:1::cc01 table inet6.0
>
> inet6.0: 2124 destinations, 4181 routes (2123 active, 0 holddown, 1 
> hidden)
> + = Active Route, - = Last Active, * = Both
>
> 2001:550::/32      *[BGP/170] 01:39:13, MED 3790, localpref 60, from 
> 2001:5e8:0:1::1:fd
>                       AS path: 11537 3549 174 I
> > to fe80::2d0:63ff:fec5:ea80 via ge-1/2/0.1
>                     [BGP/170] 1d 22:37:15, MED 5541, localpref 50, 
> from 2001:5e8::5
>                       AS path: 3549 174 I
> > to fe80::205:8501:407:881f via ge-4/3/0.0
>
> Michael
>


From tony at lava.net  Sat Aug  8 05:11:24 2009
From: tony at lava.net (Antonio Querubin)
Date: Fri, 7 Aug 2009 17:11:24 -1000 (HST)
Subject: IPv6 cogentco.com
In-Reply-To: <4A7CDA15.604@u13.net>
References: <4A7CDA15.604@u13.net>
Message-ID: <Pine.BSI.4.64.0908071710010.20710@malasada.lava.net>

On Fri, 7 Aug 2009, Ryan Rawdon wrote:

> ryan at vps-mon01:~$ host cogentco.com
> cogentco.com has address 38.100.128.10
> cogentco.com has IPv6 address 2001:550:1::cc01
>
> Can anyone actually reach them via the v6 address?  I get timeouts from 
> anywhere I have tried it so far (various points on Hurricane Electric's 
> network).

Not from here.

tony at guriguri:~> telnet cogentco.com www
Trying 2001:550:1::cc01...
^C
tony at guriguri:~> traceroute cogentco.com
traceroute to cogentco.com (38.100.128.10), 64 hops max, 40 byte packets
  1  iiwi-fe-0-0-0 (64.65.64.30)  0.531 ms  0.386 ms  0.344 ms
  2  Serial2-11.GW1.HNL2.ALTER.NET (157.130.203.185)  2.048 ms  0.303 ms 
1.017 ms
^C
tony at guriguri:~> traceroute6 cogentco.com
traceroute6 to cogentco.com (2001:550:1::cc01) from 
2001:1888:0:1:2d0:b7ff:fe7d:bed6, 64 hops max, 12 byte packets
  1  apapane-fe0-0-1  0.965 ms  0.811 ms  0.601 ms
  2  2600:80a:50f::1  67.277 ms  68.067 ms  67.191 ms
  3  0.lo0.BR6.PAO1.ALTER.NET  78.531 ms  83.464 ms  78.218 ms
  4  paix.ipv6.he.net  75.634 ms  79.328 ms  75.412 ms
  5  10gigabitethernet1-1.core1.lax1.he.net  85.013 ms  85.042 ms  88.020 
ms
  6  10gigabitethernet4-3.core1.nyc4.he.net  147.363 ms  145.719 ms 
144.870 ms
  7  10gigabitethernet1-2.core1.nyc1.he.net  150.376 ms  152.758 ms 
163.749 ms
  8  f0-0.nyc.ipv6.he.net  155.217 ms  148.220 ms  147.253 ms
  9  * *
     2001:470:0:5c::2  179.061 ms !P
^C

Tony
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net

From berni at birkenwald.de  Sat Aug  8 11:19:40 2009
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Sat, 08 Aug 2009 11:19:40 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <4A7CDA15.604@u13.net>
References: <4A7CDA15.604@u13.net>
Message-ID: <4A7D432C.6080106@birkenwald.de>

Ryan Rawdon wrote:

> ryan at vps-mon01:~$ host cogentco.com
> cogentco.com has address 38.100.128.10
> cogentco.com has IPv6 address 2001:550:1::cc01
> 
> Can anyone actually reach them via the v6 address?  I get timeouts from 
> anywhere I have tried it so far (various points on Hurricane Electric's 
> network).

Cogent probably goes for the transit-free gig, but only seems to peer 
with GBLX, NTT and UPC so far according to GRH.

traceroute to cogentco.com (2001:550:1::cc01) from 2001:1b10:100:3::1:2, 
port 33434, from port 50360, 30 hops max, 60 byte packets
  1  backbone1-gige-0-3-15.teleport-iabg.de (2001:1b10:100:3::11)  0.453 ms
  2  mchn-s1-rou-1030.DE.eurorings.net (2001:680:0:800f::a)  0.627 ms
  3  ffm-s1-rou-1030.eurorings.net (2001:680::134:222:84:72)  9.076 ms
  4  2001:450:2002:c1::1 (2001:450:2002:c1::1)  9.517 ms
  5  2001:550:3::d (2001:550:3::d)  166.032 ms
  6  te8-2.mpd01.sjc01.atlas.cogentco.com (::ffff:154.54.6.237)  242.218 ms
  7  te7-2.mpd01.lax01.atlas.cogentco.com (::ffff:154.54.6.29)  242.355 ms
  8  te3-8.mpd01.iah01.atlas.cogentco.com (::ffff:154.54.2.197)  242.316 ms
  9  te3-7.mpd01.atl01.atlas.cogentco.com (::ffff:154.54.5.201)  242.204 ms
10  te9-4.mpd01.dca01.atlas.cogentco.com (::ffff:154.54.1.226)  242.170 ms
11  te8-1.mpd01.dca02.atlas.cogentco.com (::ffff:154.54.1.70)  242.390 ms
12  2001:550:1::1 (2001:550:1::1)  242.587 ms
13  cogentco.com (2001:550:1::cc01)  242.332 ms

The latency is a mess of course, but I can reach it just fine.

Bernhard

From martin at airwire.ie  Sat Aug  8 11:28:29 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Sat, 08 Aug 2009 10:28:29 +0100
Subject: IPv6 cogentco.com
In-Reply-To: <20090808015514.GA31011@bongo.bofh.it>
References: <4A7CDA15.604@u13.net> <20090808015514.GA31011@bongo.bofh.it>
Message-ID: <4A7D453D.4000909@airwire.ie>

Marco d'Itri wrote:
> On Aug 08, Ryan Rawdon <ryan at u13.net> wrote:
> 
>> Can anyone actually reach them via the v6 address?  I get timeouts from  
> Yes, but they still do not have a complete routing table (nor did they
> deliver "experimental IPv6" by the end of june as the salesperson
> announced us).
> 

They send the contracts out, which have been returned by us, but it's
not been provisioned yet.

Ment to chase the sales guy on that.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From tore at linpro.no  Sat Aug  8 11:56:26 2009
From: tore at linpro.no (Tore Anderson)
Date: Sat, 08 Aug 2009 11:56:26 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <4A7D432C.6080106@birkenwald.de>
References: <4A7CDA15.604@u13.net> <4A7D432C.6080106@birkenwald.de>
Message-ID: <4A7D4BCA.4070502@linpro.no>

* Bernhard Schmidt

> Cogent probably goes for the transit-free gig, but only seems to peer
> with GBLX, NTT and UPC so far according to GRH.

There is a few others as well, notably Google.  This is the list of
unique as-paths (first two ASNs only) I see matching community 174:21..0
in Oslo today, first column is the prefix count:

    444 174 3549
    260 174 2914
     11 174 15169
      3 174 34997
      2 174 6830
      2 174 209
      1 174 8412
      1 174 8220

They've promised me they'll have a complete table by the end of the year.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From swmike at swm.pp.se  Sat Aug  8 12:07:10 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 8 Aug 2009 12:07:10 +0200 (CEST)
Subject: IPv6 cogentco.com
In-Reply-To: <4A7D4BCA.4070502@linpro.no>
References: <4A7CDA15.604@u13.net> <4A7D432C.6080106@birkenwald.de>
	<4A7D4BCA.4070502@linpro.no>
Message-ID: <alpine.DEB.1.10.0908081205410.5006@uplift.swm.pp.se>

On Sat, 8 Aug 2009, Tore Anderson wrote:

> They've promised me they'll have a complete table by the end of the 
> year.

Kind of strange procedure to enable IPv6 on ones website when one knows 
there isn't even close to full reachability.

>From Tele2 we can't reach them over IPv6.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From herlianto at gmail.com  Sun Aug  9 10:22:33 2009
From: herlianto at gmail.com (Herlianto)
Date: Sun, 9 Aug 2009 11:22:33 +0300
Subject: IPV6 BGP flapping caused by duplicate OSPFV3 router ID
Message-ID: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>

Hi All,

We have deployed IPV6 over IPV4 tunnel, but at some site we facing the
problem for BGP and OSPFV3.

The BGP Flapping and at the log there is command as shown below :
Aug  9 08:08:39.089: %OSPFv3-4-DUP_RTRID_AREA: Detected router with
duplicate router ID x.x.x.x in area 0
Aug  9 08:09:46.644: %OSPFv3-4-DUP_RTRID_AREA: Detected router with
duplicate router ID x.x.x.x in area 0

for OSPF V3  with the command : #show ipv6 ospf neighbor there is some
different interface tunnel but the neighbor ID is same

Is there any experience and any suggestion to solve it ?

Thanks for your kind attention and cooperation.
-- 


_H e r l y_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090809/e4830c66/attachment.html 

From mleber at he.net  Sun Aug  9 11:41:08 2009
From: mleber at he.net (Mike Leber)
Date: Sun, 09 Aug 2009 02:41:08 -0700
Subject: IPV6 BGP flapping caused by duplicate OSPFV3 router ID
In-Reply-To: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
References: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
Message-ID: <4A7E99B4.7020001@he.net>


While not necessarily your problem, make sure you add IPv6 addresses to 
your router loopback interfaces, just like you do for IPv4.

Also make sure to add IPv6 addresses for any interfaces you enable IPv6 
on, otherwise they may come up in OSFP with IPv6 link local addresses.

(Just mentioning these two because I've seen stuff like this before.)

Though you almost certainly do, if you don't have a loopback interface 
configured and you run OSPF, you should read about why you want one (the 
OSPF and BGP tutorials for Cisco and lots of other vendors cover this).
(This also can cause the problem you mention below if you happen to have 
multiple routers configured for either anycast or you use the same 
RFC1918 IP for an internal well known service like caching DNS.  i.e. no 
loopback means the same IP may be picked on multiple routers as the 
router ID if you have the same IP on multiple routers.)

Mike.

Herlianto wrote:
> Hi All,
> 
> We have deployed IPV6 over IPV4 tunnel, but at some site we facing the 
> problem for BGP and OSPFV3.
> 
> The BGP Flapping and at the log there is command as shown below :
> Aug  9 08:08:39.089: %OSPFv3-4-DUP_RTRID_AREA: Detected router with 
> duplicate router ID x.x.x.x in area 0
> Aug  9 08:09:46.644: %OSPFv3-4-DUP_RTRID_AREA: Detected router with 
> duplicate router ID x.x.x.x in area 0
> 
> for OSPF V3  with the command : #show ipv6 ospf neighbor there is some 
> different interface tunnel but the neighbor ID is same
> 
> Is there any experience and any suggestion to solve it ?
> 
> Thanks for your kind attention and cooperation.
> -- 
> 
> 
> _H e r l y_

-- 
+---------------- H U R R I C A N E - E L E C T R I C ----------------+
| Mike Leber        Wholesale IPv4 and IPv6 Transit      510 580 4100 |
| Hurricane Electric                                           AS6939 |
| mleber at he.net     Internet Backbone & Colocation      http://he.net |
+---------------------------------------------------------------------+


From tony at lava.net  Sun Aug  9 13:16:23 2009
From: tony at lava.net (Antonio Querubin)
Date: Sun, 9 Aug 2009 01:16:23 -1000 (HST)
Subject: IPV6 BGP flapping caused by duplicate OSPFV3 router ID
In-Reply-To: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
References: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
Message-ID: <alpine.OSX.1.00.0908090107030.133@cust11794.lava.net>

On Sun, 9 Aug 2009, Herlianto wrote:

> We have deployed IPV6 over IPV4 tunnel, but at some site we facing the
> problem for BGP and OSPFV3.
>
> The BGP Flapping and at the log there is command as shown below :
> Aug  9 08:08:39.089: %OSPFv3-4-DUP_RTRID_AREA: Detected router with
> duplicate router ID x.x.x.x in area 0
> Aug  9 08:09:46.644: %OSPFv3-4-DUP_RTRID_AREA: Detected router with
> duplicate router ID x.x.x.x in area 0
>
> for OSPF V3  with the command : #show ipv6 ospf neighbor there is some
> different interface tunnel but the neighbor ID is same
>
> Is there any experience and any suggestion to solve it ?

If you run multiple 6to4 gateway routers make sure 192.88.99.1 is not 
being selected as the default router ID.  Pick one interface whose address 
you do want to use as the router ID and then lock that down in both the 
OSPF, OSPFv3, and BGP configs as the router ID.  You may want to use your 
loopback interface address for this.

router ospf nn
  router-id a.a.a.a
router bgp xxxxx
  bgp router-id a.a.a.a
ipv6 router ospf mm
  router-id a.a.a.a

Tony
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net

From prickman at upcbroadband.com  Sun Aug  9 18:26:56 2009
From: prickman at upcbroadband.com (Rickman, Phil)
Date: Sun, 9 Aug 2009 18:26:56 +0200
Subject: IPV6 BGP flapping caused by duplicate OSPFV3 router ID
In-Reply-To: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
References: <e128472b0908090122x519aed88o9ac4e9cfc87fc82d@mail.gmail.com>
Message-ID: <C118CB386E772145997A81F7A8B7258F25992850C4@AMS2PMS3001.upcit.ds.upc.biz>

are you sure you are not hitting this bug or another version of it?
Bug ID:
CSCdu71404



Phil Rickman
NDA

DD - 89969
Mob:  +31 610847604
________________________________
From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Herlianto [herlianto at gmail.com]
Sent: 09 August 2009 10:22
To: ipv6-ops at lists.cluenet.de
Subject: IPV6 BGP flapping caused by duplicate OSPFV3 router ID

Hi All,

We have deployed IPV6 over IPV4 tunnel, but at some site we facing the problem for BGP and OSPFV3.

The BGP Flapping and at the log there is command as shown below :
Aug  9 08:08:39.089: %OSPFv3-4-DUP_RTRID_AREA: Detected router with duplicate router ID x.x.x.x in area 0
Aug  9 08:09:46.644: %OSPFv3-4-DUP_RTRID_AREA: Detected router with duplicate router ID x.x.x.x in area 0

for OSPF V3  with the command : #show ipv6 ospf neighbor there is some different interface tunnel but the neighbor ID is same

Is there any experience and any suggestion to solve it ?

Thanks for your kind attention and cooperation.
--


_H e r l y_

From tedm at ipinc.net  Mon Aug 10 19:22:22 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 10 Aug 2009 10:22:22 -0700
Subject: IPv6 cogentco.com
In-Reply-To: <4A7CDA15.604@u13.net>
References: <4A7CDA15.604@u13.net>
Message-ID: <4A80574E.8080406@ipinc.net>

Ryan Rawdon wrote:
> ryan at vps-mon01:~$ host cogentco.com
> cogentco.com has address 38.100.128.10
> cogentco.com has IPv6 address 2001:550:1::cc01
> 
> Can anyone actually reach them via the v6 address?  I get timeouts from 
> anywhere I have tried it so far (various points on Hurricane Electric's 
> network).

We have a Looking Glass that you can use to look this up:

http://whois.ipinc.net/cgi-bin/lg.pl

as do many other ISPs.  And no, they aren't in our table.

Hopefully someone can CC this to the NANOG list.

Ted

From tedm at ipinc.net  Mon Aug 10 19:25:33 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 10 Aug 2009 10:25:33 -0700
Subject: IPv6 cogentco.com
In-Reply-To: <alpine.DEB.1.10.0908081205410.5006@uplift.swm.pp.se>
References: <4A7CDA15.604@u13.net>
	<4A7D432C.6080106@birkenwald.de>	<4A7D4BCA.4070502@linpro.no>
	<alpine.DEB.1.10.0908081205410.5006@uplift.swm.pp.se>
Message-ID: <4A80580D.6040802@ipinc.net>

Mikael Abrahamsson wrote:
> On Sat, 8 Aug 2009, Tore Anderson wrote:
> 
>> They've promised me they'll have a complete table by the end of the year.
> 
> Kind of strange procedure to enable IPv6 on ones website when one knows 
> there isn't even close to full reachability.
> 

I see you've never had the pleasure of doing business with Cogentco.

I'd be surprised if this WASN'T the case.

At least they ARE trying, gotta give them some credit for that.
Compared to many networks out there, that's a huge advance.

Ted

From ryan at u13.net  Mon Aug 10 20:35:54 2009
From: ryan at u13.net (Ryan Rawdon)
Date: Mon, 10 Aug 2009 14:35:54 -0400
Subject: IPv6 cogentco.com
In-Reply-To: <4A80574E.8080406@ipinc.net>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net>
Message-ID: <b0e77d68768f7cad563596a36656e372@192.168.152.50>


I'm merely a lurker on NANOG and am not subscribed to NANOG-POST, if
someone else wanted to CC this discussion over to NANOG, that could be
beneficial.

On Mon, 10 Aug 2009 10:22:22 -0700, Ted Mittelstaedt <tedm at ipinc.net>
wrote:
> Ryan Rawdon wrote:
>> ryan at vps-mon01:~$ host cogentco.com
>> cogentco.com has address 38.100.128.10
>> cogentco.com has IPv6 address 2001:550:1::cc01
>> 
>> Can anyone actually reach them via the v6 address?  I get timeouts from 
>> anywhere I have tried it so far (various points on Hurricane Electric's 
>> network).
> 
> We have a Looking Glass that you can use to look this up:
> 
> http://whois.ipinc.net/cgi-bin/lg.pl
> 
> as do many other ISPs.  And no, they aren't in our table.
> 
> Hopefully someone can CC this to the NANOG list.
> 
> Ted

From gdolley at arpnetworks.com  Tue Aug 11 03:22:16 2009
From: gdolley at arpnetworks.com (Garry Dolley)
Date: Mon, 10 Aug 2009 18:22:16 -0700
Subject: IPv6 cogentco.com
In-Reply-To: <4A80574E.8080406@ipinc.net>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net>
Message-ID: <20090811012216.GA10227@garry-thinkpad.arpnetworks.com>

On Mon, Aug 10, 2009 at 10:22:22AM -0700, Ted Mittelstaedt wrote:
> Ryan Rawdon wrote:
>> ryan at vps-mon01:~$ host cogentco.com
>> cogentco.com has address 38.100.128.10
>> cogentco.com has IPv6 address 2001:550:1::cc01
>> Can anyone actually reach them via the v6 address?  I get timeouts from 
>> anywhere I have tried it so far (various points on Hurricane Electric's 
>> network).
>
> We have a Looking Glass that you can use to look this up:
>
> http://whois.ipinc.net/cgi-bin/lg.pl
>
> as do many other ISPs.  And no, they aren't in our table.
>
> Hopefully someone can CC this to the NANOG list.

2001:550::/32 isn't in my table either.

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st

From ethern at ascc.net  Tue Aug 11 03:41:33 2009
From: ethern at ascc.net (Ethern M., Lin)
Date: Tue, 11 Aug 2009 09:41:33 +0800
Subject: IPv6 cogentco.com
In-Reply-To: <20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net> 
	<20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
Message-ID: <8582c31a0908101841y29e52aadyfe506c4b8521de53@mail.gmail.com>

Here is the traceroute info from Taiwan:

% traceroute6 www.cogentco.com
traceroute6 to cogentco.com (2001:550:1::cc01) from
2001:c08:0:11:207:e9ff:fe15:adae, 64 hops max, 12 byte packets
 1  2001:c08:0:11::1:1  4.176 ms  4.677 ms  3.490 ms
 2  2001:c08:7f:1::1  0.667 ms  0.570 ms  0.490 ms
 3  2001:c08:7f:10::a  0.639 ms  0.696 ms  0.421 ms
 4  2001:c08:7f::2e  0.482 ms  0.471 ms  0.458 ms
 5  2001:c08:7f::21  30.764 ms  30.740 ms  30.705 ms
 6  2001:200:0:fe00::1253:0  30.902 ms  30.840 ms  30.793 ms
 7  lan-gate.jpnap.otemachi4.v6.dti.ad.jp  30.946 ms  30.869 ms  30.918 ms
 8  fa-1-3-2.a13.tokyjp01.jp.ra.gin.ntt.net  160.871 ms  160.892 ms  160.800 ms
 9  ae-3.a21.tokyjp01.jp.ra.gin.ntt.net  153.910 ms  153.511 ms  153.472 ms
10  ae-8.r20.tokyjp01.jp.bb.gin.ntt.net  268.867 ms  153.612 ms  159.711 ms
11  as-1.r20.snjsca04.us.bb.gin.ntt.net  153.830 ms  153.670 ms
ae-3.r20.osakjp01.jp.bb.gin.ntt.net  161.012 ms
12  as-2.r20.snjsca04.us.bb.gin.ntt.net  160.795 ms
po-1.r04.snjsca04.us.bb.gin.ntt.net  153.859 ms  153.936 ms
13  * * *

However it can't be reached through ping:

% ping6 www.cogentco.com
PING6(56=40+8+8 bytes) 2001:c08:0:11:207:e9ff:fe15:adae --> 2001:550:1::cc01
^C
--- cogentco.com ping6 statistics ---
62 packets transmitted, 0 packets received, 100.0% packet loss

Using telnet to test the connectivity:

% telnet www.cogentco.com 80
Trying 2001:550:1::cc01...
telnet: connect to address 2001:550:1::cc01: Operation timed out
Trying 38.100.128.10...
Connected to cogentco.com.
Escape character is '^]'.

The conclusion is: the IPv6 connectivity to Cogent is failed from Taiwan.


cheers,
Ethern

=============================
Ethern Lin <ethern at ascc.net>
Network Division
Computing Center, ACADEMIA SINICA
Phone: +886-2-2789-9953
Fax  : +886-2-2783-6444
=============================



On Tue, Aug 11, 2009 at 9:22 AM, Garry Dolley<gdolley at arpnetworks.com> wrote:
> On Mon, Aug 10, 2009 at 10:22:22AM -0700, Ted Mittelstaedt wrote:
>> Ryan Rawdon wrote:
>>> ryan at vps-mon01:~$ host cogentco.com
>>> cogentco.com has address 38.100.128.10
>>> cogentco.com has IPv6 address 2001:550:1::cc01
>>> Can anyone actually reach them via the v6 address? ?I get timeouts from
>>> anywhere I have tried it so far (various points on Hurricane Electric's
>>> network).
>>
>> We have a Looking Glass that you can use to look this up:
>>
>> http://whois.ipinc.net/cgi-bin/lg.pl
>>
>> as do many other ISPs. ?And no, they aren't in our table.
>>
>> Hopefully someone can CC this to the NANOG list.
>
> 2001:550::/32 isn't in my table either.
>
> --
> Garry Dolley
> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
> Data center, VPS, and IP Transit solutions
> Member Los Angeles County REACT, Unit 336 | WQGK336
> Blog http://scie.nti.st
>

From mtinka at globaltransit.net  Tue Aug 11 05:19:44 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Tue, 11 Aug 2009 11:19:44 +0800
Subject: IPv6 cogentco.com
In-Reply-To: <20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net>
	<20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
Message-ID: <200908111120.05796.mtinka@globaltransit.net>

On Tuesday 11 August 2009 09:22:16 am Garry Dolley wrote:

> 2001:550::/32 isn't in my table either.

Not in our tables either on this side (Malaysia); our route 
reflectors aren't happy:

#sh bgp ipv6 unicast 2001:550::/32
% Network not in table
#

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090811/52dbfbcc/attachment.bin 

From sethm at rollernet.us  Tue Aug 11 06:23:47 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 10 Aug 2009 21:23:47 -0700
Subject: IPv6 cogentco.com
In-Reply-To: <20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net>
	<20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
Message-ID: <4A80F253.4030700@rollernet.us>

Garry Dolley wrote:
> On Mon, Aug 10, 2009 at 10:22:22AM -0700, Ted Mittelstaedt wrote:
>> Ryan Rawdon wrote:
>>> ryan at vps-mon01:~$ host cogentco.com
>>> cogentco.com has address 38.100.128.10
>>> cogentco.com has IPv6 address 2001:550:1::cc01
>>> Can anyone actually reach them via the v6 address?  I get timeouts from 
>>> anywhere I have tried it so far (various points on Hurricane Electric's 
>>> network).
>> We have a Looking Glass that you can use to look this up:
>>
>> http://whois.ipinc.net/cgi-bin/lg.pl
>>
>> as do many other ISPs.  And no, they aren't in our table.
>>
>> Hopefully someone can CC this to the NANOG list.
> 
> 2001:550::/32 isn't in my table either.
> 

I can see it:

routy-core0>sh bgp ipv6 unicast 2001:550::/32
BGP routing table entry for 2001:550::/32, version 4564852
Paths: (1 available, best #1, table Global-IPv6-Table)
  Not advertised to any peer
  6435 6435 701 12702 286 3549 174, (received & used)
    2620:0:950::242:128 (metric 1) from 2620:0:950::242:128 (208.79.242.128)
      Origin IGP, metric 0, localpref 90, valid, internal, best

traceroute to www.cogentco.com (2001:550:1::cc01), 30 hops max, 40 byte
packets
 1  2620:0:950:beef::242:33  0.439 ms  0.859 ms  1.995 ms
 2  2620:0:950:c2::242:149  3.127 ms  5.007 ms  4.958 ms
 3  2620:0:950:c0::242:142  1.854 ms  1.841 ms  1.827 ms
 4  2001:1888::1:16:1  156.790 ms  156.811 ms  156.798 ms
 5  * * *
 6  * * *
 7  * * *
 8  2001:7f8::11e:0:1  254.765 ms  268.849 ms  268.821 ms
 9  2001:450:2002:c1::1  275.832 ms  261.593 ms  261.538 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *

But it doesn't work. Maybe someone is ignoring /48's (which is what I
announce) and there's no route back.

~Seth

From martin at airwire.ie  Fri Aug 14 15:25:51 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Fri, 14 Aug 2009 14:25:51 +0100
Subject: Cogent IPv6
Message-ID: <4A8565DF.4080104@airwire.ie>

Hi,

just to warm the discussion up again :)

We got the IPv6 details for our Cogent BGP session today, and yes, it's
not a full table yet.

Cogent only has 781 routes, that they advertise to ourselves, so anyone
not in there obviously would have no route to them.

Our looking glass can be found at http://lg.as42227.net/ and the Cogent
BGP session is on the Galway router. We're also on the SixXS GRH.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From oneingray at gmail.com  Fri Aug 14 16:48:56 2009
From: oneingray at gmail.com (Ivan Shmakov)
Date: Fri, 14 Aug 2009 21:48:56 +0700
Subject: NAT64 and DNS64 implementations
References: <4A1934A4.5040308@linpro.no>
Message-ID: <87iqgq1mef.fsf@violet.siamics.int>

>>>>> Tore Anderson <tore at linpro.no> writes:

 > Hi list, I've been reading the NAT64/DNS64 drafts with great interest
 > - it definitely seems like something I could successfully deploy.
 > I'd like to play around a bit with it, but I haven't been able to
 > find actual implementations so far.  Is there any?  Or is someone
 > working on it?

 > I'd prefer an open-source based solution (e.g. a BIND patch for DNS64
 > and a Linux/Netfilter target for NAT64), but I'm not picky...

	[1] reads:

--cut--
Description

    Ecdysis is aimed to develop an open-source implementation of a NAT64
    gateway to run on open-source operating systems such as Linux and
    BSD.  The gateway is comprised of two distinct modules: the DNS ALG
    and the IP translator.  The DNS ALG will be developed by modifying
    two DNS open-source server implementations: Unbound and Bind.  The
    IP translator will be developed by modifying Netfilter and PF.

...

Download

    Download the source code of Ecdysis.  Presently, it only does the
    DNS translation.  See instructions below.  License is BSD-like for
    patches, GPLv3 for the standalone.  It has been only compiled and
    tested on Linux

...

    Note that a full functional NAT64 gateway also requires the NAT64
    module itself, which is not yet implemented and is the next
    milestone of this project.  Come back later.
--cut--

	If I'd gather some spare time, I could try to put my hands on
	making a quick and dirty (user-space) NAT64.  (Albeit I'm afraid
	that implementing the TCP state machine is going to drive me
	nuts.)

[1] http://ecdysis.viagenie.ca/

-- 
FSF associate member #7257


From berni at birkenwald.de  Sun Aug 16 11:20:24 2009
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Sun, 16 Aug 2009 11:20:24 +0200
Subject: Testers wanted: isatapd Debian package
In-Reply-To: <4A4935C6.7040401@birkenwald.de>
References: <4A4935C6.7040401@birkenwald.de>
Message-ID: <20090816112024.14491wwbgaf1dpi0@webmail.birkenwald.de>

Quoting "Bernhard Schmidt" <berni at birkenwald.de>:

Hello,

> During the last few weeks I've been building and testing a  
> Debian/Ubuntu package for this daemon, the results are available in  
> my Ubuntu PPA at https://launchpad.net/~berni/+archive/ppa .  
> Although it is labeled "jaunty" the package should install/work just  
> fine on Debian stable and Ubuntu Intrepid or newer. If your network  
> has a relay running on the "Windows-Standard" isatap.<domainname> it  
> should work out-of-the-box without any configuration, otherwise you  
> need to edit /etc/default/isatapd.

FYI, mainly thanks to Marco d'Itri isatapd has landed in the Debian  
repository.

http://packages.debian.org/search?keywords=isatapd

I would be very happy to receive reports about it being used.

Regards,
Bernhard

From efraim at clues.de  Wed Aug 19 14:00:09 2009
From: efraim at clues.de (Alexander Koch)
Date: Wed, 19 Aug 2009 14:00:09 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <4A80F253.4030700@rollernet.us>
References: <4A7CDA15.604@u13.net> <4A80574E.8080406@ipinc.net>
	<20090811012216.GA10227@garry-thinkpad.arpnetworks.com>
	<4A80F253.4030700@rollernet.us>
Message-ID: <20090819120009.GA18605@deadend.argh.org>

> BGP routing table entry for 2001:550::/32, version 4564852
>   6435 6435 701 12702 286 3549 174, (received & used)

Oh. Ouch. How bad does that path look? KPN is a customer of
GX (v4) if memory serves me right, but why would they send a
route from their transit (or worse: peer) to 12702 which is
Verizon EU? And then, consequently, Verizon EU seems to send
a full table to the big brother.

Alexander,
officially scared


From kuenzler at init7.net  Wed Aug 19 14:29:58 2009
From: kuenzler at init7.net (Fredy Kuenzler)
Date: Wed, 19 Aug 2009 14:29:58 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <20090819120009.GA18605@deadend.argh.org>
References: <4A7CDA15.604@u13.net>
	<4A80574E.8080406@ipinc.net>	<20090811012216.GA10227@garry-thinkpad.arpnetworks.com>	<4A80F253.4030700@rollernet.us>
	<20090819120009.GA18605@deadend.argh.org>
Message-ID: <4A8BF046.9050803@init7.net>

Alexander Koch schrieb:
>> BGP routing table entry for 2001:550::/32, version 4564852
>>   6435 6435 701 12702 286 3549 174, (received & used)
> 
> Oh. Ouch. How bad does that path look? KPN is a customer of
> GX (v4) if memory serves me right, but why would they send a
> route from their transit (or worse: peer) to 12702 which is
> Verizon EU? And then, consequently, Verizon EU seems to send
> a full table to the big brother.

As so many v6 network tends to leak fulltable to others, without properly 
transiting them (examples: 2497, 3257, 6175 ...), such AS pathes don't 
surprise me at all.

As long as (mainly) incumbents think "we peer only v6 with existing v4 
peers", regardless of the v6 deployment of some v4 networks, there will be a 
deadlock forever.

Fredy K?nzler
Init7 / AS13030

From Thomas.Jessen at kpn.DE  Wed Aug 19 15:02:10 2009
From: Thomas.Jessen at kpn.DE (Jessen, Thomas)
Date: Wed, 19 Aug 2009 15:02:10 +0200
Subject: IPv6 cogentco.com
In-Reply-To: <20090819120009.GA18605@deadend.argh.org>
References: <4A7CDA15.604@u13.net>
	<4A80574E.8080406@ipinc.net><20090811012216.GA10227@garry-thinkpad.arpnetworks.com><4A80F253.4030700@rollernet.us>
	<20090819120009.GA18605@deadend.argh.org>
Message-ID: <7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>

Moin!

whois as-kpnv6 | grep VER
members:        AS-VERIZON-V6

Thomas,
officially not scared 

-----Original Message-----
From: ipv6-ops-bounces+ipv6-ops=eurodings.de at lists.cluenet.de
[mailto:ipv6-ops-bounces+ipv6-ops=eurodings.de at lists.cluenet.de] On
Behalf Of Alexander Koch
Sent: Wednesday, August 19, 2009 2:00 PM
To: ipv6-ops at lists.cluenet.de
Subject: Re: IPv6 cogentco.com

> BGP routing table entry for 2001:550::/32, version 4564852
>   6435 6435 701 12702 286 3549 174, (received & used)

Oh. Ouch. How bad does that path look? KPN is a customer of
GX (v4) if memory serves me right, but why would they send a
route from their transit (or worse: peer) to 12702 which is
Verizon EU? And then, consequently, Verizon EU seems to send
a full table to the big brother.

Alexander,
officially scared


From martin at airwire.ie  Wed Aug 19 21:24:02 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Wed, 19 Aug 2009 20:24:02 +0100
Subject: IPv6 cogentco.com
In-Reply-To: <7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>
References: <4A7CDA15.604@u13.net>	<4A80574E.8080406@ipinc.net><20090811012216.GA10227@garry-thinkpad.arpnetworks.com><4A80F253.4030700@rollernet.us>	<20090819120009.GA18605@deadend.argh.org>
	<7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>
Message-ID: <4A8C5152.6070909@airwire.ie>

Jessen, Thomas wrote:
> Moin!
> 
> whois as-kpnv6 | grep VER
> members:        AS-VERIZON-V6

AS701 has IPv6 (Verizon states), but filters everything < /32 incl. IXP
and PIv6 prefixes.

This looks however like AS702 is starting to get something going.

Kind regards,
Martin List-Petersen
Airwire


> 
> -----Original Message-----
> From: ipv6-ops-bounces+ipv6-ops=eurodings.de at lists.cluenet.de
> [mailto:ipv6-ops-bounces+ipv6-ops=eurodings.de at lists.cluenet.de] On
> Behalf Of Alexander Koch
> Sent: Wednesday, August 19, 2009 2:00 PM
> To: ipv6-ops at lists.cluenet.de
> Subject: Re: IPv6 cogentco.com
> 
>> BGP routing table entry for 2001:550::/32, version 4564852
>>   6435 6435 701 12702 286 3549 174, (received & used)
> 
> Oh. Ouch. How bad does that path look? KPN is a customer of
> GX (v4) if memory serves me right, but why would they send a
> route from their transit (or worse: peer) to 12702 which is
> Verizon EU? And then, consequently, Verizon EU seems to send
> a full table to the big brother.
> 
> Alexander,
> officially scared
> 


-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From nick-lists at netability.ie  Wed Aug 19 21:26:41 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Wed, 19 Aug 2009 20:26:41 +0100
Subject: IPv6 cogentco.com
In-Reply-To: <4A8C5152.6070909@airwire.ie>
References: <4A7CDA15.604@u13.net>	<4A80574E.8080406@ipinc.net><20090811012216.GA10227@garry-thinkpad.arpnetworks.com><4A80F253.4030700@rollernet.us>	<20090819120009.GA18605@deadend.argh.org>	<7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>
	<4A8C5152.6070909@airwire.ie>
Message-ID: <4A8C51F1.8050709@netability.ie>

On 19/08/2009 20:24, Martin List-Petersen wrote:
> AS701 has IPv6 (Verizon states), but filters everything<  /32 incl. IXP
> and PIv6 prefixes.

Do they still filter on /32?  Well, I guess they'll clue up at some stage.

Nick

From martin at airwire.ie  Wed Aug 19 21:31:00 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Wed, 19 Aug 2009 20:31:00 +0100
Subject: IPv6 cogentco.com
In-Reply-To: <4A8C51F1.8050709@netability.ie>
References: <4A7CDA15.604@u13.net>	<4A80574E.8080406@ipinc.net><20090811012216.GA10227@garry-thinkpad.arpnetworks.com><4A80F253.4030700@rollernet.us>	<20090819120009.GA18605@deadend.argh.org>	<7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>
	<4A8C5152.6070909@airwire.ie> <4A8C51F1.8050709@netability.ie>
Message-ID: <4A8C52F4.3070805@airwire.ie>

Nick Hilliard wrote:
> On 19/08/2009 20:24, Martin List-Petersen wrote:
>> AS701 has IPv6 (Verizon states), but filters everything<  /32 incl. IXP
>> and PIv6 prefixes.
> 
> Do they still filter on /32?  Well, I guess they'll clue up at some stage.

Last time I had the opportunity to check AS701 did. And they also
refused to let customers route their own PIv6.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From nick-lists at netability.ie  Wed Aug 19 22:17:57 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Wed, 19 Aug 2009 21:17:57 +0100
Subject: IPv6 cogentco.com
In-Reply-To: <4A8C52F4.3070805@airwire.ie>
References: <4A7CDA15.604@u13.net>	<4A80574E.8080406@ipinc.net><20090811012216.GA10227@garry-thinkpad.arpnetworks.com><4A80F253.4030700@rollernet.us>	<20090819120009.GA18605@deadend.argh.org>	<7707838BF569B24DBBDB8F54AB67B67F02EFAB97@foo.kpnqwest.de>
	<4A8C5152.6070909@airwire.ie> <4A8C51F1.8050709@netability.ie>
	<4A8C52F4.3070805@airwire.ie>
Message-ID: <4A8C5DF5.7010701@netability.ie>

On 19/08/2009 20:31, Martin List-Petersen wrote:
> Last time I had the opportunity to check AS701 did. And they also
> refused to let customers route their own PIv6.

That's good: their filtering policies conflict directly with their future 
revenue flow.  Change will happen sooner because of this.

All hail sales people.

Nick

From ipv6-ops at c0mplx.org  Mon Aug 24 11:18:19 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Mon, 24 Aug 2009 11:18:19 +0200
Subject: Cisco 2960, 12.2.50SE3, IPv6 and SNMP ?
Message-ID: <20090824091819.GJ56042@home.opsec.eu>

Hello,

I'm playing around with an Cisco 2960 switch that runs the most
recent IOS 12.2.50SE3, has its IPv6 address but does not answer
to SNMP.

I found some pointer that there is some

"Managing Cisco IOS Applications over IPv6" chapter

in the Cisco IOS IPv6 Configuration Library on Cisco.com.

I found the IPv6 Configuration Library at:

http://www.cisco.com/en/US/docs/ios/12_2t/ipv6/ipv6_vgf.html

which points to:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_mgev6.htm

but this is a dead link.

Does anyone here in this room^Wmailing-list has hints about this ?

Thanks in advance!

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From perc69 at gmail.com  Mon Aug 24 11:32:17 2009
From: perc69 at gmail.com (Per Carlson)
Date: Mon, 24 Aug 2009 11:32:17 +0200
Subject: Cisco 2960, 12.2.50SE3, IPv6 and SNMP ?
In-Reply-To: <20090824091819.GJ56042@home.opsec.eu>
References: <20090824091819.GJ56042@home.opsec.eu>
Message-ID: <746ca6da0908240232p785adfcbp73f525866c93f80f@mail.gmail.com>

Hi.

> I'm playing around with an Cisco 2960 switch that runs the most
> recent IOS 12.2.50SE3, has its IPv6 address but does not answer
> to SNMP.

Not sure about that specific platform and IOS-version, but I know this
has been an issue on other platforms. Check out CSCir01027 and the
related bug-id referenced.

-- 
Pelle

From ipv6-ops at c0mplx.org  Mon Aug 24 14:23:50 2009
From: ipv6-ops at c0mplx.org (Kurt Jaeger)
Date: Mon, 24 Aug 2009 14:23:50 +0200
Subject: Cisco 2960, 12.2.50SE3, IPv6 and SNMP ?
In-Reply-To: <746ca6da0908240232p785adfcbp73f525866c93f80f@mail.gmail.com>
References: <20090824091819.GJ56042@home.opsec.eu>
	<746ca6da0908240232p785adfcbp73f525866c93f80f@mail.gmail.com>
Message-ID: <20090824122350.GL56042@home.opsec.eu>

Hello,

> > I'm playing around with an Cisco 2960 switch that runs the most
> > recent IOS 12.2.50SE3, has its IPv6 address but does not answer
> > to SNMP.
> 
> Not sure about that specific platform and IOS-version, but I know this
> has been an issue on other platforms. Check out CSCir01027 and the
> related bug-id referenced.

Thanks. It worked flawlessly once I used the right community 8-} 

-- 
pi at opsec.eu            +49 171 3101372                        11 years to go !

From sethm at rollernet.us  Tue Aug 25 17:31:47 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 25 Aug 2009 08:31:47 -0700
Subject: VZB IPv6
Message-ID: <4A9403E3.1070307@rollernet.us>

Martin List-Petersen wrote:
>
> Last time I had the opportunity to check AS701 did. And they also
> refused to let customers route their own PIv6.
> 


I'm about to find out. I had ordered a new circuit, watched them qualify
it, and then it was delayed for several weeks due to "internal tickets".
I had given them this information (and they confirmed it) when the order
was placed:

"Turn up with BGP (full table) and announce 208.79.240.0/22 from
AS11170. We also require IPv6 (full table+announcing 2620:0:950::/48
from AS11170)."

I will let the list know what happens with regards to the IPv6 part.

~Seth

From sethm at rollernet.us  Sun Aug 30 20:42:35 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 30 Aug 2009 11:42:35 -0700
Subject: PTR records for v6 hosts
Message-ID: <4A9AC81B.40500@rollernet.us>

I'm curious as to how everyone is doing PTR records in DNS for their v6
hosts. Are you just letting autoconf hosts go without? Do you manually
create one once you know what it's autoconf address will be? Or do you
use DHCP with a predefined pool that's easy to create a PTR range for?

~Seth

From ron at spawar.navy.mil  Sun Aug 30 21:11:49 2009
From: ron at spawar.navy.mil (Ron Broersma)
Date: Sun, 30 Aug 2009 09:11:49 -1000
Subject: PTR records for v6 hosts
In-Reply-To: <4A9AC81B.40500@rollernet.us>
References: <4A9AC81B.40500@rollernet.us>
Message-ID: <84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>


On Aug 30, 2009, at 8:42 AM, Seth Mattinen wrote:

> I'm curious as to how everyone is doing PTR records in DNS for their  
> v6
> hosts. Are you just letting autoconf hosts go without? Do you manually
> create one once you know what it's autoconf address will be? Or do you
> use DHCP with a predefined pool that's easy to create a PTR range for?

We wrote a tool that regularly polls the routers, grabs the ARP and ND  
tables (using appropriate snmp MIBs), looks for all the global unicast  
IPv6 addresses in the list, and then using their MAC address we map to  
the associated IPv4 address, then use that to look up the IPv4 PTR  
record in DNS, then use that to build an IPv6 PTR record and use  
dynamic DNS update to update the zone (with various optimizations such  
as caching, garbage collection, etc).   That works well for us  
(dealing with thousands of v6 hosts on our net), although there are  
challenges with differences in how each vendor implements the v6 MIBs,  
and churn from those horrible privacy/temporary addresses [RFCs 3041,  
4941] that that all Microsoft OS's enable by default).  This, of  
course, is assuming each host has some amount of IPv4 and IPv6  
activity, but in reality it works just fine over time.

--Ron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4936 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090830/a333dc18/attachment.bin 

From stig at venaas.com  Mon Aug 31 01:26:51 2009
From: stig at venaas.com (Stig Venaas)
Date: Sun, 30 Aug 2009 16:26:51 -0700
Subject: PTR records for v6 hosts
In-Reply-To: <84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
Message-ID: <4A9B0ABB.2050201@venaas.com>

Hi Ron

Ron Broersma wrote:
> 
> On Aug 30, 2009, at 8:42 AM, Seth Mattinen wrote:
> 
>> I'm curious as to how everyone is doing PTR records in DNS for their v6
>> hosts. Are you just letting autoconf hosts go without? Do you manually
>> create one once you know what it's autoconf address will be? Or do you
>> use DHCP with a predefined pool that's easy to create a PTR range for?
> 
> We wrote a tool that regularly polls the routers, grabs the ARP and ND 
> tables (using appropriate snmp MIBs), looks for all the global unicast 
> IPv6 addresses in the list, and then using their MAC address we map to 
> the associated IPv4 address, then use that to look up the IPv4 PTR 
> record in DNS, then use that to build an IPv6 PTR record and use dynamic 
> DNS update to update the zone (with various optimizations such as 
> caching, garbage collection, etc).   That works well for us (dealing 

I've written the exact same tool :)

Stig

> with thousands of v6 hosts on our net), although there are challenges 
> with differences in how each vendor implements the v6 MIBs, and churn 
> from those horrible privacy/temporary addresses [RFCs 3041, 4941] that 
> that all Microsoft OS's enable by default).  This, of course, is 
> assuming each host has some amount of IPv4 and IPv6 activity, but in 
> reality it works just fine over time.
> 
> --Ron
> 


From martin at airwire.ie  Mon Aug 31 09:14:44 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Mon, 31 Aug 2009 08:14:44 +0100
Subject: PTR records for v6 hosts
In-Reply-To: <4A9AC81B.40500@rollernet.us>
References: <4A9AC81B.40500@rollernet.us>
Message-ID: <4A9B7864.8030303@airwire.ie>

Seth Mattinen wrote:
> I'm curious as to how everyone is doing PTR records in DNS for their v6
> hosts. Are you just letting autoconf hosts go without? Do you manually
> create one once you know what it's autoconf address will be? Or do you
> use DHCP with a predefined pool that's easy to create a PTR range for?

We let our DNS create hostnames (ptr and aaaa) on the fly/dynamically,
based on a prefix pattern. For that we used powerdns and the pipe backend.

I didn't feel like generating tons of zone files.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From Sam.Wilson at ed.ac.uk  Mon Aug 31 11:08:45 2009
From: Sam.Wilson at ed.ac.uk (Sam Wilson)
Date: Mon, 31 Aug 2009 10:08:45 +0100
Subject: PTR records for v6 hosts
In-Reply-To: <4A9B0ABB.2050201@venaas.com>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<4A9B0ABB.2050201@venaas.com>
Message-ID: <D74B67FA-515C-4997-9C74-741AEA95F9A0@ed.ac.uk>


On 31 Aug 2009, at 00:26, Stig Venaas wrote:

> Ron Broersma wrote:
>> We wrote a tool ...
>
> I've written the exact same tool :)

So which release of BIND will have this in the contrib directory?   
(Unless I've missed it already, of course.)

:-)

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From bjorn at mork.no  Mon Aug 31 11:41:32 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 31 Aug 2009 11:41:32 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil> (Ron
	Broersma's message of "Sun, 30 Aug 2009 09:11:49 -1000")
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
Message-ID: <87k50kz5f7.fsf@nemi.mork.no>

Ron Broersma <ron at spawar.navy.mil> writes:

> We wrote a tool that regularly polls the routers, grabs the ARP and ND
> tables (using appropriate snmp MIBs), looks for all the global unicast
> IPv6 addresses in the list, and then using their MAC address we map to
> the associated IPv4 address, then use that to look up the IPv4 PTR
> record in DNS, then use that to build an IPv6 PTR record and use
> dynamic DNS update to update the zone (with various optimizations such
> as caching, garbage collection, etc).   That works well for us
> (dealing with thousands of v6 hosts on our net), although there are
> challenges with differences in how each vendor implements the v6 MIBs,
> and churn from those horrible privacy/temporary addresses [RFCs 3041,
> 4941] that that all Microsoft OS's enable by default).  This, of
> course, is assuming each host has some amount of IPv4 and IPv6
> activity, but in reality it works just fine over time.

Nice solution for dual stack hosts.  But how do you plan to support IPv6
only hosts?

And does anyone have a proposal that would fit an ISP environment? Lets
say you use DHCP-PD to delegate a prefix to a customer, who is in full
control of his own "residential gateway" so you can't look up his
neigbour table.  What do you do?

- Delegate the reverse zone to the customer?  Most won't have a clue
  what to do with it.
- Provide a DDNS solution for the customer and not care whether they use
  it or not?  Most won't use it.
- Set up an IPv6 "walldns" (to borrow terminology from DJB)?  I don't
  really see the point.  How is a pointer record like
  x20010db800000000021a73fffe502834.example.com better than just not
  having a pointer?




Bj?rn

From lionel at mamane.lu  Mon Aug 31 11:53:38 2009
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Mon, 31 Aug 2009 11:53:38 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <87k50kz5f7.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no>
Message-ID: <20090831095338.GA4472@capsaicin.mamane.lu>

On Mon, Aug 31, 2009 at 11:41:32AM +0200, Bj?rn Mork wrote:
> Ron Broersma <ron at spawar.navy.mil> writes:

>> We wrote a tool that regularly polls the routers, grabs the ARP and
>> ND tables (using appropriate snmp MIBs), looks for all the global
>> unicast IPv6 addresses in the list, and then using their MAC
>> address we map to the associated IPv4 address, then use that to
>> look up the IPv4 PTR record in DNS, then use that to build an IPv6
>> PTR record (...)

> And does anyone have a proposal that would fit an ISP environment? Lets
> say you use DHCP-PD to delegate a prefix to a customer, who is in full
> control of his own "residential gateway" so you can't look up his
> neigbour table.  What do you do?

Well, given how few "residential gateway"s have a decent support for
IPv6 anyway...

> - Delegate the reverse zone to the customer?  Most won't have a clue
>   what to do with it.

I can imagine that once IPv6 support has "settled in", that will be
the standard solution, supported by most residential gateways.

-- 
Lionel

From martin at airwire.ie  Mon Aug 31 12:07:48 2009
From: martin at airwire.ie (Martin List-Petersen)
Date: Mon, 31 Aug 2009 11:07:48 +0100
Subject: PTR records for v6 hosts
In-Reply-To: <20090831095338.GA4472@capsaicin.mamane.lu>
References: <4A9AC81B.40500@rollernet.us>	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>	<87k50kz5f7.fsf@nemi.mork.no>
	<20090831095338.GA4472@capsaicin.mamane.lu>
Message-ID: <4A9BA0F4.7000202@airwire.ie>

Lionel Elie Mamane wrote:
> On Mon, Aug 31, 2009 at 11:41:32AM +0200, Bj?rn Mork wrote:
>> Ron Broersma <ron at spawar.navy.mil> writes:
> 
>>> We wrote a tool that regularly polls the routers, grabs the ARP and
>>> ND tables (using appropriate snmp MIBs), looks for all the global
>>> unicast IPv6 addresses in the list, and then using their MAC
>>> address we map to the associated IPv4 address, then use that to
>>> look up the IPv4 PTR record in DNS, then use that to build an IPv6
>>> PTR record (...)
> 
>> And does anyone have a proposal that would fit an ISP environment? Lets
>> say you use DHCP-PD to delegate a prefix to a customer, who is in full
>> control of his own "residential gateway" so you can't look up his
>> neigbour table.  What do you do?
> 
> Well, given how few "residential gateway"s have a decent support for
> IPv6 anyway...


With that attitude, you'll never get IPv6 to residential customers
deployed !!


>> - Delegate the reverse zone to the customer?  Most won't have a clue
>>   what to do with it.
> 
> I can imagine that once IPv6 support has "settled in", that will be
> the standard solution, supported by most residential gateways.


A resolution is only found, when the ISPs start to develop it. Until
now, the majority of the market has been sitting for 10 years doing
nothing waiting what everybody else is doing. That's why we're in this
situation in the first place.

To come back to the DNS solution, we hand out a PTR/AAAA record for all
IPv6 adresses (example ptr-1.mve.ipng.airwire.ie. or
ptr-1f01aaaa1231.knr.ipng.airwire.ie.). The customers can customize
these via a web-portal. DNS is handled via PowerDNS pipe backend, which
runs a custom script to deliver the results.

That works for now. The downside is, that it prevents DNSSEC from being
used, as the zone is dynamically generated.

Kind regards,
Martin List-Petersen
-- 
Airwire - Ag Nascadh Pobail an Iarthair
http://www.airwire.ie
Phone: 091-865 968

From martin at millnert.se  Mon Aug 31 12:14:15 2009
From: martin at millnert.se (Martin Millnert)
Date: Mon, 31 Aug 2009 12:14:15 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <87k50kz5f7.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no>
Message-ID: <1251713655.784.51.camel@hsa.vpn.anti>

On Mon, 2009-08-31 at 11:41 +0200, Bj?rn Mork wrote:
> Ron Broersma <ron at spawar.navy.mil> writes:
> 
<snip>
> 
> Nice solution for dual stack hosts.  But how do you plan to support IPv6
> only hosts?
> 
> And does anyone have a proposal that would fit an ISP environment? Lets
> say you use DHCP-PD to delegate a prefix to a customer, who is in full
> control of his own "residential gateway" so you can't look up his
> neigbour table.  What do you do?
> 
> - Delegate the reverse zone to the customer?  Most won't have a clue
>   what to do with it.
> - Provide a DDNS solution for the customer and not care whether they use
>   it or not?  Most won't use it.
> - Set up an IPv6 "walldns" (to borrow terminology from DJB)?  I don't
>   really see the point.  How is a pointer record like
>   x20010db800000000021a73fffe502834.example.com better than just not
>   having a pointer?
> 

Hi,

as long as you delegate a coherent prefix (and remember which one), you
can always at the bare minimum set up a wildcard match for your branch
of the ip6.arpa tree, that points to some customer name. BIND supports
this at least. You probably have to understand how labels and wildcard
matching works (see RFCs) to understand how to use it though. (I think
most people on this list do though :) )
  For forward records I believe the easiest thing to do is to let users
manage that themselves via some web application, if you have the support
for that.  We (ISP) are going to implement this soon.

And generally, I think they primary key everbody is looking for (but not
everybody can utilize, of course), is an interface's MAC address
(optionally tied to interface's owners - the host's - hostname, if you
want), not the interface's IPv4 domain name.  We are lucky enough to be
able to use L2 information ourselves, so, we're going for the MAC as a
key.  To make things better, we're just going to setup classic default
names for the addresses, but let users have the possibility to override
these names with their own names.
  Updates go via a web interface, and not DDNS. Really don't see how
anything get's better if typical stupid user's windows-hostnames, that
usually make no sense whatsoever, go into the domain name system.

Cheers,
-- 
Martin Millnert <martin at millnert.se>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090831/cce70bd9/attachment.bin 

From mohsen.souissi at nic.fr  Mon Aug 31 12:31:10 2009
From: mohsen.souissi at nic.fr (Mohsen Souissi)
Date: Mon, 31 Aug 2009 12:31:10 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <87k50kz5f7.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no>
Message-ID: <20090831103110.GC1773@kerkenna.nic.fr>

 On 31 Aug, Bj?rn Mork wrote:
 | Ron Broersma <ron at spawar.navy.mil> writes:
 | 
 | > We wrote a tool that regularly polls the routers, grabs the ARP and ND
 | > tables (using appropriate snmp MIBs), looks for all the global unicast
 | > IPv6 addresses in the list, and then using their MAC address we map to
 | > the associated IPv4 address, then use that to look up the IPv4 PTR
 | > record in DNS, then use that to build an IPv6 PTR record and use
 | > dynamic DNS update to update the zone (with various optimizations such
 | > as caching, garbage collection, etc).   That works well for us
 | > (dealing with thousands of v6 hosts on our net), although there are
 | > challenges with differences in how each vendor implements the v6 MIBs,
 | > and churn from those horrible privacy/temporary addresses [RFCs 3041,
 | > 4941] that that all Microsoft OS's enable by default).  This, of
 | > course, is assuming each host has some amount of IPv4 and IPv6
 | > activity, but in reality it works just fine over time.
 | 
 | Nice solution for dual stack hosts.  But how do you plan to support IPv6
 | only hosts?
 | 
 | And does anyone have a proposal that would fit an ISP environment? Lets
 | say you use DHCP-PD to delegate a prefix to a customer, who is in full
 | control of his own "residential gateway" so you can't look up his
 | neigbour table.  What do you do?
 | 
 | - Delegate the reverse zone to the customer?  Most won't have a clue
 |   what to do with it.
 | - Provide a DDNS solution for the customer and not care whether they use
 |   it or not?  Most won't use it.
 | - Set up an IPv6 "walldns" (to borrow terminology from DJB)?  I don't
 |   really see the point.  How is a pointer record like
 |   x20010db800000000021a73fffe502834.example.com better than just not
 |   having a pointer?


==> You may want to have a look at this I-D which is related to the
topic: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-00 (I
haven't read it yet, just browsed through).

Mohsen.

From spz at serpens.de  Mon Aug 31 12:48:32 2009
From: spz at serpens.de (S.P.Zeidler)
Date: Mon, 31 Aug 2009 12:48:32 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <87k50kz5f7.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no>
Message-ID: <20090831104831.GK13445@serpens.de>

Hi,

Thus wrote Bj?rn Mork (bjorn at mork.no):

> Nice solution for dual stack hosts.  But how do you plan to support IPv6
> only hosts?
> 
> And does anyone have a proposal that would fit an ISP environment? Lets
> say you use DHCP-PD to delegate a prefix to a customer, who is in full
> control of his own "residential gateway" so you can't look up his
> neigbour table.  What do you do?

Why would you do anything different from what you would do in the IPv4
case? Just because there are more addresses doesn't mean there are
necessarily more addresses in use that want reverse, after all.

I think if you have an answer to that you'll also have your answer
to what you want/need to do.

Generally, I'd say don't create reverse unless it is requested.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)

From bjorn at mork.no  Mon Aug 31 13:02:56 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 31 Aug 2009 13:02:56 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <20090831095338.GA4472@capsaicin.mamane.lu> (Lionel Elie Mamane's
	message of "Mon, 31 Aug 2009 11:53:38 +0200")
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no>
	<20090831095338.GA4472@capsaicin.mamane.lu>
Message-ID: <87fxb8z1nj.fsf@nemi.mork.no>

Lionel Elie Mamane <lionel at mamane.lu> writes:
> On Mon, Aug 31, 2009 at 11:41:32AM +0200, Bj?rn Mork wrote:
>> Ron Broersma <ron at spawar.navy.mil> writes:
>
>>> We wrote a tool that regularly polls the routers, grabs the ARP and
>>> ND tables (using appropriate snmp MIBs), looks for all the global
>>> unicast IPv6 addresses in the list, and then using their MAC
>>> address we map to the associated IPv4 address, then use that to
>>> look up the IPv4 PTR record in DNS, then use that to build an IPv6
>>> PTR record (...)
>
>> And does anyone have a proposal that would fit an ISP environment? Lets
>> say you use DHCP-PD to delegate a prefix to a customer, who is in full
>> control of his own "residential gateway" so you can't look up his
>> neigbour table.  What do you do?
>
> Well, given how few "residential gateway"s have a decent support for
> IPv6 anyway...

Oh, that's improving tremendously at the moment.  And both the BBF and
the IETF are working on IPv6 recommendations for these boxes.

>> - Delegate the reverse zone to the customer?  Most won't have a clue
>>   what to do with it.
>
> I can imagine that once IPv6 support has "settled in", that will be
> the standard solution, supported by most residential gateways.

Right.  Thanks for the idea.  I do have a few places where I can push
things like that.  This is maybe something for
http://www.ietf.org/id/draft-ietf-v6ops-ipv6-cpe-router-01.txt
?

It currently has

"
8.4.  DNS Support (CORE)

   For local DNS queries for configuration, the CPE Router may include a
   DNS server to handle local queries.  Non-local queries can be
   forwarded unchanged to a DNS server specified in the DNS server
   DHCPv6 option.  The local DNS server MAY also handle renumbering from
   the Service Provider provided prefix for local names used exclusively
   inside the home (the local AAAA and PTR records are updated).  This
   capability provides connectivity using local DNS names in the home
   after a Service Provider renumbering.
"

Which could easily be extended with an recommendation that the local DNS
server should provide authoritative service on the external interface
for any delegated prefixes.

However, this might be considered a security risk by some?

Another nice feature coupled with this might be a "dynamic DNS proxy"
for the forward records, where the RG could forward the AAAA
registration to some external dynamic DNS service.  Many CPEs includes
this feature for IPv4, but that is limited to registering a single link
address on the WAN interface.  For IPv6 they would need to register the
addresses of any (locally registered) host on the inside.

But I still wonder how the ISP is supposed to know when and where to
delegate the reverse zone.  I wouldn't want to just blindly delegate it
and end up having lots of lame delegations around.  So I would have to
wait for the RG to answer queries before enabling the DNS delegation.
Which I guess would be at least a few seconds after the DHCP-PD
finished.

Or maybe just enable it blindly first, accepting some lame delegations
for a while, and do a periodical scan to find delegations which should
be disabled?  Hmm, I'm going to have about a million of those...  Need
to think about this for a while.


Bj?rn

From bjorn at mork.no  Mon Aug 31 13:42:46 2009
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 31 Aug 2009 13:42:46 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <20090831104831.GK13445@serpens.de> (S. P. Zeidler's message of
	"Mon, 31 Aug 2009 12:48:32 +0200")
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no> <20090831104831.GK13445@serpens.de>
Message-ID: <877hwkyzt5.fsf@nemi.mork.no>

"S.P.Zeidler" <spz at serpens.de> writes:

> Why would you do anything different from what you would do in the IPv4
> case? 

Because we create static A and PTR records for all IPv4 addresses
allocated to residential customers.  That does not scale to IPv6.

Yes, it can be discussed whether our IPv4 policy makes sense.  It's a
rather strict interpretation of RFC 1912.  But that discussion is off
topic for this list, so please don't try :-)

We could of course have replaced the static zones with a script, as
others on this list have done.  That would a least scale.  But I do
question the usefulness, given that there is no "RFC 1912 for IPv6".

> Just because there are more addresses doesn't mean there are
> necessarily more addresses in use that want reverse, after all.

True. So the problem reduces to finding out which addresses are in use.
That doesn't make it much easier, though...

> I think if you have an answer to that you'll also have your answer
> to what you want/need to do.
>
> Generally, I'd say don't create reverse unless it is requested.

I tend to agree.  Providing customer self service scripts on a web
portal, letting those who care either fill in their host names or
request delegations, is probably sufficient.  If the customer doesn't
care, then why should I?

I read the http://tools.ietf.org/html/draft-howard-isp-ip6rdns-00 which
Mohsen Souissi pointed to, and it does not recommend transferring the
recommentations of RFC 1912 to IPv6.  There should not be any need to
provide a PTR record just for the sake of providing a PTR record.


Bj?rn

From spz at serpens.de  Mon Aug 31 14:21:21 2009
From: spz at serpens.de (S.P.Zeidler)
Date: Mon, 31 Aug 2009 14:21:21 +0200
Subject: PTR records for v6 hosts
In-Reply-To: <877hwkyzt5.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<87k50kz5f7.fsf@nemi.mork.no> <20090831104831.GK13445@serpens.de>
	<877hwkyzt5.fsf@nemi.mork.no>
Message-ID: <20090831122121.GL13445@serpens.de>

Hi,

Thus wrote Bj?rn Mork (bjorn at mork.no):

> "S.P.Zeidler" <spz at serpens.de> writes:
> 
> > Generally, I'd say don't create reverse unless it is requested.
> 
> I tend to agree.  Providing customer self service scripts on a web
> portal, letting those who care either fill in their host names or
> request delegations, is probably sufficient.  If the customer doesn't
> care, then why should I?

It's also the only way to give forward and reverse a chance to match. :)

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)

From mlm at pixelgate.net  Mon Aug 31 15:24:25 2009
From: mlm at pixelgate.net (Mark Milhollan)
Date: Mon, 31 Aug 2009 06:24:25 -0700 (PDT)
Subject: PTR records for v6 hosts
In-Reply-To: <mailman.1.1251712801.23918.ipv6-ops@lists.cluenet.de>
References: <mailman.1.1251712801.23918.ipv6-ops@lists.cluenet.de>
Message-ID: <Pine.LNX.4.64.0908310601080.2704@gw-admin.pixelgate.net>

On Mon, 31 Aug 2009, Lionel Elie Mamane wrote:

>>- Delegate the reverse zone to the customer?  Most won't have a clue
>>  what to do with it.
>
>I can imagine that once IPv6 support has "settled in", that will be
>the standard solution, supported by most residential gateways.

Most of todays "settled in" consumer IPv4 gateways don't know their own name 
in any meaninful global DNS terms.  Internally most are unnamed, but I've 
seen several that disclose the PPPoE username or are plain router or 
$routermodel or similarly useless things.  Hell, many "managed" routers for 
non-trivial clients don't have a useful hostname set.

Perhaps the manufacturers will provide something, but don't expect anything 
better than the semi-horrible walldns-like example already suggested 
(x20010db800000000021a73fffe502834.example.com), for privacy if not 
performance reasons, i.e., some (probably many) people would be freaked if 
you suggested that their router publish in some form the (idiotic or too 
revealing?) hostnames they have themselves assigned (often unknowingly).

Also some ISPs would want to force the domain, but where is the domain name 
delegation to complement the address prefix delegation?  Without that the 
gateway couldn't properly respond (Mark-PC.local anyone?), for this case, 
which means filtering the response (so no longer a direct delegation, and 
thus more complex systems).

I expect an ISP provided, predefined generic name for every address in the 
entire allocation will predominate for many years, making things like Martin 
List-Petersen's pdns pipe very attractive (since it would kill BIND, and 
others, to actually populate such a zone).  Perhaps using base 32 (or 64) 
encoding instead of merely 16, easy as it is to "see" the ip address when 
using hex.

From dougb at dougbarton.us  Mon Aug 31 19:26:50 2009
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 31 Aug 2009 10:26:50 -0700
Subject: PTR records for v6 hosts
In-Reply-To: <84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
Message-ID: <4A9C07DA.3060309@dougbarton.us>

Ron Broersma wrote:
> 
> On Aug 30, 2009, at 8:42 AM, Seth Mattinen wrote:
> 
>> I'm curious as to how everyone is doing PTR records in DNS for their v6
>> hosts. Are you just letting autoconf hosts go without? Do you manually
>> create one once you know what it's autoconf address will be? Or do you
>> use DHCP with a predefined pool that's easy to create a PTR range for?
> 
> We wrote a tool that regularly polls the routers, grabs the ARP and ND
> tables (using appropriate snmp MIBs), looks for all the global unicast
> IPv6 addresses in the list, and then using their MAC address we map to
> the associated IPv4 address, then use that to look up the IPv4 PTR
> record in DNS, then use that to build an IPv6 PTR record and use dynamic
> DNS update to update the zone (with various optimizations such as
> caching, garbage collection, etc). 

Have you considered open-sourcing such a tool? I'm sure that a lot of
people would find it very valuable.


> That works well for us (dealing
> with thousands of v6 hosts on our net), although there are challenges
> with differences in how each vendor implements the v6 MIBs, and churn
> from those horrible privacy/temporary addresses [RFCs 3041, 4941] that
> that all Microsoft OS's enable by default). 

Personally I like my privacy, but I can see how it would be difficult
to deal with. :)


Doug

From stig at venaas.com  Mon Aug 31 19:51:35 2009
From: stig at venaas.com (Stig Venaas)
Date: Mon, 31 Aug 2009 10:51:35 -0700
Subject: PTR records for v6 hosts
In-Reply-To: <Pine.LNX.4.64.0908310601080.2704@gw-admin.pixelgate.net>
References: <mailman.1.1251712801.23918.ipv6-ops@lists.cluenet.de>
	<Pine.LNX.4.64.0908310601080.2704@gw-admin.pixelgate.net>
Message-ID: <4A9C0DA7.1040103@venaas.com>

Mark Milhollan wrote:
> On Mon, 31 Aug 2009, Lionel Elie Mamane wrote:
[...]
> I expect an ISP provided, predefined generic name for every address in the 
> entire allocation will predominate for many years, making things like Martin 
> List-Petersen's pdns pipe very attractive (since it would kill BIND, and 
> others, to actually populate such a zone).  Perhaps using base 32 (or 64) 
> encoding instead of merely 16, easy as it is to "see" the ip address when 
> using hex.

Do you know if anyone has written something like the pdns for BIND? I've
thought about writing something like that using BIND's sdb back-end. It
should be easy but I never got around to it. I might try to implement
one unless it's been done already...

Stig

From stig at venaas.com  Mon Aug 31 19:57:41 2009
From: stig at venaas.com (Stig Venaas)
Date: Mon, 31 Aug 2009 10:57:41 -0700
Subject: PTR records for v6 hosts
In-Reply-To: <87fxb8z1nj.fsf@nemi.mork.no>
References: <4A9AC81B.40500@rollernet.us>	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>	<87k50kz5f7.fsf@nemi.mork.no>	<20090831095338.GA4472@capsaicin.mamane.lu>
	<87fxb8z1nj.fsf@nemi.mork.no>
Message-ID: <4A9C0F15.6090406@venaas.com>

Bj?rn Mork wrote:
[...]
> But I still wonder how the ISP is supposed to know when and where to
> delegate the reverse zone.  I wouldn't want to just blindly delegate it
> and end up having lots of lame delegations around.  So I would have to
> wait for the RG to answer queries before enabling the DNS delegation.
> Which I guess would be at least a few seconds after the DHCP-PD
> finished.

Would it be useful to have some DHCP option that the RG could use to
request a delegation? It could perhaps be part of the DHCP-PD request.

Stig

> Or maybe just enable it blindly first, accepting some lame delegations
> for a while, and do a periodical scan to find delegations which should
> be disabled?  Hmm, I'm going to have about a million of those...  Need
> to think about this for a while.
> 
> 
> Bj?rn


From ron at spawar.navy.mil  Mon Aug 31 20:15:01 2009
From: ron at spawar.navy.mil (Ron Broersma)
Date: Mon, 31 Aug 2009 08:15:01 -1000
Subject: PTR records for v6 hosts
In-Reply-To: <4A9C07DA.3060309@dougbarton.us>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<4A9C07DA.3060309@dougbarton.us>
Message-ID: <FCF3A9C4-7924-4C8A-B37C-FAD7F246EED1@spawar.navy.mil>


On Aug 31, 2009, at 7:26 AM, Doug Barton wrote:

> Ron Broersma wrote:
>>
>> On Aug 30, 2009, at 8:42 AM, Seth Mattinen wrote:
>>
>>> I'm curious as to how everyone is doing PTR records in DNS for  
>>> their v6
>>> hosts. Are you just letting autoconf hosts go without? Do you  
>>> manually
>>> create one once you know what it's autoconf address will be? Or do  
>>> you
>>> use DHCP with a predefined pool that's easy to create a PTR range  
>>> for?
>>
>> We wrote a tool that regularly polls the routers, grabs the ARP and  
>> ND
>> tables (using appropriate snmp MIBs), looks for all the global  
>> unicast
>> IPv6 addresses in the list, and then using their MAC address we map  
>> to
>> the associated IPv4 address, then use that to look up the IPv4 PTR
>> record in DNS, then use that to build an IPv6 PTR record and use  
>> dynamic
>> DNS update to update the zone (with various optimizations such as
>> caching, garbage collection, etc).
>
> Have you considered open-sourcing such a tool? I'm sure that a lot of
> people would find it very valuable.

Yes, that is the plan.  But we want to first make it a little more  
general purpose now that we have all the algorithms worked out, and  
clean up the code a bit, and provide various configuration options  
depending on site preferences.

>> That works well for us (dealing
>> with thousands of v6 hosts on our net), although there are challenges
>> with differences in how each vendor implements the v6 MIBs, and churn
>> from those horrible privacy/temporary addresses [RFCs 3041, 4941]  
>> that
>> that all Microsoft OS's enable by default).
>
> Personally I like my privacy, but I can see how it would be difficult
> to deal with. :)

I understand that many would prefer that level of privacy, but it  
creates serious problems for managed enterprise networks where  
stability of addresses and forensics capabilities are important.  If I  
had my way, I'd like to see another bit in the router advertisements  
(like the M & O bits) that says "do not use privacy addresses", or  
something like that, rather than having to convince all my users and  
sys admins to disable it manually on every Windows system.

--Ron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4936 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090831/4b208985/attachment.bin 

From dougb at dougbarton.us  Mon Aug 31 20:19:54 2009
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 31 Aug 2009 11:19:54 -0700
Subject: PTR records for v6 hosts
In-Reply-To: <FCF3A9C4-7924-4C8A-B37C-FAD7F246EED1@spawar.navy.mil>
References: <4A9AC81B.40500@rollernet.us>
	<84ECA8C8-717B-423A-91C1-4B96A20DF5EC@spawar.navy.mil>
	<4A9C07DA.3060309@dougbarton.us>
	<FCF3A9C4-7924-4C8A-B37C-FAD7F246EED1@spawar.navy.mil>
Message-ID: <4A9C144A.5080707@dougbarton.us>

Ron Broersma wrote:
> 
> On Aug 31, 2009, at 7:26 AM, Doug Barton wrote:
> 
>> Ron Broersma wrote:
>>>
>>> On Aug 30, 2009, at 8:42 AM, Seth Mattinen wrote:
>>>
>>>> I'm curious as to how everyone is doing PTR records in DNS for their v6
>>>> hosts. Are you just letting autoconf hosts go without? Do you manually
>>>> create one once you know what it's autoconf address will be? Or do you
>>>> use DHCP with a predefined pool that's easy to create a PTR range for?
>>>
>>> We wrote a tool that regularly polls the routers, grabs the ARP and ND
>>> tables (using appropriate snmp MIBs), looks for all the global unicast
>>> IPv6 addresses in the list, and then using their MAC address we map to
>>> the associated IPv4 address, then use that to look up the IPv4 PTR
>>> record in DNS, then use that to build an IPv6 PTR record and use dynamic
>>> DNS update to update the zone (with various optimizations such as
>>> caching, garbage collection, etc).
>>
>> Have you considered open-sourcing such a tool? I'm sure that a lot of
>> people would find it very valuable.
> 
> Yes, that is the plan.  But we want to first make it a little more
> general purpose now that we have all the algorithms worked out, and
> clean up the code a bit, and provide various configuration options
> depending on site preferences.

That sounds great! One word of free advice (worth just what you paid
for it of course), err on the side of releasing sooner than later.
Many a useful project has been stuck forever in the loop of "not quite
ready for other people to see yet."

>>> That works well for us (dealing
>>> with thousands of v6 hosts on our net), although there are challenges
>>> with differences in how each vendor implements the v6 MIBs, and churn
>>> from those horrible privacy/temporary addresses [RFCs 3041, 4941] that
>>> that all Microsoft OS's enable by default).
>>
>> Personally I like my privacy, but I can see how it would be difficult
>> to deal with. :)
> 
> I understand that many would prefer that level of privacy, but it
> creates serious problems for managed enterprise networks where stability
> of addresses and forensics capabilities are important.  If I had my way,
> I'd like to see another bit in the router advertisements (like the M & O
> bits) that says "do not use privacy addresses", or something like that,
> rather than having to convince all my users and sys admins to disable it
> manually on every Windows system.

Not that this is the forum, but if we were going to design something
like that I would prefer a flag that said 'use your "real" address on
the internal network, and a privacy address for the cloud' in the mix
somewhere.


Doug