From mchughtai at gmail.com Wed Jan 14 01:22:30 2009 From: mchughtai at gmail.com (MSC) Date: Tue, 13 Jan 2009 19:22:30 -0500 Subject: IPv6 Subnet tool Message-ID: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> Hi Guys, I am fairly new to IPv6 and recently start reading about it. We are planning to get an IPv6 block and i need to get some understanding and hands one with the v6 subnetting. I appreciate if someone could shrare the knowledge about some free ipv6 subnet tool which could help subnet a /40 or /48 etc. Regards M S C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090113/b79aec85/attachment.html From jabley at hopcount.ca Wed Jan 14 01:46:52 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Jan 2009 19:46:52 -0500 Subject: IPv6 Subnet tool In-Reply-To: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> References: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> Message-ID: <67BF2CBE-4FB4-4F16-A8C1-7C5AB6FE53F4@hopcount.ca> On 13 Jan 2009, at 19:22, MSC wrote: > I am fairly new to IPv6 and recently start reading about it. We are > planning to get an IPv6 block and i need to get some understanding > and hands one with the v6 subnetting. I appreciate if someone could > shrare the knowledge about some free ipv6 subnet tool which could > help subnet a /40 or /48 etc. Others here might well have different advice, but with fixed-sized subnets you don't really need a tool to do anything; you just need an easy-to-remember way of generating a unique number per subnet. So, if you're assigned 2607:f2c0:ffff::/48 by your ISP, and all your subnets are /64s, then you just have to number them using the middle 16 bits. So, subnet xxxx would be numbered 2607:f2c0:ffff:xxxx::/64. In networks with a switched ethernet core, one approach is to use the VLAN tag, either converted to hex or just entered as-is (so, binary- coded decimal). So if you want to figure out how to number devices on vlan 297, just use 2607:f2c0:ffff:297::/64. You could use special "vlan" numbers (e.g. 0, f000, whatever) to identify blocks of addresses to number other stuff that doesn't have a VLAN tag, like point-to-point links, loopbacks, etc. If you have a bunch of sites, and more address space than a /48, then maybe use one /48 per site. There are surely many possible variations. But it seems to work well to use fixed-sized subnets and encode an identifier into the prefix. Joe From jeroen at easyhosting.nl Wed Jan 14 09:14:49 2009 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Wed, 14 Jan 2009 09:14:49 +0100 Subject: IPv6 Subnet tool In-Reply-To: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> References: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> Message-ID: <496D9EF9.7050802@easyhosting.nl> I've used this one for some basic subnetting: http://www.liquidalchemy.com/liquidalchemy/ MSC wrote: > Hi Guys, > I am fairly new to IPv6 and recently start reading about it. We are > planning to get an IPv6 block and i need to get some understanding and > hands one with the v6 subnetting. I appreciate if someone could shrare > the knowledge about some free ipv6 subnet tool which could help subnet > a /40 or /48 etc. > > Regards > > M S C -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From nuno.vieira at nfsi.pt Wed Jan 14 09:52:13 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 14 Jan 2009 08:52:13 +0000 (WET) Subject: IPv6 Subnet tool In-Reply-To: <801197982.37931231922977585.JavaMail.root@zimbra.nfsi.pt> Message-ID: <557843575.37951231923133278.JavaMail.root@zimbra.nfsi.pt> Hi, apt-get install sipcalc souce available at http://www.routemeister.net/projects/sipcalc/ sample usage: # sipcalc 2001:abc::/48 -[ipv6 : 2001:abc::/48] - 0 [IPV6 INFO] Expanded Address - 2001:0abc:0000:0000:0000:0000:0000:0000 Compressed address - 2001:abc:: Subnet prefix (masked) - 2001:abc:0:0:0:0:0:0/48 Address ID (masked) - 0:0:0:0:0:0:0:0/48 Prefix address - ffff:ffff:ffff:0:0:0:0:0 Prefix length - 48 Address type - Aggregatable Global Unicast Addresses Network range - 2001:0abc:0000:0000:0000:0000:0000:0000 - 2001:0abc:0000:ffff:ffff:ffff:ffff:ffff have fun, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "MSC" wrote: > Hi Guys, > I am fairly new to IPv6 and recently start reading about it. We are planning to get an IPv6 block and i need to get some understanding and hands one with the v6 subnetting. I appreciate if someone could shrare the knowledge about some free ipv6 subnet tool which could help subnet a /40 or /48 etc. > > Regards > > M S C > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090114/f8803c19/attachment.html From nuno.vieira at nfsi.pt Wed Jan 14 10:03:11 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 14 Jan 2009 09:03:11 +0000 (WET) Subject: IPv6 Subnet tool In-Reply-To: <557843575.37951231923133278.JavaMail.root@zimbra.nfsi.pt> Message-ID: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> err... pasted the wrong sample :-) # sipcalc 2001:b18::/48 --v6split=64 -[ipv6 : 2001:b18::/48] - 0 [Split network] Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - 2001:0b18:0000:0000:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - 2001:0b18:0000:0001:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - 2001:0b18:0000:0002:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - 2001:0b18:0000:0003:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - 2001:0b18:0000:0004:ffff:ffff:ffff:ffff ...... Network - 2001:0b18:0000:fff9:0000:0000:0000:0000 - 2001:0b18:0000:fff9:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:fffa:0000:0000:0000:0000 - 2001:0b18:0000:fffa:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:fffb:0000:0000:0000:0000 - 2001:0b18:0000:fffb:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:fffc:0000:0000:0000:0000 - 2001:0b18:0000:fffc:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:fffd:0000:0000:0000:0000 - 2001:0b18:0000:fffd:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:fffe:0000:0000:0000:0000 - 2001:0b18:0000:fffe:ffff:ffff:ffff:ffff Network - 2001:0b18:0000:ffff:0000:0000:0000:0000 - 2001:0b18:0000:ffff:ffff:ffff:ffff:ffff --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Nuno Vieira - nfsi telecom" wrote: > > Hi, > > apt-get install sipcalc > > souce available at http://www.routemeister.net/projects/sipcalc/ > > sample usage: > > # sipcalc 2001:abc::/48 > -[ipv6 : 2001:abc::/48] - 0 > > [IPV6 INFO] > Expanded Address - 2001:0abc:0000:0000:0000:0000:0000:0000 > Compressed address - 2001:abc:: > Subnet prefix (masked) - 2001:abc:0:0:0:0:0:0/48 > Address ID (masked) - 0:0:0:0:0:0:0:0/48 > Prefix address - ffff:ffff:ffff:0:0:0:0:0 > Prefix length - 48 > Address type - Aggregatable Global Unicast Addresses > Network range - 2001:0abc:0000:0000:0000:0000:0000:0000 - > 2001:0abc:0000:ffff:ffff:ffff:ffff:ffff > > > have fun, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "MSC" wrote: > > Hi Guys, > > I am fairly new to IPv6 and recently start reading about it. We are planning to get an IPv6 block and i need to get some understanding and hands one with the v6 subnetting. I appreciate if someone could shrare the knowledge about some free ipv6 subnet tool which could help subnet a /40 or /48 etc. > > > > Regards > > > > M S C > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090114/89dbd0f8/attachment.html From marc at let.de Wed Jan 14 10:10:42 2009 From: marc at let.de (Marc Manthey) Date: Wed, 14 Jan 2009 10:10:42 +0100 Subject: IPv6 Subnet tool In-Reply-To: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> Message-ID: <99B0387F-E481-42BB-96C5-CCD18C4A1642@let.de> Am 14.01.2009 um 10:03 schrieb Nuno Vieira - nfsi telecom: > err... pasted the wrong sample :-) nice, thanks, so this works without any trouble on linux / debian, etch ? regards marc ---- apt-get install sipcalc souce available at http://www.routemeister.net/projects/sipcalc/ > > > # sipcalc 2001:b18::/48 --v6split=64 > -[ipv6 : 2001:b18::/48] - 0 > > [Split network] > Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - > 2001:0b18:0000:0000:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - > 2001:0b18:0000:0001:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - > 2001:0b18:0000:0002:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - > 2001:0b18:0000:0003:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - > 2001:0b18:0000:0004:ffff:ffff:ffff:ffff > > ...... > > > Network - 2001:0b18:0000:fff9:0000:0000:0000:0000 - > 2001:0b18:0000:fff9:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffa:0000:0000:0000:0000 - > 2001:0b18:0000:fffa:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffb:0000:0000:0000:0000 - > 2001:0b18:0000:fffb:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffc:0000:0000:0000:0000 - > 2001:0b18:0000:fffc:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffd:0000:0000:0000:0000 - > 2001:0b18:0000:fffd:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffe:0000:0000:0000:0000 - > 2001:0b18:0000:fffe:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:ffff:0000:0000:0000:0000 - > 2001:0b18:0000:ffff:ffff:ffff:ffff:ffff > > > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Nuno Vieira - nfsi telecom" wrote: > > > > Hi, > > > > apt-get install sipcalc > > > > souce available at http://www.routemeister.net/projects/sipcalc/ > > > > sample usage: > > > > # sipcalc 2001:abc::/48 > > -[ipv6 : 2001:abc::/48] - 0 > > > > [IPV6 INFO] > > Expanded Address - 2001:0abc:0000:0000:0000:0000:0000:0000 > > Compressed address - 2001:abc:: > > Subnet prefix (masked) - 2001:abc:0:0:0:0:0:0/48 > > Address ID (masked) - 0:0:0:0:0:0:0:0/48 > > Prefix address - ffff:ffff:ffff:0:0:0:0:0 > > Prefix length - 48 > > Address type - Aggregatable Global Unicast Addresses > > Network range - 2001:0abc:0000:0000:0000:0000:0000:0000 - > > 2001:0abc:0000:ffff:ffff:ffff:ffff:ffff > > > > > > have fun, > > --- > > Nuno Vieira > > nfsi telecom, lda. > > > > nuno.vieira at nfsi.pt > > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > > http://www.nfsi.pt/ > > > > > > > > ----- "MSC" wrote: > > > Hi Guys, > > > I am fairly new to IPv6 and recently start reading about it. We > are planning to get an IPv6 block and i need to get some > understanding and hands one with the v6 subnetting. I appreciate if > someone could shrare the knowledge about some free ipv6 subnet tool > which could help subnet a /40 or /48 etc. > > > > > > Regards > > > > > > M S C > > > -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090114/39afffdf/attachment-0001.html From nuno.vieira at nfsi.pt Wed Jan 14 10:08:06 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 14 Jan 2009 09:08:06 +0000 (WET) Subject: IPv6 Subnet tool In-Reply-To: <99B0387F-E481-42BB-96C5-CCD18C4A1642@let.de> Message-ID: <369698270.38061231924086571.JavaMail.root@zimbra.nfsi.pt> yup --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Marc Manthey" wrote: > > Am 14.01.2009 um 10:03 schrieb Nuno Vieira - nfsi telecom: > err... pasted the wrong sample :-) > nice, thanks, so this works without any trouble on linux / debian, etch ? > regards > marc > > ---- apt-get install sipcalc > > souce available at http://www.routemeister.net/projects/sipcalc/ > > > > # sipcalc 2001:b18::/48 --v6split=64 > -[ipv6 : 2001:b18::/48] - 0 > > [Split network] > Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - > 2001:0b18:0000:0000:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - > 2001:0b18:0000:0001:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - > 2001:0b18:0000:0002:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - > 2001:0b18:0000:0003:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - > 2001:0b18:0000:0004:ffff:ffff:ffff:ffff > > ...... > > > Network - 2001:0b18:0000:fff9:0000:0000:0000:0000 - > 2001:0b18:0000:fff9:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffa:0000:0000:0000:0000 - > 2001:0b18:0000:fffa:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffb:0000:0000:0000:0000 - > 2001:0b18:0000:fffb:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffc:0000:0000:0000:0000 - > 2001:0b18:0000:fffc:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffd:0000:0000:0000:0000 - > 2001:0b18:0000:fffd:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:fffe:0000:0000:0000:0000 - > 2001:0b18:0000:fffe:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:ffff:0000:0000:0000:0000 - > 2001:0b18:0000:ffff:ffff:ffff:ffff:ffff > > > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Nuno Vieira - nfsi telecom" < nuno.vieira at nfsi.pt > wrote: > > > > Hi, > > > > apt-get install sipcalc > > > > souce available at http://www.routemeister.net/projects/sipcalc/ > > > > sample usage: > > > > # sipcalc 2001:abc::/48 > > -[ipv6 : 2001:abc::/48] - 0 > > > > [IPV6 INFO] > > Expanded Address - 2001:0abc:0000:0000:0000:0000:0000:0000 > > Compressed address - 2001:abc:: > > Subnet prefix (masked) - 2001:abc:0:0:0:0:0:0/48 > > Address ID (masked) - 0:0:0:0:0:0:0:0/48 > > Prefix address - ffff:ffff:ffff:0:0:0:0:0 > > Prefix length - 48 > > Address type - Aggregatable Global Unicast Addresses > > Network range - 2001:0abc:0000:0000:0000:0000:0000:0000 - > > 2001:0abc:0000:ffff:ffff:ffff:ffff:ffff > > > > > > have fun, > > --- > > Nuno Vieira > > nfsi telecom, lda. > > > > nuno.vieira at nfsi.pt > > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > > http://www.nfsi.pt/ > > > > > > > > ----- "MSC" < mchughtai at gmail.com > wrote: > > > Hi Guys, > > > I am fairly new to IPv6 and recently start reading about it. We are planning to get an IPv6 block and i need to get some understanding and hands one with the v6 subnetting. I appreciate if someone could shrare the knowledge about some free ipv6 subnet tool which could help subnet a /40 or /48 etc. > > > > > > Regards > > > > > > M S C > > > > > > > -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > mail: marc at let.de jabber : marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast > web: http://www.let.de > Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). > Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090114/d5d3a92e/attachment.html From steve at ibctech.ca Wed Jan 14 15:28:20 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 14 Jan 2009 09:28:20 -0500 Subject: IPv6 Subnet tool In-Reply-To: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> Message-ID: <496DF684.2090501@ibctech.ca> Nuno Vieira - nfsi telecom wrote: > err... pasted the wrong sample :-) > > # sipcalc 2001:b18::/48 --v6split=64 > -[ipv6 : 2001:b18::/48] - 0 > > [Split network] > Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - > 2001:0b18:0000:0000:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - > 2001:0b18:0000:0001:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - > 2001:0b18:0000:0002:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - > 2001:0b18:0000:0003:ffff:ffff:ffff:ffff > Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - > 2001:0b18:0000:0004:ffff:ffff:ffff:ffff Note that it may be prudent to assign up your address space in non-contiguous prefixes. Consider the ramifications of assigning each client a /64 in a sequential fashion, and then having to assign a particular client additional prefixes at a later time. If your network is not flat, then you just broke your ability to aggregate your prefixes from the edge in. Steve From lambert at psc.edu Wed Jan 14 15:38:38 2009 From: lambert at psc.edu (Michael Lambert) Date: Wed, 14 Jan 2009 09:38:38 -0500 Subject: IPv6 Subnet tool In-Reply-To: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> References: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> Message-ID: I would also look at RFC3531. Michael On 13 Jan 2009, at 19:22, MSC wrote: > Hi Guys, > I am fairly new to IPv6 and recently start reading about it. We are > planning to get an IPv6 block and i need to get some understanding > and hands one with the v6 subnetting. I appreciate if someone could > shrare the knowledge about some free ipv6 subnet tool which could > help subnet a /40 or /48 etc. > > Regards > > M S C From lists at memetic.org Wed Jan 14 15:42:29 2009 From: lists at memetic.org (Adam Armstrong) Date: Wed, 14 Jan 2009 14:42:29 +0000 Subject: IPv6 Subnet tool In-Reply-To: <496DF684.2090501@ibctech.ca> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> Message-ID: <496DF9D5.5080002@memetic.org> Steve Bertrand wrote: > Nuno Vieira - nfsi telecom wrote: > >> err... pasted the wrong sample :-) >> >> # sipcalc 2001:b18::/48 --v6split=64 >> -[ipv6 : 2001:b18::/48] - 0 >> >> [Split network] >> Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - >> 2001:0b18:0000:0000:ffff:ffff:ffff:ffff >> Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - >> 2001:0b18:0000:0001:ffff:ffff:ffff:ffff >> Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - >> 2001:0b18:0000:0002:ffff:ffff:ffff:ffff >> Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - >> 2001:0b18:0000:0003:ffff:ffff:ffff:ffff >> Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - >> 2001:0b18:0000:0004:ffff:ffff:ffff:ffff >> > > Note that it may be prudent to assign up your address space in > non-contiguous prefixes. > > Consider the ramifications of assigning each client a /64 in a > sequential fashion, and then having to assign a particular client > additional prefixes at a later time. > > If your network is not flat, then you just broke your ability to > aggregate your prefixes from the edge in. > You would assign them a /56 if they needed more than a /64. If they're the kind of organisation which would have issues with renumbering, you wouldn't have assigned a /64. A /64 shouldn't really be given to anything but a house, dog kennel or potting shed. adam. From jabley at hopcount.ca Wed Jan 14 17:47:50 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Jan 2009 11:47:50 -0500 Subject: IPv6 Subnet tool In-Reply-To: <496DF9D5.5080002@memetic.org> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> Message-ID: <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> On 14 Jan 2009, at 09:42, Adam Armstrong wrote: > Steve Bertrand wrote: >> Nuno Vieira - nfsi telecom wrote: >> >>> err... pasted the wrong sample :-) >>> >>> # sipcalc 2001:b18::/48 --v6split=64 >>> -[ipv6 : 2001:b18::/48] - 0 >>> >>> [Split network] >>> Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - >>> 2001:0b18:0000:0000:ffff:ffff:ffff:ffff >>> Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - >>> 2001:0b18:0000:0001:ffff:ffff:ffff:ffff >>> Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - >>> 2001:0b18:0000:0002:ffff:ffff:ffff:ffff >>> Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - >>> 2001:0b18:0000:0003:ffff:ffff:ffff:ffff >>> Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - >>> 2001:0b18:0000:0004:ffff:ffff:ffff:ffff >>> >> >> Note that it may be prudent to assign up your address space in >> non-contiguous prefixes. >> >> Consider the ramifications of assigning each client a /64 in a >> sequential fashion, and then having to assign a particular client >> additional prefixes at a later time. >> >> If your network is not flat, then you just broke your ability to >> aggregate your prefixes from the edge in. >> > You would assign them a /56 if they needed more than a /64. If > they're the kind of organisation which would have issues with > renumbering, you wouldn't have assigned a /64. > > A /64 shouldn't really be given to anything but a house, dog kennel > or potting shed. ... and if the application really is to assign and route prefixes to customers, and not simply to number internal infrastructure within a single organisation, it would be a better idea to contact an RIR and request a /32 than to worry about how to cut up a /48. As an aside, I have yet to be convinced that there's any value in assigning anything smaller than a /48 to customers, regardless of whether they are residential users or giant industrial megaliths. People whose habit it is to assign /56s seem like they are most likely to cause annoyance to customers who are migrating from some other provider who gave them (reasonably) a /48. Joe From nuno.vieira at nfsi.pt Wed Jan 14 17:47:16 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 14 Jan 2009 16:47:16 +0000 (WET) Subject: IPv6 Subnet tool In-Reply-To: <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> Message-ID: <381981896.40361231951636430.JavaMail.root@zimbra.nfsi.pt> We are assigning /48's generally to customers, except to datacenter customers, where usually we assign a /64. (where sometimes only 1 or 2 hosts exist). any toughts about this ? regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Joe Abley" wrote: > On 14 Jan 2009, at 09:42, Adam Armstrong wrote: > > > Steve Bertrand wrote: > >> Nuno Vieira - nfsi telecom wrote: > >> > >>> err... pasted the wrong sample :-) > >>> > >>> # sipcalc 2001:b18::/48 --v6split=64 > >>> -[ipv6 : 2001:b18::/48] - 0 > >>> > >>> [Split network] > >>> Network - 2001:0b18:0000:0000:0000:0000:0000:0000 - > >>> 2001:0b18:0000:0000:ffff:ffff:ffff:ffff > >>> Network - 2001:0b18:0000:0001:0000:0000:0000:0000 - > >>> 2001:0b18:0000:0001:ffff:ffff:ffff:ffff > >>> Network - 2001:0b18:0000:0002:0000:0000:0000:0000 - > >>> 2001:0b18:0000:0002:ffff:ffff:ffff:ffff > >>> Network - 2001:0b18:0000:0003:0000:0000:0000:0000 - > >>> 2001:0b18:0000:0003:ffff:ffff:ffff:ffff > >>> Network - 2001:0b18:0000:0004:0000:0000:0000:0000 - > >>> 2001:0b18:0000:0004:ffff:ffff:ffff:ffff > >>> > >> > >> Note that it may be prudent to assign up your address space in > >> non-contiguous prefixes. > >> > >> Consider the ramifications of assigning each client a /64 in a > >> sequential fashion, and then having to assign a particular client > >> additional prefixes at a later time. > >> > >> If your network is not flat, then you just broke your ability to > >> aggregate your prefixes from the edge in. > >> > > You would assign them a /56 if they needed more than a /64. If > > they're the kind of organisation which would have issues with > > renumbering, you wouldn't have assigned a /64. > > > > A /64 shouldn't really be given to anything but a house, dog kennel > > > or potting shed. > > ... and if the application really is to assign and route prefixes to > > customers, and not simply to number internal infrastructure within a > > single organisation, it would be a better idea to contact an RIR and > > request a /32 than to worry about how to cut up a /48. > > As an aside, I have yet to be convinced that there's any value in > assigning anything smaller than a /48 to customers, regardless of > whether they are residential users or giant industrial megaliths. > > People whose habit it is to assign /56s seem like they are most likely > > to cause annoyance to customers who are migrating from some other > provider who gave them (reasonably) a /48. > > > Joe From jabley at hopcount.ca Wed Jan 14 17:54:09 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Jan 2009 11:54:09 -0500 Subject: IPv6 Subnet tool In-Reply-To: <381981896.40361231951636430.JavaMail.root@zimbra.nfsi.pt> References: <381981896.40361231951636430.JavaMail.root@zimbra.nfsi.pt> Message-ID: <928141DD-D8C8-4EEC-80D7-A82909482370@hopcount.ca> On 14 Jan 2009, at 11:47, Nuno Vieira - nfsi telecom wrote: > We are assigning /48's generally to customers, except to datacenter > customers, where usually we assign a /64. (where sometimes only 1 or > 2 hosts exist). > > any toughts about this ? Assigning a /64 to a single subnet in a data centre seems entirely reasonable. Assigning a /48 to a single customer in a data centre to allow for the possibility that the customer might need to add more subnets behind what they are hooking up also seems plausible. I guess it depends on the kind of colo service that is being provided. Joe From drc at virtualized.org Wed Jan 14 20:06:35 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Jan 2009 11:06:35 -0800 Subject: IPv6 Subnet tool In-Reply-To: <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> Message-ID: <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> Joe, On Jan 14, 2009, at 8:47 AM, Joe Abley wrote: > People whose habit it is to assign /56s seem like they are most > likely to cause annoyance to customers who are migrating from some > other provider who gave them (reasonably) a /48. Not sure what the annoyance would be: going from a /56 to a /48 doesn't require any more renumbering than going from one /48 to a different /48. Where the annoyance comes in is going from a /48 to a / 56... Regards, -drc From jabley at hopcount.ca Wed Jan 14 20:38:57 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Jan 2009 14:38:57 -0500 Subject: IPv6 Subnet tool In-Reply-To: <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> Message-ID: On 14 Jan 2009, at 14:06, David Conrad wrote: > On Jan 14, 2009, at 8:47 AM, Joe Abley wrote: >> People whose habit it is to assign /56s seem like they are most >> likely to cause annoyance to customers who are migrating from some >> other provider who gave them (reasonably) a /48. > > Not sure what the annoyance would be: going from a /56 to a /48 > doesn't require any more renumbering than going from one /48 to a > different /48. Where the annoyance comes in is going from a /48 to > a /56... Moving from a /56 to a /48 is easy; the annoyance is in the other direction. If your numbering scheme for your assigned /48 is of the form xxxx:xxxx:xxxx:SUBNET:<64-bit-EUI> (i.e. you're identifying individual /64 prefixes using some 16-bit integer denoted as SUBNET above), that doesn't map nicely into a /56 unless you make the conscious decision not to use the top eight bits of the SUBNET value (in which case you've really only got a /56). I'm not saying it's a huge deal, but in general it seems like it is non-zero work. This seems like a shame for an address format that was chosen, in part, to make renumbering easier. Joe From mleber at he.net Wed Jan 14 21:47:07 2009 From: mleber at he.net (Mike Leber) Date: Wed, 14 Jan 2009 12:47:07 -0800 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> Message-ID: <496E4F4B.8030605@he.net> Joe Abley wrote: > Moving from a /56 to a /48 is easy; the annoyance is in the other > direction. If your numbering scheme for your assigned /48 is of the form > > xxxx:xxxx:xxxx:SUBNET:<64-bit-EUI> > > (i.e. you're identifying individual /64 prefixes using some 16-bit > integer denoted as SUBNET above), that doesn't map nicely into a /56 > unless you make the conscious decision not to use the top eight bits of > the SUBNET value (in which case you've really only got a /56). > > I'm not saying it's a huge deal, but in general it seems like it is > non-zero work. This seems like a shame for an address format that was > chosen, in part, to make renumbering easier. So for a customer to be able to do such migrations, they need to use the lower bits first. If the problem you are posing is: "How can I make 8 bits work when I started with 16 bits?", the answer is use the lower 8 bits or renumber to fit in the 8 bits, and you are presupposing you have 8 bits or less worth of resource to migrate. It's not like math did you wrong. This would be a reasonable planning thing to mention to customers with a mix of /48s and /56s from various providers. Mike. -- +---------------- 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 jabley at hopcount.ca Wed Jan 14 21:55:08 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Jan 2009 15:55:08 -0500 Subject: IPv6 Subnet tool In-Reply-To: <496E4F4B.8030605@he.net> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: On 14 Jan 2009, at 15:47, Mike Leber wrote: > If the problem you are posing is: "How can I make 8 bits work when I > started with 16 bits?", the answer is use the lower 8 bits or > renumber to fit in the 8 bits, and you are presupposing you have 8 > bits or less worth of resource to migrate. It's not like math did > you wrong. Maybe I'm just bitter about the number of v6 numbering plans I've rolled out that map VLAN tags into those 16 bits from the bottom up, and map non-VLAN things from the top down, starting at ffff :-) > This would be a reasonable planning thing to mention to customers > with a mix of /48s and /56s from various providers. For sure. It seems disappointing that LIRs can't just assign /48s consistently, though. Perhaps I'm just not seeing the problem that assigning a /56 solves. Joe From gert at space.net Wed Jan 14 22:09:56 2009 From: gert at space.net (Gert Doering) Date: Wed, 14 Jan 2009 22:09:56 +0100 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: <20090114210956.GS44476@Space.Net> Hi, On Wed, Jan 14, 2009 at 03:55:08PM -0500, Joe Abley wrote: > For sure. It seems disappointing that LIRs can't just assign /48s > consistently, though. Perhaps I'm just not seeing the problem that > assigning a /56 solves. Geoff Huston's math seems to show that we'll run out of IPv6 space in 20-30 years if we assign /48s to every end user out there (plus have some inevitable loss due to aggregation hierarchy, and so on)... Gert Doering -- RIPE APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jabley at hopcount.ca Wed Jan 14 22:28:47 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 14 Jan 2009 16:28:47 -0500 Subject: IPv6 Subnet tool In-Reply-To: <20090114210956.GS44476@Space.Net> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <20090114210956.GS44476@Space.Net> Message-ID: <8EF0099A-72B6-47E7-8168-7075D09D6AA0@hopcount.ca> On 14 Jan 2009, at 16:09, Gert Doering wrote: > On Wed, Jan 14, 2009 at 03:55:08PM -0500, Joe Abley wrote: >> For sure. It seems disappointing that LIRs can't just assign /48s >> consistently, though. Perhaps I'm just not seeing the problem that >> assigning a /56 solves. > > Geoff Huston's math seems to show that we'll run out of IPv6 space in > 20-30 years if we assign /48s to every end user out there (plus have > some inevitable loss due to aggregation hierarchy, and so on)... I hadn't seen those numbers, thanks. I will go and hunt them down. Last I heard the expectation from the RIRs was that LIRs should assign a /48 to people who need to number more than one subnet, which makes / 56 seem like an annoying exception to the rule. I see that the ARIN policy manual has changed since then to specify /56es, however. APNIC's still says /48, as does LACNIC's and Afrinic's. I ran out of patience trying to find the v6 policy at RIPE. I guess what I'm really in favour of is consistency. Joe From devon at noved.org Wed Jan 14 22:29:26 2009 From: devon at noved.org (Devon True) Date: Wed, 14 Jan 2009 16:29:26 -0500 Subject: IPv6 Assignment Tracking Software Message-ID: <496E5936.5020308@noved.org> All: How are people tracking their IPv6 assignments to customers? Using 3rd party software, spreadsheets, or just based off the router configuration? We currently use NorthStar for our IPv4 tracking but it does not support IPv6 (and some people are not happy with NorthStar). I looked at IPPlan, but found that I could not easily assign IPv4 subnets to customers without pre-allocating them as "free". I also found a few commercial programs like Diamond IP, Easy-IP, or QIP and I was hoping I could get any opinions on them. My ideal software would include the following: o Ability to track IPv4 and IPv6 addresses o A DB that we can import and export data to/from (postgres or mysql preferred) o A web interface o Ability to find IPv4 subnets easily (e.g. I have a /20, find me the next available /28 without having to pre-allocate /28s for use) o Robust search engine o Built-in rwhois is a bonus Thanks! -- Devon From drake at begriffli.ch Wed Jan 14 22:51:25 2009 From: drake at begriffli.ch (Drake Wilson) Date: Wed, 14 Jan 2009 15:51:25 -0600 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: <20090114215125.GA843@drache.begriffli.ch> Quoth Joe Abley , on 2009-01-14 15:55:08 -0500: > Maybe I'm just bitter about the number of v6 numbering plans I've rolled > out that map VLAN tags into those 16 bits from the bottom up, and map > non-VLAN things from the top down, starting at ffff :-) You can still map those onto 8-bit representations so long as there aren't too many; you just need to reset the dividing line. If the dividing line is in the middle, you can even imagine the bits to be representations of two's-complement signed integers, and then 0000/9 and FF80/9 get translated to 00/1 and 80/1 by sign contraction. ---> Drake Wilson From nick-lists at netability.ie Wed Jan 14 23:45:16 2009 From: nick-lists at netability.ie (Nick Hilliard) Date: Wed, 14 Jan 2009 22:45:16 +0000 Subject: IPv6 Assignment Tracking Software In-Reply-To: <496E5936.5020308@noved.org> References: <496E5936.5020308@noved.org> Message-ID: <496E6AFC.8090000@netability.ie> Devon True wrote: > I > looked at IPPlan, but found that I could not easily assign IPv4 subnets > to customers without pre-allocating them as "free". IPPlan's policy on IPv6 is listed here: http://iptrack.sourceforge.net/doku.php?id=faq "One feature request that comes up from time to time is IPv6. Adding IPv6 support will require major effort but has such a limited audience. Ironically the only people that ever requested IPv6 support are either from Telcos, ISP's or government departments, yet they are never interested in contributing resources! I deam them parasites of the Open Source world - leaching off the good will and effort of the Open Source community, yet give nothing in return." Right now, it would take a major redesign of ipplan's back-end to support ipv6. As you note, its datastore depends on being able to enumerate all possible addresses on a particular subnet - a model which fails spectacularly in the ipv6 world. I looked at the code a long time ago; it would be fugly to fix it. Nick (a parasite of the Open Source world) From drc at virtualized.org Wed Jan 14 23:49:51 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Jan 2009 14:49:51 -0800 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: > Perhaps I'm just not seeing the problem that assigning a /56 solves. How many /12s, /18s, /19s, and even /32s are their in IPv6 compared to IPv4? :-) Regards, -drc From martin at airwire.ie Wed Jan 14 23:56:28 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 14 Jan 2009 22:56:28 +0000 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: <496E6D9C.8090008@airwire.ie> David Conrad wrote: > On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >> Perhaps I'm just not seeing the problem that assigning a /56 solves. > > How many /12s, /18s, /19s, and even /32s are their in IPv6 compared to > IPv4? :-) > Theoretically, assigned or announced ? No, honestly, I don't see what the point of this discussion is. If a business customer has a need to get a /48 when moving ISP, even though the standard allocation size is a /56 for that particular case and can document for it's use and purpose, then he will get it. If he doesn't get it, I wouldn't go with that ISP in the first place. As for assigning only a /56 to end-users or by default, this is very sensible, even though us ISPs have been given a huge amount of IP space. But hell, when /8's were given out, there was no shortage of them either, was there ? Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From dougb at dougbarton.us Thu Jan 15 00:06:36 2009 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 14 Jan 2009 15:06:36 -0800 Subject: IPv6 Subnet tool In-Reply-To: <496E6D9C.8090008@airwire.ie> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> Message-ID: <496E6FFC.8010605@dougbarton.us> Martin List-Petersen wrote: > As for assigning only a /56 to end-users or by default, this is very > sensible, even though us ISPs have been given a huge amount of IP space. > But hell, when /8's were given out, there was no shortage of them > either, was there ? I have long advocated flexibility in allocations for this reason, among others. One of the things I've never understood about the "everyone gets a /48" idea is that different people have different ideas of what the units of "everyone" are. (Even in this one thread if you look carefully.) The more important reason I believe in being conservative initially is that if I'm wrong, it's easy to go the other direction. "We assigned you a /56 initially to be on the safe side, but it's 10 years after widespread IPv6 deployment now and we've tons of addresses after all, so here is a /48, via con dios." OTOH, the initial IPv4 deployment has taught us that once someone gets a block they hold onto it with an iron fist, thus making it nearly impossible to move in the other direction if it turns out that those of us who urged more conservative policies were right all along. Please note, it is not my intention to revisit this entire debate, I fully realize that it's a hobby horse for a lot of people. :) Doug From martin at airwire.ie Thu Jan 15 00:17:43 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 14 Jan 2009 23:17:43 +0000 Subject: IPv6 Subnet tool In-Reply-To: <496E6FFC.8010605@dougbarton.us> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> <496E6FFC.8010605@dougbarton.us> Message-ID: <496E7297.6060403@airwire.ie> Doug Barton wrote: > Martin List-Petersen wrote: >> As for assigning only a /56 to end-users or by default, this is very >> sensible, even though us ISPs have been given a huge amount of IP space. >> But hell, when /8's were given out, there was no shortage of them >> either, was there ? > > I have long advocated flexibility in allocations for this reason, > among others. One of the things I've never understood about the > "everyone gets a /48" idea is that different people have different > ideas of what the units of "everyone" are. (Even in this one thread if > you look carefully.) > > The more important reason I believe in being conservative initially is > that if I'm wrong, it's easy to go the other direction. "We assigned > you a /56 initially to be on the safe side, but it's 10 years after > widespread IPv6 deployment now and we've tons of addresses after all, > so here is a /48, via con dios." OTOH, the initial IPv4 deployment has > taught us that once someone gets a block they hold onto it with an > iron fist, thus making it nearly impossible to move in the other > direction if it turns out that those of us who urged more conservative > policies were right all along. > > Please note, it is not my intention to revisit this entire debate, I > fully realize that it's a hobby horse for a lot of people. :) The space allocated to us and even more has been left to be allocated in needed. A /29 total per RIPE member in the RIPE region if i recall right, that gets a /32 allocated. I've always found, that no matter if it's a hobby horse, commercial or not, with reasonable ISPs you could get any amount of IP allocations that you argumented for, depending on the product that you paid for. If an ISP doesn't allow for that, I wouldn't sign up with them. Basically, if your ISP doesn't deliver the product that you expect, vote with your feet. With IPv6 that will not be different. We'll be assigning /64 to each customer by default, optionally a /56 can be routed to them and we'll be doing it in /48 increments until we run out. If we see, that we're running out of space, we can always fill the gaps :). Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From drc at virtualized.org Thu Jan 15 00:29:59 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Jan 2009 15:29:59 -0800 Subject: IPv6 Subnet tool In-Reply-To: <496E7297.6060403@airwire.ie> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> <496E6FFC.8010605@dougbarton.us> <496E7297.6060403@airwire.ie> Message-ID: <31AE47D5-1D2C-492F-AD90-2EF1B1F89712@virtualized.org> On Jan 14, 2009, at 3:17 PM, Martin List-Petersen wrote: > The space allocated to us and even more has been left to be > allocated in > needed. A /29 total per RIPE member in the RIPE region if i recall > right, that gets a /32 allocated. I hope not. Turns out reservation in IPv4 resulted in lots of tiny holes that few folks wanted (although I suspect that'll be changing soon). The reason the RIRs were allocated /12s from IANA was that the RIRs had committed to _stop_ reserving space and instead do sparse allocation via the "bisection" method. This would allow LIRs to grow while minimizing the number of non-aggregatable prefixes granted to any one ISP. IIRC, APNIC was doing this. Not sure about the other RIRs. Regards, -drc From drc at virtualized.org Thu Jan 15 00:39:13 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Jan 2009 15:39:13 -0800 Subject: IPv6 Subnet tool In-Reply-To: <496E6D9C.8090008@airwire.ie> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> Message-ID: On Jan 14, 2009, at 2:56 PM, Martin List-Petersen wrote: > David Conrad wrote: >> On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >>> Perhaps I'm just not seeing the problem that assigning a /56 solves. >> How many /12s, /18s, /19s, and even /32s are their in IPv6 compared >> to >> IPv4? :-) > Theoretically, assigned or announced ? Theoretically (it was sort of a trick question). > No, honestly, I don't see what the point of this discussion is. Joe doesn't see the problem assigning /56s solves. I was pointing out (in an overly oblique way) that current policies have resulted in the same size prefixes being allocated to ISPs that are being allocated in IPv4 today. As a result, some folks have expressed concern that we'll be facing IPv6 runout far sooner than originally anticipated. Regards, -drc From martin at airwire.ie Thu Jan 15 00:50:38 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 14 Jan 2009 23:50:38 +0000 Subject: IPv6 Subnet tool In-Reply-To: <31AE47D5-1D2C-492F-AD90-2EF1B1F89712@virtualized.org> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> <496E6FFC.8010605@dougbarton.us> <496E7297.6060403@airwire.ie> <31AE47D5-1D2C-492F-AD90-2EF1B1F89712@virtualized.org> Message-ID: <496E7A4E.8090706@airwire.ie> David Conrad wrote: > > On Jan 14, 2009, at 3:17 PM, Martin List-Petersen wrote: >> The space allocated to us and even more has been left to be allocated in >> needed. A /29 total per RIPE member in the RIPE region if i recall >> right, that gets a /32 allocated. > > I hope not. Turns out reservation in IPv4 resulted in lots of tiny > holes that few folks wanted (although I suspect that'll be changing > soon). The reason the RIRs were allocated /12s from IANA was that the > RIRs had committed to _stop_ reserving space and instead do sparse > allocation via the "bisection" method. This would allow LIRs to grow > while minimizing the number of non-aggregatable prefixes granted to any > one ISP. IIRC, APNIC was doing this. Not sure about the other RIRs. The GRH (Ghost Router Hunter) Project gives you a quite good idea on the spacing of allocations/assigments to LIRs. http://www.sixxs.net/tools/grh/dfp/ For RIPE it is quite consistant: http://www.sixxs.net/tools/grh/dfp/ripe/ ARIN however already has a mess: http://www.sixxs.net/tools/grh/dfp/arin/ Some of those IPv6 PI allocations could have been aggregated during allocation, but i probably don't see the bigger picture here. And don't get me wrong, I'm all for PIv6, but please don't give multiple allocations to one and the same business, if it can be aggregated. That's definatly going to mess the table up. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From jay at west.net Thu Jan 15 03:22:06 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 14 Jan 2009 18:22:06 -0800 Subject: IPv6 Subnet tool In-Reply-To: References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> Message-ID: <496E9DCE.1030108@west.net> David Conrad wrote: > On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >> Perhaps I'm just not seeing the problem that assigning a /56 solves. > > How many /12s, /18s, /19s, and even /32s are their in IPv6 compared to > IPv4? :-) Exactly the same number. But each of them is a *substantially* larger subnet. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From martin at airwire.ie Thu Jan 15 03:55:15 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 15 Jan 2009 02:55:15 +0000 Subject: IPv6 Subnet tool In-Reply-To: <496E9DCE.1030108@west.net> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E9DCE.1030108@west.net> Message-ID: <496EA593.5000404@airwire.ie> Jay Hennigan wrote: > David Conrad wrote: >> On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >>> Perhaps I'm just not seeing the problem that assigning a /56 solves. >> >> How many /12s, /18s, /19s, and even /32s are their in IPv6 compared to >> IPv4? :-) > > Exactly the same number. > > But each of them is a *substantially* larger subnet. That's ok, as long as they don't start poluting the global routing table by splitting things. Then, we can always start aggregating that crap as we see fit or take a policies like some stupid tier 1, who decided not to route anything less than a /32, disregard of allocation size by RIR. Kind regards, Martin List-Petersen Netizen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From drc at virtualized.org Thu Jan 15 03:55:33 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 14 Jan 2009 18:55:33 -0800 Subject: IPv6 Subnet tool In-Reply-To: <496E9DCE.1030108@west.net> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E9DCE.1030108@west.net> Message-ID: <0039E7DD-499B-4E2B-B68F-4A6C828FD832@virtualized.org> On Jan 14, 2009, at 6:22 PM, Jay Hennigan wrote: > David Conrad wrote: >> On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >>> Perhaps I'm just not seeing the problem that assigning a /56 solves. >> How many /12s, /18s, /19s, and even /32s are their in IPv6 compared >> to IPv4? :-) > Exactly the same number. Indeed. > But each of them is a *substantially* larger subnet. True. However, despite this, current policy has resulted in consumption patterns that don't look all that different than with IPv4 in the mid-90s -- /20s, /19s, even a /12. Of course it is stunningly unlikely the recipients of those prefixes would ever need to come back for address space, at least given current usage. Of course, they said that about IPv4 too... :-) Revisions to the allocation policies, including /56s and changing the HD ratio, were intended to address (pun intended) these sorts of observations. I'll let others argue about whether the revisions were good ideas. Regards, -drc From martin at airwire.ie Thu Jan 15 04:01:07 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 15 Jan 2009 03:01:07 +0000 Subject: IPv6 Subnet tool In-Reply-To: <0039E7DD-499B-4E2B-B68F-4A6C828FD832@virtualized.org> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E9DCE.1030108@west.net> <0039E7DD-499B-4E2B-B68F-4A6C828FD832@virtualized.org> Message-ID: <496EA6F3.8000405@airwire.ie> David Conrad wrote: > On Jan 14, 2009, at 6:22 PM, Jay Hennigan wrote: >> David Conrad wrote: >>> On Jan 14, 2009, at 12:55 PM, Joe Abley wrote: >>>> Perhaps I'm just not seeing the problem that assigning a /56 solves. >>> How many /12s, /18s, /19s, and even /32s are their in IPv6 compared >>> to IPv4? :-) >> Exactly the same number. > > Indeed. > >> But each of them is a *substantially* larger subnet. > > > True. However, despite this, current policy has resulted in consumption > patterns that don't look all that different than with IPv4 in the > mid-90s -- /20s, /19s, even a /12. Of course it is stunningly unlikely > the recipients of those prefixes would ever need to come back for > address space, at least given current usage. Of course, they said that > about IPv4 too... :-) > > Revisions to the allocation policies, including /56s and changing the HD > ratio, were intended to address (pun intended) these sorts of > observations. I'll let others argue about whether the revisions were > good ideas. They didn't come back for more. They just merged or bought (with) their competitors resulting in them having 2 or maybe 3 /8 at their disposal. Not that they would release any of it. Obviously this is down to 1, maybe 2, extreem examples, but everyone gets the picture. Hell, I'm happy that RIPE started charging similarly for PIv4, as for PA, even though nearly half of our IP space is PI. If you have the revenue to support for the address space it won't matter and if you are trying to save bucks, it might make you give IPv(4|6] space back. Anyhow. The consensus is, that any RIR, LIR or even non-affiliated ISP using PI should adopt a sensible way of allocating space. IPv6 leaves enough space not to mess around. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From mtinka at globaltransit.net Thu Jan 15 04:28:36 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 15 Jan 2009 11:28:36 +0800 Subject: IPv6 Subnet tool In-Reply-To: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> References: <24b6ebc90901131622ld97670ci918c5acc3abffff@mail.gmail.com> Message-ID: <200901151128.37612.mtinka@globaltransit.net> On Wednesday 14 January 2009 08:22:30 am MSC wrote: > I am fairly new to IPv6 and recently start reading about > it. We are planning to get an IPv6 block and i need to > get some understanding and hands one with the v6 > subnetting. I appreciate if someone could shrare the > knowledge about some free ipv6 subnet tool which could > help subnet a /40 or /48 etc. We're happy with 'ipv6gen' and 'sipcalc'. 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/20090115/3a00dd88/attachment.bin From gert at space.net Thu Jan 15 08:27:59 2009 From: gert at space.net (Gert Doering) Date: Thu, 15 Jan 2009 08:27:59 +0100 Subject: IPv6 Subnet tool In-Reply-To: References: <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <496E6D9C.8090008@airwire.ie> Message-ID: <20090115072759.GT44476@Space.Net> Hi, On Wed, Jan 14, 2009 at 03:39:13PM -0800, David Conrad wrote: > Joe doesn't see the problem assigning /56s solves. I was pointing out > (in an overly oblique way) that current policies have resulted in the > same size prefixes being allocated to ISPs that are being allocated in > IPv4 today. I'm not exactly sure in which data you can see *that*. ISPs in IPv4 world today get /10.../22 allocations. ISPs in IPv6 world today get /19.../32 allocations. To me, that's quite different. Especially the default allocation (in RIPE land), /21 in IPv4 vs. /32 in IPv6, is very much so. Gert Doering -- RIPE APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Thu Jan 15 10:32:06 2009 From: gert at space.net (Gert Doering) Date: Thu, 15 Jan 2009 10:32:06 +0100 Subject: IPv6 Subnet tool In-Reply-To: <8EF0099A-72B6-47E7-8168-7075D09D6AA0@hopcount.ca> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF684.2090501@ibctech.ca> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <20090114210956.GS44476@Space.Net> <8EF0099A-72B6-47E7-8168-7075D09D6AA0@hopcount.ca> Message-ID: <20090115093206.GU44476@Space.Net> Hi, On Wed, Jan 14, 2009 at 04:28:47PM -0500, Joe Abley wrote: > I ran out of patience trying to find the v6 policy at RIPE. http://www.ripe.net/rs/ipv6/ -> "IPv6 Address Allocation ... Policy" -> 5.4 "Assignments": ----------------- quote ------------- 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). 5.4.2. Assignments shorter than a /48 to a single End Site When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. ----------------- quote ------------- Gert Doering -- RIPE APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090115/b5cc52a9/attachment.bin From me at kt2t.us Fri Jan 16 05:42:40 2009 From: me at kt2t.us (Michael W. Oliver) Date: Thu, 15 Jan 2009 23:42:40 -0500 Subject: IPv6 Assignment Tracking Software In-Reply-To: <496E5936.5020308@noved.org> References: <496E5936.5020308@noved.org> Message-ID: <20090116044240.GB72854@kt2t.us> On 2009-01-14T16:29:26-0500, Devon True wrote: > All: > > How are people tracking their IPv6 assignments to customers? Using 3rd > party software, spreadsheets, or just based off the router > configuration? We currently use NorthStar for our IPv4 tracking but it > does not support IPv6 (and some people are not happy with NorthStar). I > looked at IPPlan, but found that I could not easily assign IPv4 subnets > to customers without pre-allocating them as "free". > > I also found a few commercial programs like Diamond IP, Easy-IP, or QIP > and I was hoping I could get any opinions on them. > > My ideal software would include the following: > > o Ability to track IPv4 and IPv6 addresses > o A DB that we can import and export data to/from (postgres or mysql > preferred) > o A web interface > o Ability to find IPv4 subnets easily (e.g. I have a /20, find me the > next available /28 without having to pre-allocate /28s for use) > o Robust search engine > o Built-in rwhois is a bonus > > Thanks! There was FreeIPDB from back in the day, developed by Ben April at Global Crossing. AFAIK, Ben left there and I had worked with a guy who was still there named Monte to further development and get it working in a sane way with MySQL (original design focused on PostgreSQL). That was a couple years ago. Since then, I haven't received any response from Monte for further development of the product, and in fact the freeipdb.org domain has lapsed and is in the hands of a squatter. I still have the source and in fact just tried to contact Ben through Linked-In to ask about the status of the license and if he would consider reviving the project, and have had no response yet. I still have the latest source that Monte and I worked on and have been seriously thinking about sharpening my Perl-fu to get this working well. I have been using IPPlan for a few years for IPv4, and have actually contributed to the code base even though I work for a "telco". No doubt I am in the minority there. Anyway, looking at the code for IPPlan, it would be a helluva job to get it working well with IPv6, even if the architecture of IPPlan suited your needs (not a given). I will keep trying to contact Ben about FreeIPDB and if I can get a positive response then I hope to open the project back up in some way. Good luck, you are not alone. -- Mike Oliver, KT2T [see complete headers for contact information] +----------------------------------------------------------------------+ | KT2T When all else fails... AMATEUR RADIO THRIVES! KT2T | +----------------------------------------------------------------------+ | Serious about IPv6 yet? Why not? http://www.potaroo.net/tools/ipv4/ | +----------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090115/28024c0b/attachment.bin From mchughtai at gmail.com Sat Jan 17 04:59:43 2009 From: mchughtai at gmail.com (MSC) Date: Fri, 16 Jan 2009 22:59:43 -0500 Subject: IPv6 Subnet tool In-Reply-To: <20090115093206.GU44476@Space.Net> References: <701048556.38031231923791642.JavaMail.root@zimbra.nfsi.pt> <496DF9D5.5080002@memetic.org> <58AE1766-F894-4872-BB20-56C929D45923@hopcount.ca> <33766B49-FE97-40B1-BAD4-166F8EBC157F@virtualized.org> <496E4F4B.8030605@he.net> <20090114210956.GS44476@Space.Net> <8EF0099A-72B6-47E7-8168-7075D09D6AA0@hopcount.ca> <20090115093206.GU44476@Space.Net> Message-ID: <24b6ebc90901161959g46504f25u887ce24cf20f0534@mail.gmail.com> Thanks you all for your time. It was great help On Thu, Jan 15, 2009 at 4:32 AM, Gert Doering wrote: > Hi, > > On Wed, Jan 14, 2009 at 04:28:47PM -0500, Joe Abley wrote: > > I ran out of patience trying to find the v6 policy at RIPE. > > http://www.ripe.net/rs/ipv6/ -> "IPv6 Address Allocation ... Policy" -> > 5.4 "Assignments": > > ----------------- quote ------------- > 5.4.1. Assignment address space size > > End Users are assigned an End Site assignment from their LIR or > ISP. The size of the assignment is a local decision for the LIR or > ISP to make, using a minimum value of a /64 (only one subnet is > anticipated for the End Site). > > 5.4.2. Assignments shorter than a /48 to a single End Site > > When a single End Site requires an assignment shorter than a /48, > it must request the assignment with documentation or materials that > justify the request. Requests for multiple or additional prefixes > exceeding a /48 assignment for a single End Site will be processed > and reviewed (i.e., evaluation of justification) at the RIR/NIR > level. > ----------------- quote ------------- > > Gert Doering > -- RIPE APWG chair > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090116/006d7b18/attachment.html From iljitsch at muada.com Tue Jan 20 14:46:51 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 20 Jan 2009 14:46:51 +0100 Subject: Pirate Bay v6 breaks stuff? Message-ID: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> Hi, The Pirate Bay is rolling out IPv6: http://thepiratebay.org/blog/146 They now have an IPv6 tracker. I tried this with two clients (purely for research purposes, of course): Azureus 3.0.3.4 and the (original?) BitTorrent 4.1.7 python client. Neither of them could do anything useful when connected to the tracker over IPv6, and neither of them would fall back to IPv4 as far as I can tell. Anyone else seeing the same issues? As far as I know, the original BitTorrent specification allows for IPv6 but later updates optimized away the possibility of communicating IPv6 addresses or host names and only work with IPv4 addresses, but I have no idea about the capabilities of various software. Tip: if you're having this type of trouble on FreeBSD, this will make the client connect to the tracker over IPv6. Creating a Windows version of this command is left as an exercise for the reader. ip6addrctl add 2a01:298:3:1::2/128 5 1 From iljitsch at muada.com Tue Jan 20 14:55:19 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 20 Jan 2009 14:55:19 +0100 Subject: Pirate Bay v6 breaks stuff? In-Reply-To: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> References: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> Message-ID: <71014BD5-0854-4C68-93BC-199D3DB05E61@muada.com> On 20 jan 2009, at 14:46, Iljitsch van Beijnum wrote: > Tip: if you're having this type of trouble on FreeBSD, this will > make the client connect to the tracker over IPv6. Ugh, IPv4. > Creating a Windows version of this command is left as an exercise > for the reader. > ip6addrctl add 2a01:298:3:1::2/128 5 1 From jeroen at unfix.org Tue Jan 20 15:20:16 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 20 Jan 2009 15:20:16 +0100 Subject: Pirate Bay v6 breaks stuff? In-Reply-To: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> References: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> Message-ID: <4975DDA0.6090502@spaghetti.zurich.ibm.com> Iljitsch van Beijnum wrote: > Hi, > > The Pirate Bay is rolling out IPv6: > > http://thepiratebay.org/blog/146 > > They now have an IPv6 tracker. I tried this with two clients (purely for > research purposes, of course): Azureus 3.0.3.4 and the (original?) > BitTorrent 4.1.7 python client. Neither of them could do anything useful > when connected to the tracker over IPv6, and neither of them would fall > back to IPv4 as far as I can tell. The trick is that in the generic tracker protocol (the HTTP based one) one don't use the "peers" notation which is IPv4 only (just 32-bits repeated). > Anyone else seeing the same issues? Works for me(tm) and apparently a number of clients are able to use it IPv6: http://www.sixxs.net/tools/tracker/clients/ for a list. Note also that http://piratebay.org lists: 8<------------------------------------------------------------------------- IPv4 23.013.843 peers (10.345.077 seeders + 12.668.766 leechers) in 1.593.127 torrents on tracker. IPv6 17.142 peers (7.566 seeders + 9.576 leechers) in 15.523 torrents on tracker. RSS ------------------------------------------------------------------------->8 Thus, yes, there is content out there ;) > As far as I know, the original BitTorrent specification allows for IPv6 > but later updates optimized away the possibility of communicating IPv6 > addresses or host names and only work with IPv4 addresses, but I have no > idea about the capabilities of various software. They support it, as they don't use the peers notation for IPv6. See above. > Tip: if you're having this type of trouble on FreeBSD, this will make > the client connect to the tracker over IPv6. Creating a Windows version > of this command is left as an exercise for the reader. Your Prefix Policy should already prefer native IPv6 over native IPv4; 6to4 and Teredo is behind native IPv4 though. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090120/da8dc505/attachment.bin From ryan at u13.net Tue Jan 20 15:29:10 2009 From: ryan at u13.net (Ryan Rawdon) Date: Tue, 20 Jan 2009 09:29:10 -0500 Subject: Pirate Bay v6 breaks stuff? In-Reply-To: <4975DDA0.6090502@spaghetti.zurich.ibm.com> References: <9E2A4CF6-D9DF-4306-B7EF-2B48F227E4AD@muada.com> <4975DDA0.6090502@spaghetti.zurich.ibm.com> Message-ID: <4975DFB6.8000709@u13.net> I also tested out some stuff on TPB last night and had no issues with the IPv6-enabled setup (from a machine with v4 and v6 connectivity) Jeroen Massar wrote: > Iljitsch van Beijnum wrote: > >> Hi, >> >> The Pirate Bay is rolling out IPv6: >> >> http://thepiratebay.org/blog/146 >> >> They now have an IPv6 tracker. I tried this with two clients (purely for >> research purposes, of course): Azureus 3.0.3.4 and the (original?) >> BitTorrent 4.1.7 python client. Neither of them could do anything useful >> when connected to the tracker over IPv6, and neither of them would fall >> back to IPv4 as far as I can tell. >> > > The trick is that in the generic tracker protocol (the HTTP based one) > one don't use the "peers" notation which is IPv4 only (just 32-bits > repeated). > > >> Anyone else seeing the same issues? >> > > Works for me(tm) and apparently a number of clients are able to use it > IPv6: http://www.sixxs.net/tools/tracker/clients/ for a list. > > Note also that http://piratebay.org lists: > 8<------------------------------------------------------------------------- > IPv4 23.013.843 peers (10.345.077 seeders + 12.668.766 leechers) in > 1.593.127 torrents on tracker. > IPv6 17.142 peers (7.566 seeders + 9.576 leechers) in 15.523 torrents on > tracker. > RSS > ------------------------------------------------------------------------->8 > Thus, yes, there is content out there ;) > > >> As far as I know, the original BitTorrent specification allows for IPv6 >> but later updates optimized away the possibility of communicating IPv6 >> addresses or host names and only work with IPv4 addresses, but I have no >> idea about the capabilities of various software. >> > > They support it, as they don't use the peers notation for IPv6. See above. > > >> Tip: if you're having this type of trouble on FreeBSD, this will make >> the client connect to the tracker over IPv6. Creating a Windows version >> of this command is left as an exercise for the reader. >> > > Your Prefix Policy should already prefer native IPv6 over native IPv4; > 6to4 and Teredo is behind native IPv4 though. > > Greets, > Jeroen > > From jabley at hopcount.ca Wed Jan 21 23:28:54 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Jan 2009 17:28:54 -0500 Subject: dhcp pd on IOS Message-ID: Hi all, Does anybody happen to know what IOS releases support dhcp prefix delegation, e.g. as follows? interface Dialer1 ipv6 address autoconfig default ipv6 dhcp client pd LAN ! interface Vlan1 ipv6 address LAN 1111::1/64 CCO is being particularly inscrutable for me today, all kinds of links to dead documents and the feature navigator seems quite value-free. Joe From iljitsch at muada.com Wed Jan 21 23:35:03 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 21 Jan 2009 23:35:03 +0100 Subject: dhcp pd on IOS In-Reply-To: References: Message-ID: <2803DCCF-366A-40AA-A778-95C3532BAAF1@muada.com> On 21 jan 2009, at 23:28, Joe Abley wrote: > Does anybody happen to know what IOS releases support dhcp prefix > delegation, No, I'm not wasting neurons on Cisco's insanity. But I was able to do this on a bunch of test 2500s 5 years ago so I'd say it's in pretty much everything that does IPv6 except the SOHO boxes. From jabley at hopcount.ca Thu Jan 22 02:17:42 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Jan 2009 20:17:42 -0500 Subject: dhcp pd on IOS In-Reply-To: <2803DCCF-366A-40AA-A778-95C3532BAAF1@muada.com> References: <2803DCCF-366A-40AA-A778-95C3532BAAF1@muada.com> Message-ID: On 21 Jan 2009, at 17:35, Iljitsch van Beijnum wrote: > But I was able to do this on a bunch of test 2500s 5 years ago so > I'd say it's in pretty much everything that does IPv6 except the > SOHO boxes. The box I have to test with is an old 2600 running 12.3(23), and it doesn't work on there, hence the question. Good to know that DHCPv6 pd isn't necessarily a bleeding edge feature, however, if you used it in 2003. yxu1b#show version | include System image System image file is "flash:c2600-ik9o3s3-mz.123-23.bin" yxu1b#conf t Enter configuration commands, one per line. End with CNTL/Z. yxu1b(config)#int di2 yxu1b(config-if)#ipv6 address autoconfig default ^ % Invalid input detected at '^' marker. yxu1b(config-if)#ipv6 address autoconfig ? yxu1b(config-if)#ipv6 address autoconfig yxu1b(config-if)#ipv6 dhcp client pd LAN ^ % Invalid input detected at '^' marker. yxu1b(config-if)# Joe From gert at space.net Thu Jan 22 08:23:01 2009 From: gert at space.net (Gert Doering) Date: Thu, 22 Jan 2009 08:23:01 +0100 Subject: dhcp pd on IOS In-Reply-To: References: <2803DCCF-366A-40AA-A778-95C3532BAAF1@muada.com> Message-ID: <20090122072301.GR44476@Space.Net> Hi, On Wed, Jan 21, 2009 at 08:17:42PM -0500, Joe Abley wrote: > The box I have to test with is an old 2600 running 12.3(23), and it > doesn't work on there, hence the question. Good to know that DHCPv6 pd > isn't necessarily a bleeding edge feature, however, if you used it in > 2003. 12.3-main did not get new features since 12.3(1) in early 2003. Only bugfixes. But there have been 12.3T and 12.4T trains since then, who got all the new features. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From lists at hojmark.org Thu Jan 22 23:36:23 2009 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Thu, 22 Jan 2009 23:36:23 +0100 Subject: dhcp pd on IOS In-Reply-To: References: Message-ID: <61CC991E39604CF7B216800426CFC727@hojmark.net> > Does anybody happen to know what IOS releases support dhcp > prefix delegation Software forwarding platforms (traditional routers, e.g. 800, 2800, 7200): 12.3 T, 12.4, 12.4 T or newer. 3560: 12.2(46)SE 3750: 12.2(46)SE 7304: 12.2(33)SB 6500: 12.2(18)SXE 7600: 12.2(18)SXE, 12.2(33)SRA 10K : 12.2(33)SB ... or newer -A From iljitsch at muada.com Fri Jan 23 11:48:30 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 23 Jan 2009 11:48:30 +0100 Subject: dhcp pd on IOS In-Reply-To: References: <2803DCCF-366A-40AA-A778-95C3532BAAF1@muada.com> Message-ID: <043D69F9-0904-459D-93CC-DBE3FBEFE786@muada.com> On 22 jan 2009, at 2:17, Joe Abley wrote: >> But I was able to do this on a bunch of test 2500s 5 years ago so >> I'd say it's in pretty much everything that does IPv6 except the >> SOHO boxes. > The box I have to test with is an old 2600 running 12.3(23), and it > doesn't work on there, hence the question. Good to know that DHCPv6 > pd isn't necessarily a bleeding edge feature, however, if you used > it in 2003. Actually it was 2005 (I think I got the 5 from 2005) so 4 years ago, not 5. From maho at nic.dtag.de Fri Jan 30 13:04:38 2009 From: maho at nic.dtag.de (Martin Horneffer) Date: Fri, 30 Jan 2009 13:04:38 +0100 Subject: How to choose IPv6 addresses for customer links? Message-ID: <20090130120438.GA16878@nic.dtag.de> Hello, I'd like to collect opinions from the experienced IPv6 network engineers that meet here so nicely: Consider a service provider that provides IPv6 services to leased line customers. In almost all cases the customer gets a /48 out of the aggregate of the service provider. In many cases and probaly in most future-oriented cases the physical interface is some kind of ethernet (10/100/100/10000 Mbit/s). Thus the link to the customer needs its own addresses. Some customers might want operate their own routers and maintain several subnets. But some customers might also be happy with having just one subnet and probably some kind of (layer-2) switches. My questions is now: How should the addresses for the link network be chosen? My understanding would be that it might be best to select one /64 out of the customer's /48. And to route the complete /48 to one address of that /64. Thus the customer can easily put their hosts in the simple /64 if they only have layer-2 devices. Or they can set up their own router. It would have to use the address mentioned above from the link network and can use up to 65535 more /64 subnets. They lose one /64 for the link network, though. Would that be a sensible addressing scheme? Or would a customer insist to get a completely independet /64 for the link addresses? Best regards, Martin -- Dr. Martin Horneffer Deutsche Telekom Netzproduktion GmbH Technical Engineering Center Deutsche Telekom Netzproduktion GmbH Supervisory Board: Timotheus Hoettges (Chairman) Managing Board: Friedrich Fu? (Chairman), Albert Matheis, Klaus Peren Commercial register: Amtsgericht Bonn HRB 14190 Registered office: Bonn VAT ident. no.: DE 814645262 From md at Linux.IT Fri Jan 30 13:23:47 2009 From: md at Linux.IT (Marco d'Itri) Date: Fri, 30 Jan 2009 13:23:47 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: <20090130122347.GA14264@bongo.bofh.it> On Jan 30, Martin Horneffer wrote: > My understanding would be that it might be best to select one /64 out > of the customer's /48. And to route the complete /48 to one address of > that /64. This is what I do for colocation customers. I especially like having a single prefix from which the customer can originate traffic. The only open issue is if I should use :FFFF::/64 or :0000::/64 for the link, but so far I asked the customer for their preference. :-) > subnets. They lose one /64 for the link network, though. I do no think that this should be a concern... -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090130/cc02f8f4/attachment.bin From martin at airwire.ie Fri Jan 30 13:50:44 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 30 Jan 2009 12:50:44 +0000 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: <4982F7A4.2070102@airwire.ie> Martin Horneffer wrote: [SNIP] > Would that be a sensible addressing scheme? Or would a customer insist > to get a completely independet /64 for the link addresses? SixXS uses the approach commonly of assigning the link-addresses out of a seperate /48 in the PoP. One /40 per PoP. For native customers, we'll assign one /64 on the lan-side interface of the customers CPE and route the remainder of their allocation to a fixed address within that allocation. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From mohacsi at niif.hu Fri Jan 30 15:06:57 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 30 Jan 2009 15:06:57 +0100 (CET) Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: On Fri, 30 Jan 2009, Martin Horneffer wrote: > Hello, > > I'd like to collect opinions from the experienced IPv6 network > engineers that meet here so nicely: > > Consider a service provider that provides IPv6 services to leased line > customers. > In almost all cases the customer gets a /48 out of the aggregate of > the service provider. > In many cases and probaly in most future-oriented cases the physical > interface is some kind of ethernet (10/100/100/10000 Mbit/s). Thus the > link to the customer needs its own addresses. > Some customers might want operate their own routers and maintain > several subnets. But some customers might also be happy with having > just one subnet and probably some kind of (layer-2) switches. > > My questions is now: How should the addresses for the link network be > chosen? > > My understanding would be that it might be best to select one /64 out > of the customer's /48. And to route the complete /48 to one address of > that /64. > Thus the customer can easily put their hosts in the simple /64 if they > only have layer-2 devices. > Or they can set up their own router. It would have to use the address > mentioned above from the link network and can use up to 65535 more /64 > subnets. They lose one /64 for the link network, though. > > Would that be a sensible addressing scheme? Or would a customer insist > to get a completely independet /64 for the link addresses? I would ask you: - Did you implement infrastructure protection with infrastructure ACL? - protecting all you devices with edge filtering If yes, then I would ask a customer to allocate /64 from their address block, otherwise would be mode difficult to manage protection against the potential malicius traffic coming from outside. The selecting address for the last 64 bit is also a kind of challenge to prevent scanning attacks on this links see: rfc 5157 http://www.ietf.org/rfc/rfc5157.txt Best Regards, > > > Best regards, Martin > > -- > Dr. Martin Horneffer > Deutsche Telekom Netzproduktion GmbH > Technical Engineering Center > > Deutsche Telekom Netzproduktion GmbH > Supervisory Board: Timotheus Hoettges (Chairman) > Managing Board: Friedrich Fu? (Chairman), Albert Matheis, Klaus Peren > Commercial register: Amtsgericht Bonn HRB 14190 > Registered office: Bonn > VAT ident. no.: DE 814645262 > From jeroen at unfix.org Fri Jan 30 15:38:18 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 30 Jan 2009 15:38:18 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <4982F7A4.2070102@airwire.ie> References: <20090130120438.GA16878@nic.dtag.de> <4982F7A4.2070102@airwire.ie> Message-ID: <498310DA.1050003@spaghetti.zurich.ibm.com> Martin List-Petersen wrote: > Martin Horneffer wrote: > [SNIP] >> Would that be a sensible addressing scheme? Or would a customer insist >> to get a completely independet /64 for the link addresses? > > SixXS uses the approach commonly of assigning the link-addresses out of > a seperate /48 in the PoP. One /40 per PoP. To put a bit background there for that decision, if you 'steal' a /64 out of the customers /48 then the whole idea that the customer 'never has to change their numberplan because they keep a /48 when changing ISPs' goes away. Thus if they move from A t to B, and A uses the first /64 for the link, but B uses the last /64 or another for the transfer-link, then they have to renumber their network again. Also, it quite inconvieniences the customer who can't nicely chunk the /48 into /56's or something for eg per-building routes etc, as you stole a /64 out of one of those blocks. DHCP-PD also becomes easier as you say to it "this /48" instead of "this /48 but not this /64 out of that". Also if the complete /48 goes to the customer, then that is only one route. If you steal a /64 from it, you have a /48 and a /64 from the same block. Makes whois entries also clearer (you do register those /48's nicely with an IRT object in whois do you?) Thus IMHO and from my POV, use a /48 (or larger if you need >65k of these links) for transfer links. This also makes it easy for you to protect access links, eg just allow that /48 to do BGP with your routers and exclude anything else. And route a full /48 to the customer. Btw, you should have already done all of this when REQUESTING your prefix from RIPE. Numberplans are important to them, they should also be important to you. Sidenote: In the SixXS case where we effectively fully control the device that does the routing over the tunnels this addressingplan simplifies routing a lot as we know that prefixes from /48 are 'interfaces' (read: tunnels) to the users, while everything else has no specifics, we where thus able to optimize routing a lot because of that basically ignoring anything else ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090130/bc52fc54/attachment.bin From dwhite at olp.net Fri Jan 30 16:54:18 2009 From: dwhite at olp.net (Dan White) Date: Fri, 30 Jan 2009 09:54:18 -0600 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: <498322AA.8090506@olp.net> Martin Horneffer wrote: > Hello, > > I'd like to collect opinions from the experienced IPv6 network > engineers that meet here so nicely: > > Consider a service provider that provides IPv6 services to leased line > customers. > In almost all cases the customer gets a /48 out of the aggregate of > the service provider. > In many cases and probaly in most future-oriented cases the physical > interface is some kind of ethernet (10/100/100/10000 Mbit/s). Thus the > link to the customer needs its own addresses. > Some customers might want operate their own routers and maintain > several subnets. But some customers might also be happy with having > just one subnet and probably some kind of (layer-2) switches. > > My questions is now: How should the addresses for the link network be > chosen? > > My understanding would be that it might be best to select one /64 out > of the customer's /48. And to route the complete /48 to one address of > that /64. > Thus the customer can easily put their hosts in the simple /64 if they > only have layer-2 devices. > Or they can set up their own router. It would have to use the address > mentioned above from the link network and can use up to 65535 more /64 > subnets. They lose one /64 for the link network, though. > > Would that be a sensible addressing scheme? Or would a customer insist > to get a completely independet /64 for the link addresses? > > > Best regards, Martin > > I can't offer much experience on this situation, but I have a somewhat similar network environment, except that we use the VLAN-per-subscriber model. It seems that splitting out a /64 and routing to a specific IP defeats the purpose of having router advertisements. The approach I'm trying to design for is this (pardon the ASCII diagram): ---------------- ---------------- | Router A | | Router B | ---------------- ---------------- \ / \ / ----------------- | Transport | ----------------- / \ / \ -------------- | CPE | -------------- | | -------------- ------------- | cust. | | cust. | | router 1| | router 2| -------------- --------------- With all four routers (2 customer routers, 2 provider routers) participating in the same VLAN/Network. This should facilitate the failure of any one router, without operator intervention, as long as the two customer routers are allowed to advertise the same /48. Assignment to customer may be a static assignment or DHCP prefix delegation, but the IP block numbering will be based on some hash of the customer's VLAN (as previously suggested on this list). For the two routers on the provider side, Dibbler running on a Linux box seems to look promising. I can configure a VLAN interface on each router corresponding to each customer, which allows me to control DHCP/RA *to* the customer. It also gives me the option of configuring a /64 advertisement to each customer that does not wish to use a router, but connects clients directly to the (bridged) CPE. An issue I'm struggling with is how to filter router advertisements *from* the customer. I know which /48 advertisement I want to allow, on the specific vlan interface, but IP tables does not seem to let me filter on specific incoming RA routes. I'd be interested in any ideas how to accomplish that. - Dan From gert at space.net Fri Jan 30 18:15:57 2009 From: gert at space.net (Gert Doering) Date: Fri, 30 Jan 2009 18:15:57 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <498322AA.8090506@olp.net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> Message-ID: <20090130171557.GV44476@Space.Net> Hi, On Fri, Jan 30, 2009 at 09:54:18AM -0600, Dan White wrote: > It seems that splitting out a /64 and routing to a specific IP defeats > the purpose of having router advertisements. Router-Advertisements are not actually there to exchange information *among routers* - they convey information about things *on* this link, and not behind the other box. For your design, a routing protocol is what you want to use - preferably BGP (= easy filtering). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sabt at sabt.net Fri Jan 30 19:07:35 2009 From: sabt at sabt.net (Sebastian Abt) Date: Fri, 30 Jan 2009 19:07:35 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: <20090130180735.GB957@sephina.sabt.net> * Martin Horneffer wrote: > My understanding would be that it might be best to select one /64 out > of the customer's /48. And to route the complete /48 to one address of > that /64. > Thus the customer can easily put their hosts in the simple /64 if they > only have layer-2 devices. > Or they can set up their own router. It would have to use the address > mentioned above from the link network and can use up to 65535 more /64 > subnets. They lose one /64 for the link network, though. This is exactly what we do with our DSL-based IPv6 offer. Worked for us as well as for our customers so far. While I see the issues with this adressing scheme Jeroen mentioned, personally I don't believe that they're relevant in practice. Our motivation basically was to have a /48 assigned to/reserved for a customer and to not have to think about further adresses for this client. regards, sebastian -- SABT-RIPE PGPKEY-D008DA9C From martin at airwire.ie Fri Jan 30 20:14:52 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 30 Jan 2009 19:14:52 +0000 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130180735.GB957@sephina.sabt.net> References: <20090130120438.GA16878@nic.dtag.de> <20090130180735.GB957@sephina.sabt.net> Message-ID: <498351AC.4020103@airwire.ie> Sebastian Abt wrote: > * Martin Horneffer wrote: >> My understanding would be that it might be best to select one /64 out >> of the customer's /48. And to route the complete /48 to one address of >> that /64. >> Thus the customer can easily put their hosts in the simple /64 if they >> only have layer-2 devices. >> Or they can set up their own router. It would have to use the address >> mentioned above from the link network and can use up to 65535 more /64 >> subnets. They lose one /64 for the link network, though. > > This is exactly what we do with our DSL-based IPv6 offer. Worked for us > as well as for our customers so far. While I see the issues with this > adressing scheme Jeroen mentioned, personally I don't believe that > they're relevant in practice. Our motivation basically was to have a > /48 assigned to/reserved for a customer and to not have to think about > further adresses for this client. > With residential or consumer customers the need a seperate /64 (from the /48) shouldn't really arise. (talking about BGP etc.) Also from an allocation perspective it might be easier to just allocate a /48 (or reserve it), because you can give the customer a /64, increase it to /56 or /48 on demand. Obviously the claim could be made, that the SixXS approach is more IP conserving. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From pekkas at netcore.fi Fri Jan 30 20:27:39 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 30 Jan 2009 21:27:39 +0200 (EET) Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130120438.GA16878@nic.dtag.de> References: <20090130120438.GA16878@nic.dtag.de> Message-ID: On Fri, 30 Jan 2009, Martin Horneffer wrote: > Consider a service provider that provides IPv6 services to leased > line customers. In almost all cases the customer gets a /48 out of > the aggregate of the service provider. In many cases and probaly in > most future-oriented cases the physical interface is some kind of > ethernet (10/100/100/10000 Mbit/s). Thus the link to the customer > needs its own addresses. Actually, the link already has link-local addresses. You could just run it without any global address. But that has a caveat for another reason. When you need to configure static routes towards the customer, you're kinda stuck because you'd need to configure the nexthop to be a link-local address and that would not be fun for many reasons, including changes in CPE (MAC address change). Otherwise link-local would be great. FWIW, we're using an address out of customer's block; they can choose but the customers are organisations so this is not a provisioning problem. We also advertise those p2p addresses to our core. This has some tradeoffs. The good is that the link is pingable even if the address aggregate would happen to change so that the p2p link is no longer covered, and that if a customer is multihomed, pinging the p2p link from different places would cause non-deterministic routing. The bad is that for multihomed customers, strict uRPF requires a workaround. (See S3.2 of draft-savola-bcp84-urpf-experiences-03 for more.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dwhite at olp.net Fri Jan 30 21:38:00 2009 From: dwhite at olp.net (Dan White) Date: Fri, 30 Jan 2009 14:38:00 -0600 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130171557.GV44476@Space.Net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> Message-ID: <49836528.7020805@olp.net> Gert Doering wrote: > Hi, > > On Fri, Jan 30, 2009 at 09:54:18AM -0600, Dan White wrote: > >> It seems that splitting out a /64 and routing to a specific IP defeats >> the purpose of having router advertisements. >> > > Router-Advertisements are not actually there to exchange information > *among routers* - they convey information about things *on* this link, > and not behind the other box. > > For your design, a routing protocol is what you want to use - preferably > BGP (= easy filtering). > > Gert Doering > -- NetMaster > Yeah, I'm definitely confused. In the case where a customer router is performing DHCP prefix delegation, is the provider router installing a route at the time of assignment? With BGP, I suppose I will need to know the customer's two router addresses (or link layer addresses) at configuration time. - Dan From gert at space.net Fri Jan 30 22:49:53 2009 From: gert at space.net (Gert Doering) Date: Fri, 30 Jan 2009 22:49:53 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <49836528.7020805@olp.net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> Message-ID: <20090130214953.GX44476@Space.Net> Hi, On Fri, Jan 30, 2009 at 02:38:00PM -0600, Dan White wrote: > In the case where a customer router is performing DHCP prefix > delegation, is the provider router installing a route at the time of > assignment? It better should. (But this is not RA, this is DHCP PD :-) ). Actually, I have no practical experience with DHCP PD yet - but I can't really think of any useful way to have DHCP PD without installing a route at delegation time. > With BGP, I suppose I will need to know the customer's two router > addresses (or link layer addresses) at configuration time. Yep. Either "know" or just mandate ("we have :0:1 and :0:2, you have :1:1 and :1:2, period"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090130/b325d80e/attachment.bin From steve at ibctech.ca Sat Jan 31 03:23:30 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 30 Jan 2009 21:23:30 -0500 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090130214953.GX44476@Space.Net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> Message-ID: <4983B622.3010701@ibctech.ca> Gert Doering wrote: > Hi, > > On Fri, Jan 30, 2009 at 02:38:00PM -0600, Dan White wrote: >> In the case where a customer router is performing DHCP prefix >> delegation, is the provider router installing a route at the time of >> assignment? > > It better should. (But this is not RA, this is DHCP PD :-) ). > > Actually, I have no practical experience with DHCP PD yet - but I can't > really think of any useful way to have DHCP PD without installing a route > at delegation time. > >> With BGP, I suppose I will need to know the customer's two router >> addresses (or link layer addresses) at configuration time. > > Yep. Either "know" or just mandate ("we have :0:1 and :0:2, you have > :1:1 and :1:2, period"). ...and, if you assign a /64 global between eBGP peers (as opposed to anything longer), BGP will automagically configure the next-hop to the link-local: B>* 2001:478:235::/48 [20/0] via fe80::d8ea:2f09, gif1, 06:07:43 ...as opposed to this route, where a /128 global PtP is in place: B>* 2001:478:178::/48 [20/0] via 2001:4978:1:600::1, gif0, 06:08:14 What I haven't tested, but plan on doing so, is whether my theory that moving the IPv6 peering address from one source interface to another will not disrupt this link-local next-hop. You (Dan) are going to like BGP. I have had much fortune finding people to help me out with it, particularly in the v6 context. If you ever need any help testing a setup in the global context, email me off-list. So long as it's low-bandwidth, I'll do anything I can to pass along knowledge I've gained from others (including sessions (non-transit), VMs, test routers etc). When I help others learn, I'm either reinforcing knowledge, or having to research the unknown. Another thing that I'd like to point out, is that if _anyone_ is to consider toying with BGP, read, understand and ensure that you follow BCP 38, at minimum. Ask for guidance if necessary. This should be a prerequisite to turning-up your first test session. I've recently found that when one sanely organizes a question relating to proper network behaviour prior to implementation, and posts it to a high-profile list, the feedback is astounding. The 'big' good-guys really seem to like helping out the 'little' guys who are trying to do the right thing. As a matter of fact, (in my experience), they will go miles out of their way to help you become a trusted, albeit small, network. Sorry for swaying OT. I just felt that if BGP was mentioned, a recommendation to ensure network cleanliness was in order. Steve