From brokenflea at gmail.com Mon Aug 1 12:39:43 2011 From: brokenflea at gmail.com (Khurram Khan) Date: Mon, 1 Aug 2011 11:39:43 -0600 Subject: L3 Issues Message-ID: Hello and Good Morning, Are there reports of L3 having issues this morning ? Starting at about 10:10 A Pacific, I started seeing huge drops in traffic at various sites, including San Diego, Houston, San Antonio, Charlotte, NC, Philadelphia, etc. Anyone seeing a similar behavior ? From tad1214 at gmail.com Mon Aug 1 12:42:15 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Mon, 01 Aug 2011 12:42:15 -0500 Subject: L3 Issues In-Reply-To: References: Message-ID: On Mon, 01 Aug 2011 12:39:43 -0500, Khurram Khan wrote: > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? > Yes we are seeing Loss from Houston To LA (not NYC to LA) dropping out in Dallas -=Tom -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From dhubbard at dino.hostasaurus.com Mon Aug 1 12:43:17 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 1 Aug 2011 13:43:17 -0400 Subject: L3 Issues Message-ID: Seeing a big drop in outbound traffic on our L3 link starting about that time (we're a web host). Getting calls about sites down too; all the traces I've walked customers through so far have died on L3 networks. David > -----Original Message----- > From: Khurram Khan [mailto:brokenflea at gmail.com] > Sent: Monday, August 01, 2011 1:40 PM > To: nanog at nanog.org > Subject: L3 Issues > > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? > > > From brent at servuhome.net Mon Aug 1 12:44:40 2011 From: brent at servuhome.net (Brent Jones) Date: Mon, 1 Aug 2011 10:44:40 -0700 Subject: L3 Issues In-Reply-To: References: Message-ID: On Mon, Aug 1, 2011 at 10:39 AM, Khurram Khan wrote: > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? > > Seeing similar issues here. Traffic going over Level3 seems to be dying. -- Brent Jones brent at servuhome.net From mike at m5computersecurity.com Mon Aug 1 12:45:40 2011 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Mon, 1 Aug 2011 17:45:40 +0000 Subject: L3 Issues Message-ID: <81089688-1312220741-cardhu_decombobulator_blackberry.rim.net-1409085823-@b1.c3.bise6.blackberry> Yes. I am getting customer calls from people not able to reach us via Level3. ------Original Message------ From: Khurram Khan To: nanog at nanog.org Subject: L3 Issues Sent: Aug 1, 2011 10:39 AM Hello and Good Morning, Are there reports of L3 having issues this morning ? Starting at about 10:10 A Pacific, I started seeing huge drops in traffic at various sites, including San Diego, Houston, San Antonio, Charlotte, NC, Philadelphia, etc. Anyone seeing a similar behavior ? Sent from my Verizon Wireless BlackBerry From scott at sberkman.net Mon Aug 1 12:47:42 2011 From: scott at sberkman.net (Scott Berkman) Date: Mon, 1 Aug 2011 13:47:42 -0400 Subject: L3 Issues In-Reply-To: References: Message-ID: <02ba01cc5073$1d1665d0$57433170$@sberkman.net> We were seeing issues here as well, we have BGP to Level 3 down until they stabilize. We were seeing a number of sites as unreachable, but ping tests from the Level3 IP address on that interface were working. Looks like perhaps they stopped advertising our addresses or were advertising them through an incorrect path. -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Monday, August 01, 2011 1:43 PM To: nanog at nanog.org Subject: RE: L3 Issues Seeing a big drop in outbound traffic on our L3 link starting about that time (we're a web host). Getting calls about sites down too; all the traces I've walked customers through so far have died on L3 networks. David > -----Original Message----- > From: Khurram Khan [mailto:brokenflea at gmail.com] > Sent: Monday, August 01, 2011 1:40 PM > To: nanog at nanog.org > Subject: L3 Issues > > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? > > > From vasil at ludost.net Mon Aug 1 12:48:11 2011 From: vasil at ludost.net (Vasil Kolev) Date: Mon, 01 Aug 2011 20:48:11 +0300 Subject: L3 Issues In-Reply-To: References: Message-ID: <1312220891.5221.25.camel@shrike> ? 11:39 -0600 ?? 01.08.2011 (??), Khurram Khan ??????: > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? > Yes, l3 in Dallas is dropping about 40% of the traffic we're sending them. -- Regards, Vasil Kolev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jlewis at lewis.org Mon Aug 1 12:48:58 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 1 Aug 2011 13:48:58 -0400 (EDT) Subject: L3 Issues In-Reply-To: References: Message-ID: On Mon, 1 Aug 2011, Khurram Khan wrote: > Hello and Good Morning, > > Are there reports of L3 having issues this morning ? Starting at about > 10:10 A Pacific, I started seeing huge drops in traffic at various > sites, including San Diego, Houston, San Antonio, Charlotte, NC, > Philadelphia, etc. > Anyone seeing a similar behavior ? Yes...about the same time here...maybe a few minutes later. I was seeing traces stopping at ae-63-63.ebr3.Atlanta2.Level3.net. Things seem to be moving again. I just unshut our L3 BGP session. Interestingly, while Level3 was having problems, our local Akamai cluster was apparently not working properly. images.apple.com resolves to our local Akamai cluster, but requests there were timing out. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jason at lixfeld.ca Mon Aug 1 13:03:24 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 1 Aug 2011 14:03:24 -0400 Subject: =?iso-8859-1?Q?Community_troubleshooting_=E9tiquette/BCP_=28was?= =?iso-8859-1?Q?=3A_L3_Issues=29?= In-Reply-To: References: Message-ID: <81CCBB29-A43A-4B41-94D9-3E53896B9F7C@lixfeld.ca> On 2011-08-01, at 1:48 PM, Jon Lewis wrote: > Things seem to be moving again. I happen to have an L3 link out of NYC, but unfortunately I don't have a list of on-net L3 prefixes in any of the reportedly affected regions, so I'm unable to provide any data from my vantage point up here. I'm sure others are in my position as well. Is there any sort of etiquette/BCP for reporting issues like this to the community? Something that might specify a method of providing information a little more specific than just specifying the affected region(s)? Maybe a list of a few affected hosts/prefixes/URLS/etc? (incidentally, images.apple.com also resolves to our local Akamai cluster) From scott at sberkman.net Mon Aug 1 13:50:30 2011 From: scott at sberkman.net (Scott Berkman) Date: Mon, 1 Aug 2011 14:50:30 -0400 Subject: =?iso-8859-1?Q?RE:_Community_troubleshooting_=E9tiquette/BCP_=28was:_L3_I?= =?iso-8859-1?Q?ssues=29?= In-Reply-To: <81CCBB29-A43A-4B41-94D9-3E53896B9F7C@lixfeld.ca> References: <81CCBB29-A43A-4B41-94D9-3E53896B9F7C@lixfeld.ca> Message-ID: <030101cc507b$e3c43d30$ab4cb790$@sberkman.net> I did finally see a Level 3 network event posted about this in their portal. Actually they list two separate ones: A routing issue failure between Dallas, TX and Los Angeles, CA is impacting IP services. Impacted for: 1 hour 29 minutes A loss of connectivity to servers in Dallas, TX, Tustin, CA, and Tokyo, Japan caused an impact to CDN services. The second one probably explains the Akamai issues one poster mentioned. -----Original Message----- From: Jason Lixfeld [mailto:jason at lixfeld.ca] Sent: Monday, August 01, 2011 2:03 PM To: nanog at nanog.org Subject: Community troubleshooting ?tiquette/BCP (was: L3 Issues) On 2011-08-01, at 1:48 PM, Jon Lewis wrote: > Things seem to be moving again. I happen to have an L3 link out of NYC, but unfortunately I don't have a list of on-net L3 prefixes in any of the reportedly affected regions, so I'm unable to provide any data from my vantage point up here. I'm sure others are in my position as well. Is there any sort of etiquette/BCP for reporting issues like this to the community? Something that might specify a method of providing information a little more specific than just specifying the affected region(s)? Maybe a list of a few affected hosts/prefixes/URLS/etc? (incidentally, images.apple.com also resolves to our local Akamai cluster) From bjorn at mork.no Tue Aug 2 07:33:57 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 02 Aug 2011 14:33:57 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: (JORDI PALET MARTINEZ's message of "Tue, 26 Jul 2011 10:58:24 -0400") References: Message-ID: <877h6w9emi.fsf@nemi.mork.no> JORDI PALET MARTINEZ writes: > I will like to know, from those deploying IPv6 services to residential > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > Just to be clear, I'm for static prefix delegation to residential > customers, however I heard that some ISPs are doing dynamic delegations, > the same way as is common today with IPv4. > > I don't thin it make sense, as the main reason for doing so in IPv4 was > address exhaustion and legacy oversubscription models such as PPP/dial-up. We will do "semi-static" PD for residential users. In practice most users will see this as static, but we may reallocate users if necessary to preserve aggregation. One point I often miss in the endless discussions wrt dynamic/static IPv6 with references to the dynamic IPv4 world, is the lack of RFC1918 addressing for IPv6. The fact is that all residential users are used to, and depend on, static IPv4 addressing within their own network. They assign e.g. 192.168.5.5 to their printer and 192.168.5.6 to their NAS, and trust that those addresses are static. Now moving to IPv6, their choices are either link local or a static delegated prefix. Link local will of course work and be completely static for a given device, but does have a couple of drawbacks which I believe will make most users want a static global prefix instead: - ugly addresses, often not configurable - the need to specify outgoing interface on any PC/whatever you want to talk to the link local addresss For this reason, I argue that residential users are used to static IPv4 addresses and will demand static IPv6 addresses. The fact that their globally routed IPv4 address is dynamic is completely irrelevant as long as a similar mechanism isn't available for IPv6 (no, I won't mention NAT66). Bj?rn From marka at isc.org Tue Aug 2 09:32:38 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Aug 2011 00:32:38 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 02 Aug 2011 14:33:57 +0200." <877h6w9emi.fsf@nemi.mork.no> References: <877h6w9emi.fsf@nemi.mork.no> Message-ID: <20110802143239.028B31261C13@drugs.dv.isc.org> In message <877h6w9emi.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes: > JORDI PALET MARTINEZ writes: > > > I will like to know, from those deploying IPv6 services to residential > > customers, if you are planning to provide static or dynamic IPv6 prefixes. > > > > Just to be clear, I'm for static prefix delegation to residential > > customers, however I heard that some ISPs are doing dynamic delegations, > > the same way as is common today with IPv4. > > > > I don't thin it make sense, as the main reason for doing so in IPv4 was > > address exhaustion and legacy oversubscription models such as PPP/dial-up. > > We will do "semi-static" PD for residential users. In practice most > users will see this as static, but we may reallocate users if necessary > to preserve aggregation. > > One point I often miss in the endless discussions wrt dynamic/static > IPv6 with references to the dynamic IPv4 world, is the lack of RFC1918 > addressing for IPv6. The fact is that all residential users are used > to, and depend on, static IPv4 addressing within their own network. > They assign e.g. 192.168.5.5 to their printer and 192.168.5.6 to their > NAS, and trust that those addresses are static. > > Now moving to IPv6, their choices are either link local or a static > delegated prefix. Link local will of course work and be completely > static for a given device, but does have a couple of drawbacks which I > believe will make most users want a static global prefix instead: > - ugly addresses, often not configurable > - the need to specify outgoing interface on any PC/whatever you want to > talk to the link local addresss > > For this reason, I argue that residential users are used to static IPv4 > addresses and will demand static IPv6 addresses. The fact that their > globally routed IPv4 address is dynamic is completely irrelevant as long > as a similar mechanism isn't available for IPv6 (no, I won't mention > NAT66).=20 en1: flags=8863 mtu 1500 ether 60:33:4b:01:75:85 inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf media: autoselect status: active Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. If you want to give your printers, etc. stable IPv6 addesses use ULAs. > Bj=C3=B8rn > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From leo.vegoda at icann.org Tue Aug 2 10:37:50 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 2 Aug 2011 08:37:50 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <877h6w9emi.fsf@nemi.mork.no> References: <877h6w9emi.fsf@nemi.mork.no> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341824F4219818@EXVPMBX100-1.exc.icann.org> You wrote: > One point I often miss in the endless discussions wrt dynamic/static > IPv6 with references to the dynamic IPv4 world, is the lack of RFC1918 > addressing for IPv6. The fact is that all residential users are used > to, and depend on, static IPv4 addressing within their own network. > They assign e.g. 192.168.5.5 to their printer and 192.168.5.6 to their > NAS, and trust that those addresses are static. They can do this with a ULA prefix if they want (RFC 4193). It is both private and most likely (really, very, very likely) unique. This assumes they only want their printer or NAS to be accessible on their own local network. Regards, Leo From owen at delong.com Tue Aug 2 12:17:42 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 10:17:42 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110802143239.028B31261C13@drugs.dv.isc.org> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> Message-ID: <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> > > en1: flags=8863 mtu 1500 > ether 60:33:4b:01:75:85 > inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 > inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 > inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf > inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf > media: autoselect > status: active > > Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. > If you want to give your printers, etc. stable IPv6 addesses use ULAs. > Icky. Better yet, just subscribe to an ISP that will give you a static prefix. Owen From tony.mccrory at gmail.com Tue Aug 2 12:28:20 2011 From: tony.mccrory at gmail.com (Tony McCrory) Date: Tue, 2 Aug 2011 18:28:20 +0100 Subject: Netvision.net.il contact Message-ID: Hi, Does anyone have a contact for Netvision's NOC? Can't get any response from noc at netvision.co.il, and they're causing me some operational issues. Thanks Tony From joelja at bogus.com Tue Aug 2 12:28:05 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 2 Aug 2011 10:28:05 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> Message-ID: On Aug 2, 2011, at 10:17 AM, Owen DeLong wrote: >> >> en1: flags=8863 mtu 1500 >> ether 60:33:4b:01:75:85 >> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 >> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 >> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf >> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf >> media: autoselect >> status: active >> >> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. >> If you want to give your printers, etc. stable IPv6 addesses use ULAs. >> > > Icky. > > > Better yet, just subscribe to an ISP that will give you a static prefix. Some (probably all) networks need addressing even when they're not attached to a provider. while link-local is necessary it's also probably not sufficient. > Owen > > From Bryan.Welch at arrisi.com Tue Aug 2 12:33:39 2011 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 2 Aug 2011 10:33:39 -0700 Subject: Twitter Contact Message-ID: Anyone from Twitter monitoring the list? Please contact me offline. Regards, Bryan From arnold at nipper.de Tue Aug 2 12:46:20 2011 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 02 Aug 2011 19:46:20 +0200 Subject: Netvision.net.il contact In-Reply-To: References: Message-ID: <4E3837EC.1070705@nipper.de> on 02.08.2011 19:28 Tony McCrory wrote: > Does anyone have a contact for Netvision's NOC? Can't get any > response from noc at netvision.co.il, and they're causing me some > operational issues. > whois -h whois.peeringdb.com as1680 | egrep 'Role|NOC' Role Name E-Mail Phone NOC NMCC nmcc at 013netvision.co.il +972-3-9001133 Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 152 53717690 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From caldcv at gmail.com Tue Aug 2 12:52:26 2011 From: caldcv at gmail.com (Chris) Date: Tue, 2 Aug 2011 13:52:26 -0400 Subject: Netvision.net.il contact In-Reply-To: References: Message-ID: Good luck to you. Botnets are a low priority to NOC / Abuse on Netvision, even hosting botnet IRCd on a home network connection. On Tue, Aug 2, 2011 at 1:28 PM, Tony McCrory wrote: > Hi, > > Does anyone have a contact for Netvision's NOC? ?Can't get any > response from noc at netvision.co.il, and they're causing me some > operational issues. > > Thanks > > Tony > > -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From igor at ergens.org Tue Aug 2 12:58:18 2011 From: igor at ergens.org (Igor Ybema) Date: Tue, 2 Aug 2011 19:58:18 +0200 Subject: someone from verisign? website down over ipv6 In-Reply-To: References: Message-ID: > I've been told that this is fixed now. ?Can you confirm? Correct. Site is working now over a tunneled ipv6. Great work! > Still working on the whois problem. Good luck with this. regards, Igor From owen at delong.com Tue Aug 2 14:24:31 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 12:24:31 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> Message-ID: <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> On Aug 2, 2011, at 10:28 AM, Joel Jaeggli wrote: > > On Aug 2, 2011, at 10:17 AM, Owen DeLong wrote: > >>> >>> en1: flags=8863 mtu 1500 >>> ether 60:33:4b:01:75:85 >>> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 >>> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 >>> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf >>> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf >>> media: autoselect >>> status: active >>> >>> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. >>> If you want to give your printers, etc. stable IPv6 addesses use ULAs. >>> >> >> Icky. >> >> >> Better yet, just subscribe to an ISP that will give you a static prefix. > > Some (probably all) networks need addressing even when they're not attached to a provider. > I don't understand why this is a problem if your ISP gives you a static address. There are, of course, other sources of addresses available as well. Nobody has yet presented me a situation where I would prefer to use ULA over GUA. > while link-local is necessary it's also probably not sufficient. > True. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From khelms at ispalliance.net Tue Aug 2 14:38:53 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 02 Aug 2011 15:38:53 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341824F4219818@EXVPMBX100-1.exc.icann.org> References: <877h6w9emi.fsf@nemi.mork.no> <41F6C547EA49EC46B4EE1EB2BC2F341824F4219818@EXVPMBX100-1.exc.icann.org> Message-ID: <4E38524D.8080503@ispalliance.net> that those addresses are static. > They can do this with a ULA prefix if they want (RFC 4193). It is both private and most likely (really, very, very likely) unique. This assumes they only want their printer or NAS to be accessible on their own local network. > > Regards, > > Leo That is the case in the vast majority of situations. Many users want to be able to access their home network resources remotely on occasion but they don't want everyone else to be able to and printers and other appliances have little if any security built into them. The paradigm of internal versus external networking is going to be very hard to educate past given that most users are comfortable with how it works today. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From sreed at nwwnet.net Tue Aug 2 14:46:35 2011 From: sreed at nwwnet.net (Scott Reed) Date: Tue, 02 Aug 2011 15:46:35 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> Message-ID: <4E38541B.3060003@nwwnet.net> And just how are you going to make all of us small ISPs, or the big ones for that matter, do that? I don't disagree with you, but I think the conversation needs to continue assuming that is not going to happen. And that may not be what happens within a large organization that uses private connections to consolidate connects to the Internet. On 8/2/2011 1:17 PM, Owen DeLong wrote: >> en1: flags=8863 mtu 1500 >> ether 60:33:4b:01:75:85 >> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 >> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 >> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf >> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf >> media: autoselect >> status: active >> >> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. >> If you want to give your printers, etc. stable IPv6 addesses use ULAs. >> > Icky. > > > Better yet, just subscribe to an ISP that will give you a static prefix. > > Owen > > > -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060 (765) 439-4253 (855) 231-6239 From hvgeekwtrvl at gmail.com Tue Aug 2 14:51:11 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 2 Aug 2011 12:51:11 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: > I don't understand why this is a problem if your ISP gives you a static address. > There are, of course, other sources of addresses available as well. > Nobody has yet presented me a situation where I would prefer to use ULA over GUA. > >> while link-local is necessary it's also probably not sufficient. >> >t > True. > > Owen Lets look at some issues here. 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat will be able to qualify for their own end user assignment from ARIN. 2) if their router goes down they loose network connectivity on the same subnet due to loosing their ISP assigned prefix. 3) If they are getting dynamic IP's from their ISP and it changes they may or may not be able to print, connect to a share, things like that. these 3 items make a case for everybody having a ULA. however while many of the technical bent will be able to manage multiple addresses I know how much tech support I'll be providing my parents with either an IP address that goes away/changes or multiple IP addresses. I'll set them up on a ULA so there is consistency. Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 made things such as these much nicer in a home and business setting. james From jra at baylink.com Tue Aug 2 14:56:05 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 2 Aug 2011 15:56:05 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Message-ID: <17132633.281.1312314965192.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "james machado" > Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 > made things such as these much nicer in a home and business setting. An argument I've been making right along. Concern about what's happening network-wise outside my edge router belongs to my edge router, *and no other device on my LAN* should be held hostage by problems there. That's my best practice advice (to my clients, at least), and if IPv6 makes that impossible, well, then, things are gonna get messy, until someone figures out a way around it, cause I'm sure I'm not the only person who views it that way... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Tue Aug 2 15:05:20 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 13:05:20 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E38541B.3060003@nwwnet.net> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38541B.3060003@nwwnet.net> Message-ID: <30AAC04B-8C37-4A2C-9E30-DE951867B8E1@delong.com> On Aug 2, 2011, at 12:46 PM, Scott Reed wrote: > And just how are you going to make all of us small ISPs, or the big ones for that matter, do that? Well, if you want my business, you'll do it. If not, I'll route around you as damage. If enough customers approach the problem this way, it will happen. In addition, I think a large number of providers are already seeing that static is, for the most part, just simpler to manage in IPv6 and considering going that way. The cable MSOs are the obvious exception for semi-obvious reasons specific to their technology. > I don't disagree with you, but I think the conversation needs to continue assuming that is not going to happen. Why assume the less likely case will come to pass? IMHO, static is more likely than dynamic given the forces at play. > And that may not be what happens within a large organization that uses private connections to consolidate connects to the Internet. > A large organization that does that should get their own PI space and multihome. Why would they do anything else? Owen > On 8/2/2011 1:17 PM, Owen DeLong wrote: >>> en1: flags=8863 mtu 1500 >>> ether 60:33:4b:01:75:85 >>> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 >>> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 >>> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf >>> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf >>> media: autoselect >>> status: active >>> >>> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. >>> If you want to give your printers, etc. stable IPv6 addesses use ULAs. >>> >> Icky. >> >> >> Better yet, just subscribe to an ISP that will give you a static prefix. >> >> Owen >> >> >> > > -- > Scott Reed > Owner > NewWays Networking, LLC > Wireless Networking > Network Design, Installation and Administration > > > > Mikrotik Advanced Certified > > www.nwwnet.net > (765) 855-1060 > (765) 439-4253 > (855) 231-6239 > > From owen at delong.com Tue Aug 2 15:09:40 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 13:09:40 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: On Aug 2, 2011, at 12:51 PM, james machado wrote: >> I don't understand why this is a problem if your ISP gives you a static address. >> There are, of course, other sources of addresses available as well. >> Nobody has yet presented me a situation where I would prefer to use ULA over GUA. >> >>> while link-local is necessary it's also probably not sufficient. >>> >> t >> True. >> >> Owen > > Lets look at some issues here. > > 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat > will be able to qualify for their own end user assignment from ARIN. > Interesting... I have a "normal household". I lack 2.5 kids and have no dog or cat. I have my own ARIN assignment. Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't find such a statement in ARIN policy. Are you saying that a household that multihomes is abnormal? Perhaps today, but, not necessarily so in the future. > 2) if their router goes down they loose network connectivity on the > same subnet due to loosing their ISP assigned prefix. > I keep hearing this myth, and I really do not understand where it comes from. If they get a static prefix from their ISP and configure it into their router and/or other equipment, it does not go away when they loose their router. It simply isn't true. > 3) If they are getting dynamic IP's from their ISP and it changes they > may or may not be able to print, connect to a share, things like that. > Perhaps, but, this is another reason that I think sane customers will start demanding static IPv6 from their providers in relatively short order. > these 3 items make a case for everybody having a ULA. however while > many of the technical bent will be able to manage multiple addresses I > know how much tech support I'll be providing my parents with either an > IP address that goes away/changes or multiple IP addresses. I'll set > them up on a ULA so there is consistency. > No, they don't. They make a great case for giving people static GUA. > Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 > made things such as these much nicer in a home and business setting. > No, it really didn't. If IPv4 had contained enough addresses we probably wouldn't have always-on dynamic connections in the first place. Owen From khelms at ispalliance.net Tue Aug 2 15:16:03 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 02 Aug 2011 16:16:03 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <30AAC04B-8C37-4A2C-9E30-DE951867B8E1@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38541B.3060003@nwwnet.net> <30AAC04B-8C37-4A2C-9E30-DE951867B8E1@delong.com> Message-ID: <4E385B03.1090509@ispalliance.net> On 8/2/2011 4:05 PM, Owen DeLong wrote: > On Aug 2, 2011, at 12:46 PM, Scott Reed wrote: > >> And just how are you going to make all of us small ISPs, or the big ones for that matter, do that? > Well, if you want my business, you'll do it. > > If not, I'll route around you as damage. If enough customers approach the problem this way, it will happen. No disrespect intended, but I don't think you're representative of the average or even above average ISP customer. For that matter neither are the majority of the participants on this list. > > In addition, I think a large number of providers are already seeing that static is, for the most part, just simpler > to manage in IPv6 and considering going that way. The cable MSOs are the obvious exception for semi-obvious > reasons specific to their technology. From my observations only the cable MSOs are even somewhat prepared for IPv6 because Cablelabs included it in the DOCSIS 3.0 spec. The DSL and FTTx networks I've seen are much further behind to the point that only some kind of tunneling (mainly RD) makes sense as a transition technology because of the layer 2 challenges. > A large organization that does that should get their own PI space and > multihome. Why would they do anything else? Owen I thought we were talking about residential users specifically here... -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From hvgeekwtrvl at gmail.com Tue Aug 2 16:42:58 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 2 Aug 2011 14:42:58 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: >> Lets look at some issues here. >> >> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >> will be able to qualify for their own end user assignment from ARIN. >> > > Interesting... > > I have a "normal household". > I lack 2.5 kids and have no dog or cat. > > I have my own ARIN assignment. > > Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't > find such a statement in ARIN policy. > > Are you saying that a household that multihomes is abnormal? Perhaps today, > but, not necessarily so in the future. > Yes I am saying a household that mulithomes is abnormal and with today's and contracted monopolies I expect that to continue. You are not a normal household in that 1) you multihome 2) you are willing to pay $1500+ US a year for your own AS, IP assignments 3) Internet service, much like cell phone service is a commodity product and many people go for the lowest price. They are not looking for the best options. >> 2) if their router goes down they loose network connectivity on the >> same subnet due to loosing their ISP assigned prefix. > > I keep hearing this myth, and I really do not understand where it comes from. > If they get a static prefix from their ISP and configure it into their router and/or > other equipment, it does not go away when they loose their router. It simply > isn't true. If they are using RA's to assign their network and the router goes down they can loose the network as well as the router thus going to link-local addresses. This has been discusses ad-nauseum on this list. As I recall you played a big part of that discussion and it was very interesting and informative. > >> 3) If they are getting dynamic IP's from their ISP and it changes they >> may or may not be able to print, connect to a share, things like that. >> > Perhaps, but, this is another reason that I think sane customers will start demanding > static IPv6 from their providers in relatively short order. > I hope this happens but I'm guessing that with marketing and sales in the mix it will be another up charge to get this "service" and enough people won't pay it that we will be fighting these problems for a long time. Some businesses will pay it and some won't but the home user will probably not. >> these 3 items make a case for everybody having a ULA. ?however while >> many of the technical bent will be able to manage multiple addresses I >> know how much tech support I'll be providing my parents with either an >> IP address that goes away/changes or multiple IP addresses. ?I'll set >> them up on a ULA so there is consistency. >> > > No, they don't. They make a great case for giving people static GUA. These are businesses were talking about. They are not going to "give" anything away. > >> Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 >> made things such as these much nicer in a home and business setting. >> > > No, it really didn't. If IPv4 had contained enough addresses we probably > wouldn't have always-on dynamic connections in the first place. > Debatable but not worth an argument. Having said that the ability to 1) not have to renumber internal address space on changing ISPs 2) not having to give a printer (or other device with no security) a public IP address or run multiple addressing schemes and the security implications there of 3) change the internals of my network without worrying about the world are all important and critical issues for me. I realize that these arguments are at layers 8 & 9 of the OSI model (politics and religion) but that does not make them less real nor less important. They are not the same issues that ISP operators may normally have to deal with but they are crucial to business operators. The DSCP/RA arguments are of the same criticality and importance. > Owen > james From joelja at bogus.com Tue Aug 2 17:28:02 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 2 Aug 2011 15:28:02 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: <711BA319-B23B-4777-A8AA-E6220A0EC1F7@bogus.com> On Aug 2, 2011, at 2:42 PM, james machado wrote: >>> Lets look at some issues here. >>> >>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>> will be able to qualify for their own end user assignment from ARIN. >>> >> >> Interesting... >> >> I have a "normal household". >> I lack 2.5 kids and have no dog or cat. >> >> I have my own ARIN assignment. >> >> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >> find such a statement in ARIN policy. >> >> Are you saying that a household that multihomes is abnormal? Perhaps today, >> but, not necessarily so in the future. >> > > Yes I am saying a household that mulithomes is abnormal and with > today's and contracted monopolies I expect that to continue. You are > not a normal household in that 1) you multihome 2) you are willing to > pay $1500+ US a year for your own AS, IP assignments while I don't disagree with the assertion that this is unrealistic the annual fee is $100 per org-id for direct assignments. > 3) Internet > service, much like cell phone service is a commodity product and many > people go for the lowest price. They are not looking for the best > options. > >>> 2) if their router goes down they loose network connectivity on the >>> same subnet due to loosing their ISP assigned prefix. >> >> I keep hearing this myth, and I really do not understand where it comes from. >> If they get a static prefix from their ISP and configure it into their router and/or >> other equipment, it does not go away when they loose their router. It simply >> isn't true. > > If they are using RA's to assign their network and the router goes > down they can loose the network as well as the router thus going to > link-local addresses. This has been discusses ad-nauseum on this > list. As I recall you played a big part of that discussion and it was > very interesting and informative. > >> >>> 3) If they are getting dynamic IP's from their ISP and it changes they >>> may or may not be able to print, connect to a share, things like that. >>> >> Perhaps, but, this is another reason that I think sane customers will start demanding >> static IPv6 from their providers in relatively short order. >> > > I hope this happens but I'm guessing that with marketing and sales in > the mix it will be another up charge to get this "service" and enough > people won't pay it that we will be fighting these problems for a long > time. Some businesses will pay it and some won't but the home user > will probably not. > >>> these 3 items make a case for everybody having a ULA. however while >>> many of the technical bent will be able to manage multiple addresses I >>> know how much tech support I'll be providing my parents with either an >>> IP address that goes away/changes or multiple IP addresses. I'll set >>> them up on a ULA so there is consistency. >>> >> >> No, they don't. They make a great case for giving people static GUA. > > These are businesses were talking about. They are not going to "give" > anything away. > >> >>> Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 >>> made things such as these much nicer in a home and business setting. >>> >> >> No, it really didn't. If IPv4 had contained enough addresses we probably >> wouldn't have always-on dynamic connections in the first place. >> > > Debatable but not worth an argument. Having said that the ability to > 1) not have to renumber internal address space on changing ISPs 2) not > having to give a printer (or other device with no security) a public > IP address or run multiple addressing schemes and the security > implications there of 3) change the internals of my network without > worrying about the world are all important and critical issues for me. > > I realize that these arguments are at layers 8 & 9 of the OSI model > (politics and religion) but that does not make them less real nor less > important. They are not the same issues that ISP operators may > normally have to deal with but they are crucial to business operators. > The DSCP/RA arguments are of the same criticality and importance. > >> Owen >> > > james > > From hvgeekwtrvl at gmail.com Tue Aug 2 17:37:50 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 2 Aug 2011 15:37:50 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <711BA319-B23B-4777-A8AA-E6220A0EC1F7@bogus.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <711BA319-B23B-4777-A8AA-E6220A0EC1F7@bogus.com> Message-ID: On Tue, Aug 2, 2011 at 3:28 PM, Joel Jaeggli wrote: > > On Aug 2, 2011, at 2:42 PM, james machado wrote: > >>>> Lets look at some issues here. >>>> >>>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>>> will be able to qualify for their own end user assignment from ARIN. >>>> >>> >>> Interesting... >>> >>> I have a "normal household". >>> I lack 2.5 kids and have no dog or cat. >>> >>> I have my own ARIN assignment. >>> >>> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >>> find such a statement in ARIN policy. >>> >>> Are you saying that a household that multihomes is abnormal? Perhaps today, >>> but, not necessarily so in the future. >>> >> >> Yes I am saying a household that mulithomes is abnormal and with >> today's and contracted monopolies I expect that to continue. ?You are >> not a normal household in that 1) you multihome 2) you are willing to >> pay $1500+ US a year for your own AS, IP assignments > > while I don't disagree with the assertion that this is unrealistic the annual fee is $100 per org-id for direct assignments. sorry was unclear - I was guessing $1500+ for ASnumer + IP Assignments but not counting ISP costs for a year. Looks like ARIN is charging about $1250 per year for a new IPv6 assignment and the AS yearly cost is rolled into that. Granted ISP costs will probably be in the ballpark of $150 per month for 2 consumer grade connections and more for business or better connections. James From joelja at bogus.com Tue Aug 2 17:50:26 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 2 Aug 2011 15:50:26 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <711BA319-B23B-4777-A8AA-E6220A0EC1F7@bogus.com> Message-ID: <14EE311B-C916-4B57-A1FB-DDAE55DF54C2@bogus.com> On Aug 2, 2011, at 3:37 PM, james machado wrote: >>>> >>> >>> Yes I am saying a household that mulithomes is abnormal and with >>> today's and contracted monopolies I expect that to continue. You are >>> not a normal household in that 1) you multihome 2) you are willing to >>> pay $1500+ US a year for your own AS, IP assignments >> >> while I don't disagree with the assertion that this is unrealistic the annual fee is $100 per org-id for direct assignments. > > > sorry was unclear - I was guessing $1500+ for ASnumer + IP Assignments > but not counting ISP costs for a year. Looks like ARIN is charging > about $1250 per year for a new IPv6 assignment and the AS yearly cost > is rolled into that. Granted ISP costs will probably be in the > ballpark of $150 per month for 2 consumer grade connections and more > for business or better connections. multihomed end users (e.g. generally businesses) are not ISPs they pay only once for the assignment, and annually only $100 in total to maintain their orgid. https://www.arin.net/fees/fee_schedule.html > > James > > From owen at delong.com Tue Aug 2 19:03:46 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 17:03:46 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: On Aug 2, 2011, at 2:42 PM, james machado wrote: >>> Lets look at some issues here. >>> >>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>> will be able to qualify for their own end user assignment from ARIN. >>> >> >> Interesting... >> >> I have a "normal household". >> I lack 2.5 kids and have no dog or cat. >> >> I have my own ARIN assignment. >> >> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >> find such a statement in ARIN policy. >> >> Are you saying that a household that multihomes is abnormal? Perhaps today, >> but, not necessarily so in the future. >> > > Yes I am saying a household that mulithomes is abnormal and with > today's and contracted monopolies I expect that to continue. You are > not a normal household in that 1) you multihome 2) you are willing to > pay $1500+ US a year for your own AS, IP assignments 3) Internet > service, much like cell phone service is a commodity product and many > people go for the lowest price. They are not looking for the best > options. > 1) yes. 2) Uh, no. I pay $100/year to ARIN for all of my IP resources. I really don't know where this $1,500+/year myth keeps coming from. I bet most households pay more than $100/year for their internet access. Heck, if you pay Comcast $5/month for a single static IP, you're paying more than half of what I pay for 1,208,925,819,614,629,174,706,944 addresses and an AS Number. If you pay $9/month for 10 static IPs to Comcast (these are their current rates, btw), you are paying them MORE than I pay ($108 instead of $100) per year. 3) I think people do some of both. I think that if people can get static for the same price, they will choose static over dynamic. I think that some will even choose to use their dynamic to run tunnels where they can get static. You can get free static tunnels for IPv6 today. So, no, the monopoly problem does not prevent what I am doing from being done in most households because: 1. Most monopolies are actually at least duopolies with at least one cable and at least one DSL or PON provider. 2. Contract monopolies are actually reducing rather than growing. >>> 2) if their router goes down they loose network connectivity on the >>> same subnet due to loosing their ISP assigned prefix. >> >> I keep hearing this myth, and I really do not understand where it comes from. >> If they get a static prefix from their ISP and configure it into their router and/or >> other equipment, it does not go away when they loose their router. It simply >> isn't true. > > If they are using RA's to assign their network and the router goes > down they can loose the network as well as the router thus going to > link-local addresses. This has been discusses ad-nauseum on this > list. As I recall you played a big part of that discussion and it was > very interesting and informative. > 1. Why would you use RAs to assign numbers to things you want to work when the router goes down. 2. This presumes they have only one router. There is no reason, given static addressing, that they cannot have a High and a Medium priority router. The High priority router provides connectivity to the ISP and the medium priority router is essentially /dev/null, but, keeps the addresses active. Yes, it has been discussed before, but, it continues to be made clear that people are still applying a mixture of misinformation and IPv4-think to the IPv6 situation, so, I continue to work towards better education. >> >>> 3) If they are getting dynamic IP's from their ISP and it changes they >>> may or may not be able to print, connect to a share, things like that. >>> >> Perhaps, but, this is another reason that I think sane customers will start demanding >> static IPv6 from their providers in relatively short order. >> > > I hope this happens but I'm guessing that with marketing and sales in > the mix it will be another up charge to get this "service" and enough > people won't pay it that we will be fighting these problems for a long > time. Some businesses will pay it and some won't but the home user > will probably not. > Amusingly, I have, so far, refused to pay it to Comcast on my business class service. Every once in a while, they renumber my address and I have to reconfigure my tunnel. (I'm using commodity internet access for layer 2 transport into my home. The BGP is done between my home router and routers in colo facilities via GRE). >>> these 3 items make a case for everybody having a ULA. however while >>> many of the technical bent will be able to manage multiple addresses I >>> know how much tech support I'll be providing my parents with either an >>> IP address that goes away/changes or multiple IP addresses. I'll set >>> them up on a ULA so there is consistency. >>> >> >> No, they don't. They make a great case for giving people static GUA. > > These are businesses were talking about. They are not going to "give" > anything away. > Interesting? Hurricane Electric is a business. We give away IPv6 /48s to tunnel broker users. In fact, we give away IPv6 transit services and tunnel access. I see lots of businesses giving things away to try and gain market advantage and customer awareness all the time. Why do you think that a business would not do so, given the overwhelming evidence to the contrary? >> >>> Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 >>> made things such as these much nicer in a home and business setting. >>> >> >> No, it really didn't. If IPv4 had contained enough addresses we probably >> wouldn't have always-on dynamic connections in the first place. >> > > Debatable but not worth an argument. Having said that the ability to > 1) not have to renumber internal address space on changing ISPs 2) not > having to give a printer (or other device with no security) a public > IP address or run multiple addressing schemes and the security > implications there of 3) change the internals of my network without > worrying about the world are all important and critical issues for me. > Addressing != security. This issue has definitely been rehashed on here several times and the reality is that you can have just as secure a permit/deny policy with just as much of a default deny with public addresses as you can without them. The difference, of course, is that with public addresses, you have the option of creating permit rules that may not be possible with private addresses depending on your particular implementation (or lack thereof) of address translation. 1. Multihome and get portable GUA, problem solved. If it's actually important to you, this is easy. 2. Since you can give it a public address and still block access between the internet and it if you so choose (I actually find it rather convenient to be able to print at home and the only extra crap that comes out of my printer so far arrives via the telephone line and the G3 protocol, not via IP), public GUA does not change the nature of this issue. 3. I can change the internals of my network without worrying about the world. I'm not sure why you think I can't. Frankly, this claim makes no sense to me whatsoever. > I realize that these arguments are at layers 8 & 9 of the OSI model > (politics and religion) but that does not make them less real nor less > important. They are not the same issues that ISP operators may > normally have to deal with but they are crucial to business operators. > The DSCP/RA arguments are of the same criticality and importance. Agreed. However, misinformation and FUD remains misinformation and FUD regardless of the ISO protocol layer in question. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Tue Aug 2 19:14:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 17:14:26 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <711BA319-B23B-4777-A8AA-E6220A0EC1F7@bogus.com> Message-ID: <5C5CD751-BAF0-4BCB-A3D8-C3F4201323B9@delong.com> On Aug 2, 2011, at 3:37 PM, james machado wrote: > On Tue, Aug 2, 2011 at 3:28 PM, Joel Jaeggli wrote: >> >> On Aug 2, 2011, at 2:42 PM, james machado wrote: >> >>>>> Lets look at some issues here. >>>>> >>>>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>>>> will be able to qualify for their own end user assignment from ARIN. >>>>> >>>> >>>> Interesting... >>>> >>>> I have a "normal household". >>>> I lack 2.5 kids and have no dog or cat. >>>> >>>> I have my own ARIN assignment. >>>> >>>> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >>>> find such a statement in ARIN policy. >>>> >>>> Are you saying that a household that multihomes is abnormal? Perhaps today, >>>> but, not necessarily so in the future. >>>> >>> >>> Yes I am saying a household that mulithomes is abnormal and with >>> today's and contracted monopolies I expect that to continue. You are >>> not a normal household in that 1) you multihome 2) you are willing to >>> pay $1500+ US a year for your own AS, IP assignments >> >> while I don't disagree with the assertion that this is unrealistic the annual fee is $100 per org-id for direct assignments. > > > sorry was unclear - I was guessing $1500+ for ASnumer + IP Assignments > but not counting ISP costs for a year. Looks like ARIN is charging > about $1250 per year for a new IPv6 assignment and the AS yearly cost > is rolled into that. Granted ISP costs will probably be in the > ballpark of $150 per month for 2 consumer grade connections and more > for business or better connections. > > James No, you still have it wrong. There is a one-time charge of $500 for your ASN and $1250 for your /48. After that, it is just $100/year, period. The ISP costs do not have to be significantly more than what you already pay for commodity access. My ISP costs total roughly $140/month, but, for that I am subscribing to 50Mbps down and 7Mbps up and usually get about 70Mbps down and close to 10Mbps up as well as a slower DSL circuit for backup. Yes, it's more than $20/month, but, decent business class service from one provider is going to be around $60/month or more. So, if you double that ($120), you're not far off from what I'm paying and for the small incremental cost, I'm getting quite a bit more. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From sreed at nwwnet.net Tue Aug 2 19:29:10 2011 From: sreed at nwwnet.net (Scott Reed) Date: Tue, 02 Aug 2011 20:29:10 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> Message-ID: <4E389656.9070206@nwwnet.net> Nothing I can disagree with in your statements and I am not trying to argumentative, but I know my customer base and I can assure you there is not one one them that could tell you what ARIN Multi-home BGP OSPF RA or a host of other terms in your response are, let alone what they mean, why they would care, what they would do with it, etc. And you obviously live in a metropolitan area because there isn't DSL in most of my service are, nor is there cable, fiber of any kind and sometimes even satellite doesn't work. Very few of my customers could be dual-homed, let alone mutil-homed, if they wanted to. So, in order to keep the discussion general and to cover all the customer types, skill levels, etc., I really think we need to assume your are not a "normal" household that purchase Internet connectivity to play a game and check Facebook. One other comment. Even those of us the run very small businesses give away things for market share, visibility, etc. On 8/2/2011 8:03 PM, Owen DeLong wrote: > On Aug 2, 2011, at 2:42 PM, james machado wrote: > >>>> Lets look at some issues here. >>>> >>>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>>> will be able to qualify for their own end user assignment from ARIN. >>>> >>> Interesting... >>> >>> I have a "normal household". >>> I lack 2.5 kids and have no dog or cat. >>> >>> I have my own ARIN assignment. >>> >>> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >>> find such a statement in ARIN policy. >>> >>> Are you saying that a household that multihomes is abnormal? Perhaps today, >>> but, not necessarily so in the future. >>> >> Yes I am saying a household that mulithomes is abnormal and with >> today's and contracted monopolies I expect that to continue. You are >> not a normal household in that 1) you multihome 2) you are willing to >> pay $1500+ US a year for your own AS, IP assignments 3) Internet >> service, much like cell phone service is a commodity product and many >> people go for the lowest price. They are not looking for the best >> options. >> > 1) yes. > 2) Uh, no. I pay $100/year to ARIN for all of my IP resources. I really don't > know where this $1,500+/year myth keeps coming from. > I bet most households pay more than $100/year for their internet access. > Heck, if you pay Comcast $5/month for a single static IP, you're paying > more than half of what I pay for 1,208,925,819,614,629,174,706,944 > addresses and an AS Number. If you pay $9/month for 10 static IPs > to Comcast (these are their current rates, btw), you are paying > them MORE than I pay ($108 instead of $100) per year. > 3) I think people do some of both. I think that if people can get static for the > same price, they will choose static over dynamic. I think that some > will even choose to use their dynamic to run tunnels where they > can get static. You can get free static tunnels for IPv6 today. > > So, no, the monopoly problem does not prevent what I am doing from > being done in most households because: > > 1. Most monopolies are actually at least duopolies with at least > one cable and at least one DSL or PON provider. > > 2. Contract monopolies are actually reducing rather than growing. > > >>>> 2) if their router goes down they loose network connectivity on the >>>> same subnet due to loosing their ISP assigned prefix. >>> I keep hearing this myth, and I really do not understand where it comes from. >>> If they get a static prefix from their ISP and configure it into their router and/or >>> other equipment, it does not go away when they loose their router. It simply >>> isn't true. >> If they are using RA's to assign their network and the router goes >> down they can loose the network as well as the router thus going to >> link-local addresses. This has been discusses ad-nauseum on this >> list. As I recall you played a big part of that discussion and it was >> very interesting and informative. >> > 1. Why would you use RAs to assign numbers to things you want to work > when the router goes down. > > 2. This presumes they have only one router. There is no reason, given > static addressing, that they cannot have a High and a Medium priority > router. The High priority router provides connectivity to the ISP and the > medium priority router is essentially /dev/null, but, keeps the addresses > active. > > Yes, it has been discussed before, but, it continues to be made clear that > people are still applying a mixture of misinformation and IPv4-think to > the IPv6 situation, so, I continue to work towards better education. > >>>> 3) If they are getting dynamic IP's from their ISP and it changes they >>>> may or may not be able to print, connect to a share, things like that. >>>> >>> Perhaps, but, this is another reason that I think sane customers will start demanding >>> static IPv6 from their providers in relatively short order. >>> >> I hope this happens but I'm guessing that with marketing and sales in >> the mix it will be another up charge to get this "service" and enough >> people won't pay it that we will be fighting these problems for a long >> time. Some businesses will pay it and some won't but the home user >> will probably not. >> > Amusingly, I have, so far, refused to pay it to Comcast on my business > class service. Every once in a while, they renumber my address and I have > to reconfigure my tunnel. (I'm using commodity internet access for layer > 2 transport into my home. The BGP is done between my home router and > routers in colo facilities via GRE). > >>>> these 3 items make a case for everybody having a ULA. however while >>>> many of the technical bent will be able to manage multiple addresses I >>>> know how much tech support I'll be providing my parents with either an >>>> IP address that goes away/changes or multiple IP addresses. I'll set >>>> them up on a ULA so there is consistency. >>>> >>> No, they don't. They make a great case for giving people static GUA. >> These are businesses were talking about. They are not going to "give" >> anything away. >> > Interesting? Hurricane Electric is a business. We give away IPv6 /48s to > tunnel broker users. In fact, we give away IPv6 transit services and tunnel > access. I see lots of businesses giving things away to try and gain market > advantage and customer awareness all the time. Why do you think that > a business would not do so, given the overwhelming evidence to the > contrary? > >>>> Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 >>>> made things such as these much nicer in a home and business setting. >>>> >>> No, it really didn't. If IPv4 had contained enough addresses we probably >>> wouldn't have always-on dynamic connections in the first place. >>> >> Debatable but not worth an argument. Having said that the ability to >> 1) not have to renumber internal address space on changing ISPs 2) not >> having to give a printer (or other device with no security) a public >> IP address or run multiple addressing schemes and the security >> implications there of 3) change the internals of my network without >> worrying about the world are all important and critical issues for me. >> > Addressing != security. This issue has definitely been rehashed on > here several times and the reality is that you can have just as secure > a permit/deny policy with just as much of a default deny with public > addresses as you can without them. The difference, of course, is that > with public addresses, you have the option of creating permit rules > that may not be possible with private addresses depending on your > particular implementation (or lack thereof) of address translation. > > 1. Multihome and get portable GUA, problem solved. If it's actually > important to you, this is easy. > > 2. Since you can give it a public address and still block access > between the internet and it if you so choose (I actually find > it rather convenient to be able to print at home and the only > extra crap that comes out of my printer so far arrives via the > telephone line and the G3 protocol, not via IP), public GUA > does not change the nature of this issue. > > 3. I can change the internals of my network without worrying > about the world. I'm not sure why you think I can't. Frankly, > this claim makes no sense to me whatsoever. > >> I realize that these arguments are at layers 8& 9 of the OSI model >> (politics and religion) but that does not make them less real nor less >> important. They are not the same issues that ISP operators may >> normally have to deal with but they are crucial to business operators. >> The DSCP/RA arguments are of the same criticality and importance. > Agreed. However, misinformation and FUD remains misinformation > and FUD regardless of the ISO protocol layer in question. > > Owen > -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060 (765) 439-4253 (855) 231-6239 From owen at delong.com Tue Aug 2 19:39:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 17:39:26 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E389656.9070206@nwwnet.net> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <4E389656.9070206@nwwnet.net> Message-ID: <6A301A00-8E48-4D92-8C5A-5DF091F0F90F@delong.com> From your description below, I am pretty sure that one of the following is true: 1. Your service area covers ?1% of the population of whatever state or province you are in. or 2. Your state or province has a population ?1% of the US national population. I would argue that I am not an "abnormal" household by any definition other than my internet access and that even by that definition, I am not particularly abnormal where I live. There are many people I know of with much more expensive and elaborate internet connectivity to their houses than what I have within 30 miles of me. While I don't think I represent the typical residential ISP customer, I do think that the typical customer will eventually learn what static addressing is and will want it for a variety of reasons. Owen On Aug 2, 2011, at 5:29 PM, Scott Reed wrote: > Nothing I can disagree with in your statements and I am not trying to argumentative, but I know my customer base and I can assure you there is not one one them that could tell you what > ARIN > Multi-home > BGP > OSPF > RA > or a host of other terms in your response are, let alone what they mean, why they would care, what they would do with it, etc. > And you obviously live in a metropolitan area because there isn't DSL in most of my service are, nor is there cable, fiber of any kind and sometimes even satellite doesn't work. Very few of my customers could be dual-homed, let alone mutil-homed, if they wanted to. > So, in order to keep the discussion general and to cover all the customer types, skill levels, etc., I really think we need to assume your are not a "normal" household that purchase Internet connectivity to play a game and check Facebook. > > One other comment. > Even those of us the run very small businesses give away things for market share, visibility, etc. > > On 8/2/2011 8:03 PM, Owen DeLong wrote: >> On Aug 2, 2011, at 2:42 PM, james machado wrote: >> >>>>> Lets look at some issues here. >>>>> >>>>> 1) it's unlikely that a "normal" household with 2.5 kids and a dog/cat >>>>> will be able to qualify for their own end user assignment from ARIN. >>>>> >>>> Interesting... >>>> >>>> I have a "normal household". >>>> I lack 2.5 kids and have no dog or cat. >>>> >>>> I have my own ARIN assignment. >>>> >>>> Are you saying that the 2.5 kids and the dog/cat would disqualify them? I can't >>>> find such a statement in ARIN policy. >>>> >>>> Are you saying that a household that multihomes is abnormal? Perhaps today, >>>> but, not necessarily so in the future. >>>> >>> Yes I am saying a household that mulithomes is abnormal and with >>> today's and contracted monopolies I expect that to continue. You are >>> not a normal household in that 1) you multihome 2) you are willing to >>> pay $1500+ US a year for your own AS, IP assignments 3) Internet >>> service, much like cell phone service is a commodity product and many >>> people go for the lowest price. They are not looking for the best >>> options. >>> >> 1) yes. >> 2) Uh, no. I pay $100/year to ARIN for all of my IP resources. I really don't >> know where this $1,500+/year myth keeps coming from. >> I bet most households pay more than $100/year for their internet access. >> Heck, if you pay Comcast $5/month for a single static IP, you're paying >> more than half of what I pay for 1,208,925,819,614,629,174,706,944 >> addresses and an AS Number. If you pay $9/month for 10 static IPs >> to Comcast (these are their current rates, btw), you are paying >> them MORE than I pay ($108 instead of $100) per year. >> 3) I think people do some of both. I think that if people can get static for the >> same price, they will choose static over dynamic. I think that some >> will even choose to use their dynamic to run tunnels where they >> can get static. You can get free static tunnels for IPv6 today. >> >> So, no, the monopoly problem does not prevent what I am doing from >> being done in most households because: >> >> 1. Most monopolies are actually at least duopolies with at least >> one cable and at least one DSL or PON provider. >> >> 2. Contract monopolies are actually reducing rather than growing. >> >> >>>>> 2) if their router goes down they loose network connectivity on the >>>>> same subnet due to loosing their ISP assigned prefix. >>>> I keep hearing this myth, and I really do not understand where it comes from. >>>> If they get a static prefix from their ISP and configure it into their router and/or >>>> other equipment, it does not go away when they loose their router. It simply >>>> isn't true. >>> If they are using RA's to assign their network and the router goes >>> down they can loose the network as well as the router thus going to >>> link-local addresses. This has been discusses ad-nauseum on this >>> list. As I recall you played a big part of that discussion and it was >>> very interesting and informative. >>> >> 1. Why would you use RAs to assign numbers to things you want to work >> when the router goes down. >> >> 2. This presumes they have only one router. There is no reason, given >> static addressing, that they cannot have a High and a Medium priority >> router. The High priority router provides connectivity to the ISP and the >> medium priority router is essentially /dev/null, but, keeps the addresses >> active. >> >> Yes, it has been discussed before, but, it continues to be made clear that >> people are still applying a mixture of misinformation and IPv4-think to >> the IPv6 situation, so, I continue to work towards better education. >> >>>>> 3) If they are getting dynamic IP's from their ISP and it changes they >>>>> may or may not be able to print, connect to a share, things like that. >>>>> >>>> Perhaps, but, this is another reason that I think sane customers will start demanding >>>> static IPv6 from their providers in relatively short order. >>>> >>> I hope this happens but I'm guessing that with marketing and sales in >>> the mix it will be another up charge to get this "service" and enough >>> people won't pay it that we will be fighting these problems for a long >>> time. Some businesses will pay it and some won't but the home user >>> will probably not. >>> >> Amusingly, I have, so far, refused to pay it to Comcast on my business >> class service. Every once in a while, they renumber my address and I have >> to reconfigure my tunnel. (I'm using commodity internet access for layer >> 2 transport into my home. The BGP is done between my home router and >> routers in colo facilities via GRE). >> >>>>> these 3 items make a case for everybody having a ULA. however while >>>>> many of the technical bent will be able to manage multiple addresses I >>>>> know how much tech support I'll be providing my parents with either an >>>>> IP address that goes away/changes or multiple IP addresses. I'll set >>>>> them up on a ULA so there is consistency. >>>>> >>>> No, they don't. They make a great case for giving people static GUA. >>> These are businesses were talking about. They are not going to "give" >>> anything away. >>> >> Interesting? Hurricane Electric is a business. We give away IPv6 /48s to >> tunnel broker users. In fact, we give away IPv6 transit services and tunnel >> access. I see lots of businesses giving things away to try and gain market >> advantage and customer awareness all the time. Why do you think that >> a business would not do so, given the overwhelming evidence to the >> contrary? >> >>>>> Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 >>>>> made things such as these much nicer in a home and business setting. >>>>> >>>> No, it really didn't. If IPv4 had contained enough addresses we probably >>>> wouldn't have always-on dynamic connections in the first place. >>>> >>> Debatable but not worth an argument. Having said that the ability to >>> 1) not have to renumber internal address space on changing ISPs 2) not >>> having to give a printer (or other device with no security) a public >>> IP address or run multiple addressing schemes and the security >>> implications there of 3) change the internals of my network without >>> worrying about the world are all important and critical issues for me. >>> >> Addressing != security. This issue has definitely been rehashed on >> here several times and the reality is that you can have just as secure >> a permit/deny policy with just as much of a default deny with public >> addresses as you can without them. The difference, of course, is that >> with public addresses, you have the option of creating permit rules >> that may not be possible with private addresses depending on your >> particular implementation (or lack thereof) of address translation. >> >> 1. Multihome and get portable GUA, problem solved. If it's actually >> important to you, this is easy. >> >> 2. Since you can give it a public address and still block access >> between the internet and it if you so choose (I actually find >> it rather convenient to be able to print at home and the only >> extra crap that comes out of my printer so far arrives via the >> telephone line and the G3 protocol, not via IP), public GUA >> does not change the nature of this issue. >> >> 3. I can change the internals of my network without worrying >> about the world. I'm not sure why you think I can't. Frankly, >> this claim makes no sense to me whatsoever. >> >>> I realize that these arguments are at layers 8& 9 of the OSI model >>> (politics and religion) but that does not make them less real nor less >>> important. They are not the same issues that ISP operators may >>> normally have to deal with but they are crucial to business operators. >>> The DSCP/RA arguments are of the same criticality and importance. >> Agreed. However, misinformation and FUD remains misinformation >> and FUD regardless of the ISO protocol layer in question. >> >> Owen >> > > -- > Scott Reed > Owner > NewWays Networking, LLC > Wireless Networking > Network Design, Installation and Administration > > > > Mikrotik Advanced Certified > > www.nwwnet.net > (765) 855-1060 > (765) 439-4253 > (855) 231-6239 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From hvgeekwtrvl at gmail.com Tue Aug 2 20:18:44 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 2 Aug 2011 18:18:44 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <6A301A00-8E48-4D92-8C5A-5DF091F0F90F@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <4E389656.9070206@nwwnet.net> <6A301A00-8E48-4D92-8C5A-5DF091F0F90F@delong.com> Message-ID: > I would argue that I am not an "abnormal" household by any definition other than > my internet access and that even by that definition, I am not particularly abnormal > where I live. > your based out of san jose, there might not be any other area like that in the U.S. as far as connectivity and concentration of i.t. savy. there might be 10 cities in the U.S. with the same infrastructure and availability as you have accessible. there are not 50. while not abnormal where you live, it is abnormal to the rest of the country. > There are many people I know of with much more expensive and elaborate > internet connectivity to their houses than what I have within 30 miles of me. > > While I don't think I represent the typical residential ISP customer, I do think that > the typical customer will eventually learn what static addressing is and will want > it for a variety of reasons. > > Owen scott's user base is more typical than what you can find in your neighborhood. i am sure some of the same users live within 30 miles of you too but you,i, scott, or anybody else on this list can not be considered normal in this respect. james From owen at delong.com Tue Aug 2 21:11:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 19:11:39 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <9C92E215-9B2E-4D1E-B4ED-B93019C4FFAD@delong.com> <4E389656.9070206@nwwnet.net> <6A301A00-8E48-4D92-8C5A-5DF091F0F90F@delong.com> Message-ID: On Aug 2, 2011, at 6:18 PM, james machado wrote: >> I would argue that I am not an "abnormal" household by any definition other than >> my internet access and that even by that definition, I am not particularly abnormal >> where I live. >> > > your based out of san jose, there might not be any other area like > that in the U.S. as far as connectivity and concentration of i.t. > savy. there might be 10 cities in the U.S. with the same > infrastructure and availability as you have accessible. there are not > 50. while not abnormal where you live, it is abnormal to the rest of > the country. > Sir, if that is true, then it is a truly sad state of affairs in the U.S. For the connectivity situation in San Jose for residential is rather poor in most areas with the only options being relatively low bandwidth DSL and CMTS. The CMTS is now halfway decent (less than 2 years ago, it was largely poor as well). There is not a PON system to be had in most of San Jose and the WISP situation is similarly dismal. In my neighborhood, I have about the best connectivity that money can buy short of installing a fiber node and paying for a DS-3 or better at business rates on a monthly basis and waiting for a rather extensive build-out that may involve a multi-million dollar installation charge. That's 50mbps/7mbps on the CMTS (I asked, the higher tier products are not to be had where I live), and the 1.5mbps/384kbps DSL. > >> There are many people I know of with much more expensive and elaborate >> internet connectivity to their houses than what I have within 30 miles of me. >> >> While I don't think I represent the typical residential ISP customer, I do think that >> the typical customer will eventually learn what static addressing is and will want >> it for a variety of reasons. >> >> Owen > > scott's user base is more typical than what you can find in your > neighborhood. i am sure some of the same users live within 30 miles > of you too but you,i, scott, or anybody else on this list can not be > considered normal in this respect. > The majority of the US population has access to at least cable (CMTS) and DSL. Claiming otherwise is, well, specious. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From nanog at jima.tk Tue Aug 2 22:50:53 2011 From: nanog at jima.tk (Jima) Date: Tue, 02 Aug 2011 21:50:53 -0600 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> Message-ID: <4E38C59D.8000201@jima.tk> On 2011-08-02 11:17, Owen DeLong wrote: >> >> en1: flags=8863 mtu 1500 >> ether 60:33:4b:01:75:85 >> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 >> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 >> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf >> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf >> media: autoselect >> status: active >> >> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. >> If you want to give your printers, etc. stable IPv6 addesses use ULAs. >> > > Icky. > > > Better yet, just subscribe to an ISP that will give you a static prefix. Well, judging by his prefixes, he does. Also: > Are you saying that a household that multihomes is abnormal? Perhaps > today, but, not necessarily so in the future. I technically multi-homed back in 2001-2004. I didn't have BGP or anything; my DSL provider offered it to me half-jokingly once, but since the other side (Time Warner Cable) wouldn't to it, I didn't take them up on it. Alas, I will maintain that any household that multi-homes at this stage is, indeed, abnormal. Jima From ikiris at gmail.com Tue Aug 2 23:33:00 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 2 Aug 2011 23:33:00 -0500 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E38C59D.8000201@jima.tk> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> Message-ID: Or, alternately, don't care what your printer's ridiculously long IPv6 IP is at this moment, (ULA/GUA/assigned: it really doesn't matter) and use mdns like normal people. Otherwise we're ignoring the forest for the trees, I don't expect to try to explain to my grandma how to type in 2001:45ea:344b:dead:beef::27 and/or remember it, when "printer1" will do. This just makes me think of this: http://bash.org/?14258 If we need a way to mdns to work across subnet boundries in a single administrative domain, so be it. If we need a better mdns, lets make that too, but we *really* need to get away from direct IPs in general. -Blake From marka at isc.org Tue Aug 2 23:43:51 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Aug 2011 14:43:51 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 02 Aug 2011 21:50:53 CST." <4E38C59D.8000201@jima.tk> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> Message-ID: <20110803044351.19C9112673D4@drugs.dv.isc.org> In message <4E38C59D.8000201 at jima.tk>, Jima writes: > On 2011-08-02 11:17, Owen DeLong wrote: > >> > >> en1: flags=8863 mtu 1500 > >> ether 60:33:4b:01:75:85 > >> inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 > >> inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255 > >> inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf > >> inet6 2001:470:1f00:820:6233:4bff:fe01:7585 prefixlen 64 autoconf > >> media: autoselect > >> status: active > >> > >> Note the multiple prefixes. IPv6 is not just IPv4 with bigger addresses. > >> If you want to give your printers, etc. stable IPv6 addesses use ULAs. > >> > > > > Icky. > > > > > > Better yet, just subscribe to an ISP that will give you a static prefix. > > Well, judging by his prefixes, he does. Indeed it is static but that doesn't change the argument that having a ULA works. The address selection algorithms choose the right source address for the correct destination address. The RA's for 2001:470:1f00:820::/64 could be withdrawn and the network would continue to work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Aug 2 23:42:38 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Aug 2011 21:42:38 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> Message-ID: <83EF2A9B-DBFD-408B-8EC0-CF36F2CF2895@delong.com> On Aug 2, 2011, at 9:33 PM, Blake Dunlap wrote: > Or, alternately, don't care what your printer's ridiculously long IPv6 IP is > at this moment, (ULA/GUA/assigned: it really doesn't matter) and use mdns > like normal people. Otherwise we're ignoring the forest for the trees, I > don't expect to try to explain to my grandma how to type in > 2001:45ea:344b:dead:beef::27 and/or remember it, when "printer1" will do. > > This just makes me think of this: http://bash.org/?14258 > > > If we need a way to mdns to work across subnet boundries in a single > administrative domain, so be it. If we need a better mdns, lets make that > too, but we *really* need to get away from direct IPs in general. > > -Blake In IPv6, that should be a relatively simple matter of changing the MDNS address from starting with ff01 to ff02 or ff04. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From marka at isc.org Tue Aug 2 23:52:32 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Aug 2011 14:52:32 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 02 Aug 2011 23:33:00 EST." References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> Message-ID: <20110803045232.AB802126752E@drugs.dv.isc.org> In message , Blake Dunlap writes: > Or, alternately, don't care what your printer's ridiculously long IPv6 IP is > at this moment, (ULA/GUA/assigned: it really doesn't matter) and use mdns > like normal people. Otherwise we're ignoring the forest for the trees, I > don't expect to try to explain to my grandma how to type in > 2001:45ea:344b:dead:beef::27 and/or remember it, when "printer1" will do. > > This just makes me think of this: http://bash.org/?14258 > > If we need a way to mdns to work across subnet boundries in a single > administrative domain, so be it. If we need a better mdns, lets make that > too, but we *really* need to get away from direct IPs in general. You are totally missing the point which is that the printer has a *routable* address when the home, with possibly multiple subnets, is disconnected or has never connected to the global network. link-locals are insufficient for a routed home. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From newton at internode.com.au Tue Aug 2 23:56:41 2011 From: newton at internode.com.au (Mark Newton) Date: Wed, 3 Aug 2011 04:56:41 +0000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E38C59D.8000201@jima.tk> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> Message-ID: <0A9ED519-D8CB-4AD2-8B6B-42D4AEEFA15D@internode.com.au> On 03/08/2011, at 1:20 PM, Jima wrote: > Alas, I will maintain that any household that multi-homes at this stage is, indeed, abnormal. I'll go out on a limb and suggest that most people loathe their telcos with an undying venomous passion, and can think of nothing worse than dealing with any more of them than they do now. Widespread multihoming might be technically pure, but I reckon most customers would rather eat their firstborns than take up the option. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From joelja at bogus.com Wed Aug 3 00:37:55 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 2 Aug 2011 22:37:55 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <0A9ED519-D8CB-4AD2-8B6B-42D4AEEFA15D@internode.com.au> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> <0A9ED519-D8CB-4AD2-8B6B-42D4AEEFA15D@internode.com.au> Message-ID: <6BE2E719-710A-4A8C-9B58-BC2924088107@bogus.com> On Aug 2, 2011, at 9:56 PM, Mark Newton wrote: > > On 03/08/2011, at 1:20 PM, Jima wrote: > >> Alas, I will maintain that any household that multi-homes at this stage is, indeed, abnormal. > > > I'll go out on a limb and suggest that most people loathe their telcos with > an undying venomous passion, and can think of nothing worse than dealing with > any more of them than they do now. > > Widespread multihoming might be technically pure, but I reckon most customers > would rather eat their firstborns than take up the option. There are likely a few orders of magnitude more people who have more than one internet service available at the same time at home then there are people with two bgp speaking peers. there are 38453 ASes that appear in the DFZ this week and I don't see that number growing to 1 billion anytime soon. > - mark > > -- > Mark Newton Email: newton at internode.com.au (W) > Network Engineer Email: newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > > > From sthaug at nethelp.no Wed Aug 3 02:14:21 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 03 Aug 2011 09:14:21 +0200 (CEST) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: Message-ID: <20110803.091421.74749615.sthaug@nethelp.no> > 3) I think people do some of both. I think that if people can get static for the > same price, they will choose static over dynamic. I think that some > will even choose to use their dynamic to run tunnels where they > can get static. You can get free static tunnels for IPv6 today. Experience from IPv4 suggests otherwise. We (as an ISP) normally hand out dynamic IPv4 addresses to residential customers, and static IPv4 addresses to business customers. - We have plenty of business customers who *want* dynamic addresses, even if static is available as a standard part of their product. - There are quite a few ISPs here that offer static IPv4 addresses to residential customers. Those ISPs haven't captured the whole market, strangely enough. So I completely disagree with the claim that (all) people will choose static over dynamic if it is available at the same price. From my POV the market here clearly wants both options - and both are available. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From owen at delong.com Wed Aug 3 02:14:38 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Aug 2011 00:14:38 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110803045232.AB802126752E@drugs.dv.isc.org> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> <20110803045232.AB802126752E@drugs.dv.isc.org> Message-ID: On Aug 2, 2011, at 9:52 PM, Mark Andrews wrote: > > In message > , Blake Dunlap writes: >> Or, alternately, don't care what your printer's ridiculously long IPv6 IP is >> at this moment, (ULA/GUA/assigned: it really doesn't matter) and use mdns >> like normal people. Otherwise we're ignoring the forest for the trees, I >> don't expect to try to explain to my grandma how to type in >> 2001:45ea:344b:dead:beef::27 and/or remember it, when "printer1" will do. >> >> This just makes me think of this: http://bash.org/?14258 >> >> If we need a way to mdns to work across subnet boundries in a single >> administrative domain, so be it. If we need a better mdns, lets make that >> too, but we *really* need to get away from direct IPs in general. > > You are totally missing the point which is that the printer has a > *routable* address when the home, with possibly multiple subnets, > is disconnected or has never connected to the global network. > > link-locals are insufficient for a routed home. > I get that and I have that with GUA without resorting to ULA. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Wed Aug 3 02:42:39 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Aug 2011 00:42:39 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110803.091421.74749615.sthaug@nethelp.no> References: <20110803.091421.74749615.sthaug@nethelp.no> Message-ID: <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> On Aug 3, 2011, at 12:14 AM, sthaug at nethelp.no wrote: >> 3) I think people do some of both. I think that if people can get static for the >> same price, they will choose static over dynamic. I think that some >> will even choose to use their dynamic to run tunnels where they >> can get static. You can get free static tunnels for IPv6 today. > > Experience from IPv4 suggests otherwise. We (as an ISP) normally hand > out dynamic IPv4 addresses to residential customers, and static IPv4 > addresses to business customers. > > - We have plenty of business customers who *want* dynamic addresses, > even if static is available as a standard part of their product. > > - There are quite a few ISPs here that offer static IPv4 addresses to > residential customers. Those ISPs haven't captured the whole market, > strangely enough. > > So I completely disagree with the claim that (all) people will choose > static over dynamic if it is available at the same price. From my POV > the market here clearly wants both options - and both are available. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Europe is a little odd in that way, especially DE and NO in that there seems to be this weird FUD running around claiming that static addresses are in some way more antithetical to privacy. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From sthaug at nethelp.no Wed Aug 3 03:04:39 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 03 Aug 2011 10:04:39 +0200 (CEST) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> Message-ID: <20110803.100439.74745741.sthaug@nethelp.no> > > Experience from IPv4 suggests otherwise. We (as an ISP) normally hand > > out dynamic IPv4 addresses to residential customers, and static IPv4 > > addresses to business customers. > > > > - We have plenty of business customers who *want* dynamic addresses, > > even if static is available as a standard part of their product. > > > > - There are quite a few ISPs here that offer static IPv4 addresses to > > residential customers. Those ISPs haven't captured the whole market, > > strangely enough. > > > > So I completely disagree with the claim that (all) people will choose > > static over dynamic if it is available at the same price. From my POV > > the market here clearly wants both options - and both are available. > > Europe is a little odd in that way, especially DE and NO in that there seems > to be this weird FUD running around claiming that static addresses are > in some way more antithetical to privacy. I haven't noticed FUD like that here in Norway. From my POV the reason quite a few customers *want* dynamic has much more to do with ease of use: - Dynamic address: Customer connects PC (defaults to DHCP) or router/ firewall with DHCP for the WAN interface plus NAT for the LAN side. Necessary configuration: Small to none. - Static address: Customer needs to configure PC or router/firewall with static address(es). This is no longer a "small touch/zero touch" configuration. For a customer who doesn't know a lot about computers and networking the difference between these two alternatives can be dramatic... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From owen at delong.com Wed Aug 3 03:13:30 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Aug 2011 01:13:30 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110803.100439.74745741.sthaug@nethelp.no> References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> Message-ID: On Aug 3, 2011, at 1:04 AM, sthaug at nethelp.no wrote: >>> Experience from IPv4 suggests otherwise. We (as an ISP) normally hand >>> out dynamic IPv4 addresses to residential customers, and static IPv4 >>> addresses to business customers. >>> >>> - We have plenty of business customers who *want* dynamic addresses, >>> even if static is available as a standard part of their product. >>> >>> - There are quite a few ISPs here that offer static IPv4 addresses to >>> residential customers. Those ISPs haven't captured the whole market, >>> strangely enough. >>> >>> So I completely disagree with the claim that (all) people will choose >>> static over dynamic if it is available at the same price. From my POV >>> the market here clearly wants both options - and both are available. >> >> Europe is a little odd in that way, especially DE and NO in that there seems >> to be this weird FUD running around claiming that static addresses are >> in some way more antithetical to privacy. > > I haven't noticed FUD like that here in Norway. From my POV the reason > quite a few customers *want* dynamic has much more to do with ease of > use: > > - Dynamic address: Customer connects PC (defaults to DHCP) or router/ > firewall with DHCP for the WAN interface plus NAT for the LAN side. > Necessary configuration: Small to none. > > - Static address: Customer needs to configure PC or router/firewall > with static address(es). This is no longer a "small touch/zero touch" > configuration. > That's only true if you don't make static DHCP lease available to customers that want static addresses. You are confusing auto configured addresses with dynamic addresses. They are not the same thing. > For a customer who doesn't know a lot about computers and networking > the difference between these two alternatives can be dramatic? > I agree that autoconf is desirable. Now, please explain to me why it is desirable for the address to change at random intervals from the customer perspective? (i.e. why would one want dynamic rather than static auto configuration?) Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From swmike at swm.pp.se Wed Aug 3 03:28:32 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 3 Aug 2011 10:28:32 +0200 (CEST) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> Message-ID: On Wed, 3 Aug 2011, Owen DeLong wrote: > Europe is a little odd in that way, especially DE and NO in that there > seems to be this weird FUD running around claiming that static addresses > are in some way more antithetical to privacy. Yes, I agree. I know people who choose provider based on the availability of static addresses, I know very few who avoid static address ISPs because of this fact. FUD indeed. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Wed Aug 3 03:30:04 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 3 Aug 2011 10:30:04 +0200 (CEST) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <20110803.100439.74745741.sthaug@nethelp.no> References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> Message-ID: On Wed, 3 Aug 2011, sthaug at nethelp.no wrote: > - Dynamic address: Customer connects PC (defaults to DHCP) or router/ > firewall with DHCP for the WAN interface plus NAT for the LAN side. > Necessary configuration: Small to none. DHCP doesn't imply dynamic address. It implies customer doesn't have to configure an address him/herself. DHCP can very well always hand out the same address every time. -- Mikael Abrahamsson email: swmike at swm.pp.se From sthaug at nethelp.no Wed Aug 3 04:03:28 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 03 Aug 2011 11:03:28 +0200 (CEST) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> Message-ID: <20110803.110328.41636477.sthaug@nethelp.no> > > - Dynamic address: Customer connects PC (defaults to DHCP) or router/ > > firewall with DHCP for the WAN interface plus NAT for the LAN side. > > Necessary configuration: Small to none. > > DHCP doesn't imply dynamic address. It implies customer doesn't have to > configure an address him/herself. DHCP can very well always hand out the > same address every time. Absolutely, and in our network it does - in most cases. However, ensuring that DHCP hands out a *real* static address every time, in the face of non SP controlled CPEs, changing MAC addresses etc is non-trivial. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jra at baylink.com Wed Aug 3 08:55:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Aug 2011 09:55:51 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Message-ID: <17340112.373.1312379751660.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > On Wed, 3 Aug 2011, Owen DeLong wrote: > > > Europe is a little odd in that way, especially DE and NO in that there > > seems to be this weird FUD running around claiming that static addresses > > are in some way more antithetical to privacy. > > Yes, I agree. I know people who choose provider based on the availability > of static addresses, I know very few who avoid static address ISPs because > of this fact. > > FUD indeed. You guys aren't *near* paranoid enough. :-) If the ISP a) Assigns dynamic addresses to customers, and b) changes those IPs on a relatively short scale (days) then c) outside parties *who are not the ISP or an LEO* will have a relatively harder time tying together two visits solely by the IP address. While this isn't "privacy", per se, that "making harder" is at least somewhat useful to a client in reducing the odds that such non-ISP/LEO parties will be unable to tie their visits, assuming they've controlled the items they *can* control (cookies, flash cookies, etc). Imperfect security != no security, *as long as you know where the holes are*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From william.allen.simpson at gmail.com Wed Aug 3 11:54:45 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 03 Aug 2011 12:54:45 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> Message-ID: <4E397D55.1000203@gmail.com> On 8/3/11 4:13 AM, Owen DeLong wrote: > I agree that autoconf is desirable. Now, please explain to me why it is > desirable for the address to change at random intervals from the customer > perspective? (i.e. why would one want dynamic rather than static auto > configuration?) > Because IPv6 was originally designed with the goal of completely transparent renumbering. Indeed, after many WG meetings over many years debating renumbering and all the problems that entailed for IPv4, some of my drafts proposed that IANA would renumber IPv6 for every ISP and IX at regular intervals! Thus, enforcing that all the dynamic configuration protocols actually work. :-) And nobody starts issuing licenses based on IP addresses anymore. :-( From woody at pch.net Wed Aug 3 12:00:37 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 Aug 2011 10:00:37 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <4E397D55.1000203@gmail.com> References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> <4E397D55.1000203@gmail.com> Message-ID: Also good for customer privacy. LE can still subpoena ISP logs, but e-commerce sites can't track users quite as easily. -Bill On Aug 3, 2011, at 9:55, "William Allen Simpson" wrote: > On 8/3/11 4:13 AM, Owen DeLong wrote: >> I agree that autoconf is desirable. Now, please explain to me why it is >> desirable for the address to change at random intervals from the customer >> perspective? (i.e. why would one want dynamic rather than static auto >> configuration?) >> > Because IPv6 was originally designed with the goal of completely > transparent renumbering. Indeed, after many WG meetings over many > years debating renumbering and all the problems that entailed for > IPv4, some of my drafts proposed that IANA would renumber IPv6 for > every ISP and IX at regular intervals! > > Thus, enforcing that all the dynamic configuration protocols > actually work. :-) And nobody starts issuing licenses based on IP > addresses anymore. :-( > From brunner at nic-naa.net Wed Aug 3 10:14:54 2011 From: brunner at nic-naa.net (brunner at nic-naa.net) Date: Wed, 03 Aug 2011 11:14:54 -0400 Subject: assume v6 available, average cost to implement Message-ID: <201108031514.p73FEsq1050688@nic-naa.net> Folks, In the never ending game of policy whack-a-mole, we are offered the claim that that the cost to a small to medium business to make its operational purpose v6 address enabled is in the mid-five figures. For those of you who do smb consults, some numbers to make a hypothetical shop consisting of a quarter rack of gear running nothing more goofy than a couple of applications on a couple of ports, basicially, a dbms plus a bit of gorp, say in central Kansas, to which some provider, say Kansas Telekenesis and Telefriend has just made v6 happy. Having renumbered hq.af.mil some time ago, I'm expecting the 50k bogie to add colons to some retail insurance office or mortuary in central Kansas to be on the exceedingly good dope high side. Thanks in advance for real numbers, which I'll sanitize before using to attmept to keep one policy playpen slightly less crazy than normal. Eric From owen at delong.com Wed Aug 3 12:38:21 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Aug 2011 10:38:21 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <17340112.373.1312379751660.JavaMail.root@benjamin.baylink.com> References: <17340112.373.1312379751660.JavaMail.root@benjamin.baylink.com> Message-ID: On Aug 3, 2011, at 6:55 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Mikael Abrahamsson" > >> On Wed, 3 Aug 2011, Owen DeLong wrote: >> >>> Europe is a little odd in that way, especially DE and NO in that there >>> seems to be this weird FUD running around claiming that static addresses >>> are in some way more antithetical to privacy. >> >> Yes, I agree. I know people who choose provider based on the availability >> of static addresses, I know very few who avoid static address ISPs because >> of this fact. >> >> FUD indeed. > > You guys aren't *near* paranoid enough. :-) > > If the ISP > > a) Assigns dynamic addresses to customers, and > b) changes those IPs on a relatively short scale (days) > > then > > c) outside parties *who are not the ISP or an LEO* will have a > relatively harder time tying together two visits solely by the IP > address. > ROFL... Yeah, right... Because the MAC suffix won't do anything. > While this isn't "privacy", per se, that "making harder" is at least > somewhat useful to a client in reducing the odds that such non-ISP/LEO > parties will be unable to tie their visits, assuming they've controlled > the items they *can* control (cookies, flash cookies, etc). > Which is something, what, 1% of people probably even know how to do, let alone practice on a regular basis. > Imperfect security != no security, *as long as you know where the holes are*. > If people want this, they can use RFC-4193 to just about the same effect. The ISP modifying the prefix regularly simply doesn't do much. Owen From kemp at network-services.uoregon.edu Wed Aug 3 13:36:12 2011 From: kemp at network-services.uoregon.edu (John Kemp) Date: Wed, 03 Aug 2011 11:36:12 -0700 Subject: bgplay.routeviews.org online again (finally) Message-ID: <4E39951C.2060107@network-services.uoregon.edu> See: http://bgplay.routeviews.org/ It's up again, and actively updating. We ran into a space crunch on the previous machine. We now have the DB living on one of our stable RAID6 arrays. Currently the data is from January 26, 2011 to present. (it's finishing the data for 08/03/2011 right now...) The data source is the route-views2 collector. Data downloads of routing updates happen at :10 after each hour. --- John Kemp (kemp at routeviews.org) RouteViews Engineer NOC: help at routeviews.org http://www.routeviews.org From jra at baylink.com Wed Aug 3 12:53:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Aug 2011 13:53:11 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Message-ID: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Aug 3, 2011, at 6:55 AM, Jay Ashworth wrote: > > You guys aren't *near* paranoid enough. :-) > > > > If the ISP > > > > a) Assigns dynamic addresses to customers, and > > b) changes those IPs on a relatively short scale (days) > > > > then > > > > c) outside parties *who are not the ISP or an LEO* will have a > > relatively harder time tying together two visits solely by the IP > > address. > > ROFL... Yeah, right... Because the MAC suffix won't do anything. Did I mention I haven't implemented v6 yet? :-) *Really*? It bakes the endpoint MAC into the IP? Well, that's miserably poor architecture design. > > While this isn't "privacy", per se, that "making harder" is at least > > somewhat useful to a client in reducing the odds that such > > non-ISP/LEO > > parties will be unable to tie their visits, assuming they've > > controlled > > the items they *can* control (cookies, flash cookies, etc). > > Which is something, what, 1% of people probably even know how to do, > let alone practice on a regular basis. Yup; let's go out of our way to penalize the smart people; that's a *great* plan; I so enjoy it when people do it -- and they do it *far* too often for my tastes. > > Imperfect security != no security, *as long as you know where the > > holes are*. > > If people want this, they can use RFC-4193 to just about the same > effect. The ISP modifying the prefix regularly simply doesn't do much. I'll make a note of it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From up at 3.am Wed Aug 3 14:27:27 2011 From: up at 3.am (James Smallacombe) Date: Wed, 3 Aug 2011 15:27:27 -0400 (EDT) Subject: Verizon Issues? East Coast US In-Reply-To: <4D6C62E4.8010102@sentex.net> References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> Message-ID: I'm having issues through Verizon too...I have a server colocated in Vancouver...could it be a Canadian thing with Verizon? 2 l100.phlapa-vfttp-60.verizon-gni.net (98.114.95.1) 8.910 ms 8.760 ms 7.026 ms 3 g3-0-2-860.phlapa-lcr-08.verizon-gni.net (130.81.139.120) 10.711 ms 8.466 ms 10.698 ms 4 * * * 5 so-13-2-0-0.res-bb-rtr2.verizon-gni.net (130.81.19.118) 14.937 ms 15.975 ms 15.148 ms 6 0.ae2.br2.iad8.alter.net (152.63.34.73) 14.346 ms 13.943 ms 14.833 ms 7 * * * 8 * * * I can ssh to the box from other networks, and here's a traceroute back to my Verzon FIOS IP...other Verizon customers (DSL, etc) report same problem: 2 static-209-17-142-114.gtcust.grouptelecom.net (209.17.142.114) 0.744 ms 0.642 ms 0.620 ms 3 static-66-38-255-9.gtcust.grouptelecom.net (66.38.255.9) 0.750 ms 0.657 ms 0.649 ms 4 GE3-0.PEERA-VANCBC.IP.GROUPTELECOM.NET (66.59.190.6) 0.730 ms 0.694 ms 0.693 ms 5 bx4-vancouver_G1-1-6.net.bell.ca (67.69.199.105) 0.847 ms 0.836 ms 0.828 ms 6 core4-vancouver_ge8-0-0.net.bell.ca (64.230.183.109) 4.637 ms core3-vancouver_ge8-0-0.net.bell.ca (64.230.183.105) 113.794 ms 17.328 ms 7 core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 23.686 ms core1-seattle_pos6-0-0_core.net.bell.ca (64.230.144.89) 4.672 ms core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 5.720 ms 8 bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.358 ms bx2-seattle_POS11-0-0.net.bell.ca (64.230.186.26) 4.396 ms bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.353 ms 9 Comcast-peering.net.bell.ca (67.69.246.198) 4.991 ms 4.795 ms 4.795 ms 10 pos-0-4-0-0-cr01.seattle.wa.ibone.comcast.net (68.86.86.137) 8.285 ms 5.258 ms 4.919 ms 11 pos-0-6-0-0-cr01.denver.co.ibone.comcast.net (68.86.87.49) 46.892 ms 46.901 ms 46.952 ms 12 pos-0-13-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.245) 57.243 ms 57.359 ms 57.333 ms 13 pos-2-13-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.87.25) 85.080 ms 85.020 ms 85.069 ms 14 te-2-1-pe01.philadelphia.pa.ibone.comcast.net (68.86.84.194) 87.264 ms 86.372 ms 86.453 ms 15 75.149.230.250 (75.149.230.250) 86.548 ms 86.489 ms 86.439 ms On Mon, 28 Feb 2011, Mike Tancsa wrote: > I was just looking at an issue between 701 in Toronto. Seems to be resolved now-- at least the issue I was seeing. > > > the bad traceroute, looked like > .... > 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.988 ms 0.978 ms 1.578 ms > 4 209.58.94.10 (209.58.94.10) 1.902 ms 71.416 ms 3.472 ms > 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 22.286 ms 21.957 ms 29.472 ms > 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 67.961 ms > if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121) 21.449 ms 20.956 ms > 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 21.975 ms 22.467 ms 21.977 ms > 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 20.977 ms * 30.520 ms > 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.478 ms 21.458 ms 21.477 ms > 10 * > 11 * > > Now its working > > .... > 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.975 ms > 4 209.58.94.10 (209.58.94.10) 1.975 ms > 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 21.445 ms > 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 54.472 ms > 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 112.426 ms > 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 22.964 ms > 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.455 ms > 10 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 21.466 ms > 11 0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121) 34.958 ms > 12 0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205) 33.958 ms > > > When it was not working, packets would not get from my AS (11647) to the target in IP in AS701. But packets from 701 would get back to my AS. The AS path in both directions are 701-6453-11647 and 11647 6453 701... I saw a similar outage to VPNs I have in AS15290 which I see as 11647 6453 701 15290. However, I did not have time to check if it was the same behaviour with loss being in one direction. In both cases, IPs that follow 11647 174 701 and 701 174 11647 and 11647 174 7018 15290 and 15290 7018 174 11647 were not impacted. > > ---Mike > > > > On 2/28/2011 9:53 PM, ML wrote: >> Seeing some packet loss via Cogent. >> >> www.internetpulse.net seems to be lighting up. >> >> > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike at sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From up at 3.am Wed Aug 3 14:31:47 2011 From: up at 3.am (James Smallacombe) Date: Wed, 3 Aug 2011 15:31:47 -0400 (EDT) Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> Message-ID: Please disregard my reply...I used pine for the first time in months and although this was tagged as a New message, I didn't see the date was from months ago. However, I AM seeing problems right now as described below...anybody aware of any Verizon issues? On Wed, 3 Aug 2011, James Smallacombe wrote: > > I'm having issues through Verizon too...I have a server colocated in > Vancouver...could it be a Canadian thing with Verizon? > > 2 l100.phlapa-vfttp-60.verizon-gni.net (98.114.95.1) 8.910 ms 8.760 ms > 7.026 ms > 3 g3-0-2-860.phlapa-lcr-08.verizon-gni.net (130.81.139.120) 10.711 ms > 8.466 ms 10.698 ms > 4 * * * > 5 so-13-2-0-0.res-bb-rtr2.verizon-gni.net (130.81.19.118) 14.937 ms 15.975 > ms 15.148 ms > 6 0.ae2.br2.iad8.alter.net (152.63.34.73) 14.346 ms 13.943 ms 14.833 ms > 7 * * * > 8 * * * > > I can ssh to the box from other networks, and here's a traceroute back to my > Verzon FIOS IP...other Verizon customers (DSL, etc) report same problem: > > 2 static-209-17-142-114.gtcust.grouptelecom.net (209.17.142.114) 0.744 ms > 0.642 ms 0.620 ms > 3 static-66-38-255-9.gtcust.grouptelecom.net (66.38.255.9) 0.750 ms 0.657 > ms 0.649 ms > 4 GE3-0.PEERA-VANCBC.IP.GROUPTELECOM.NET (66.59.190.6) 0.730 ms 0.694 ms > 0.693 ms > 5 bx4-vancouver_G1-1-6.net.bell.ca (67.69.199.105) 0.847 ms 0.836 ms > 0.828 ms > 6 core4-vancouver_ge8-0-0.net.bell.ca (64.230.183.109) 4.637 ms > core3-vancouver_ge8-0-0.net.bell.ca (64.230.183.105) 113.794 ms 17.328 > ms > 7 core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 23.686 ms > core1-seattle_pos6-0-0_core.net.bell.ca (64.230.144.89) 4.672 ms > core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 5.720 ms > 8 bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.358 ms > bx2-seattle_POS11-0-0.net.bell.ca (64.230.186.26) 4.396 ms > bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.353 ms > 9 Comcast-peering.net.bell.ca (67.69.246.198) 4.991 ms 4.795 ms 4.795 ms > 10 pos-0-4-0-0-cr01.seattle.wa.ibone.comcast.net (68.86.86.137) 8.285 ms > 5.258 ms 4.919 ms > 11 pos-0-6-0-0-cr01.denver.co.ibone.comcast.net (68.86.87.49) 46.892 ms > 46.901 ms 46.952 ms > 12 pos-0-13-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.245) 57.243 ms > 57.359 ms 57.333 ms > 13 pos-2-13-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.87.25) 85.080 ms > 85.020 ms 85.069 ms > 14 te-2-1-pe01.philadelphia.pa.ibone.comcast.net (68.86.84.194) 87.264 ms > 86.372 ms 86.453 ms > 15 75.149.230.250 (75.149.230.250) 86.548 ms 86.489 ms 86.439 ms > > > On Mon, 28 Feb 2011, Mike Tancsa wrote: > >> I was just looking at an issue between 701 in Toronto. Seems to be >> resolved now-- at least the issue I was seeing. >> >> >> the bad traceroute, looked like >> .... >> 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.988 ms 0.978 ms >> 1.578 ms >> 4 209.58.94.10 (209.58.94.10) 1.902 ms 71.416 ms 3.472 ms >> 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 22.286 ms 21.957 >> ms 29.472 ms >> 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 67.961 ms >> if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121) 21.449 ms 20.956 >> ms >> 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 21.975 ms 22.467 ms >> 21.977 ms >> 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 20.977 ms * >> 30.520 ms >> 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.478 ms 21.458 ms >> 21.477 ms >> 10 * >> 11 * >> >> Now its working >> >> .... >> 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.975 ms >> 4 209.58.94.10 (209.58.94.10) 1.975 ms >> 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 21.445 ms >> 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 54.472 ms >> 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 112.426 ms >> 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 22.964 ms >> 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.455 ms >> 10 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 21.466 ms >> 11 0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121) 34.958 ms >> 12 0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205) 33.958 ms >> >> >> When it was not working, packets would not get from my AS (11647) to the >> target in IP in AS701. But packets from 701 would get back to my AS. The >> AS path in both directions are 701-6453-11647 and 11647 6453 701... I saw >> a similar outage to VPNs I have in AS15290 which I see as 11647 6453 701 >> 15290. However, I did not have time to check if it was the same behaviour >> with loss being in one direction. In both cases, IPs that follow 11647 174 >> 701 and 701 174 11647 and 11647 174 7018 15290 and 15290 7018 174 11647 >> were not impacted. >> >> ---Mike >> >> >> >> On 2/28/2011 9:53 PM, ML wrote: >>> Seeing some packet loss via Cogent. >>> >>> www.internetpulse.net seems to be lighting up. >>> >>> >> >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike at sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >> >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From mike at sentex.net Wed Aug 3 14:34:53 2011 From: mike at sentex.net (Mike Tancsa) Date: Wed, 03 Aug 2011 15:34:53 -0400 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> Message-ID: <4E39A2DD.2000507@sentex.net> Hi, Yeah, I was just seeing some issues through TATA (AS6453) with routes being blackholed in Newark, or at least that was where the packets stopped. I had to shut my peer with them and I just finished opening a trouble ticket. A traceroute to 209.167.35.0/24 from a source addr in 205.211.164.0/24 byte packets 1 teleglobe-vl38-tor (205.211.165.121) 0.259 ms 0.465 ms 0.488 ms 2 if-2-3-513.core4.TNK-Toronto.as6453.net (209.58.16.21) 0.987 ms 0.981 ms 0.565 ms 3 if-14-0-0.mcore3.TTT-Scarborough.as6453.net (63.243.172.2) 53.390 ms 2.973 ms 2.991 ms 4 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 20.481 ms 62.938 ms 20.967 ms 5 if-2-2.tcore2.NJY-Newark.as6453.net (66.198.70.2) 20.986 ms 21.059 ms 20.871 ms 6 * * * Not sure if it was after them or coming back to them. Same source addr through AS174 is fine ---Mike On 8/3/2011 3:27 PM, James Smallacombe wrote: > > I'm having issues through Verizon too...I have a server colocated in > Vancouver...could it be a Canadian thing with Verizon? > > 2 l100.phlapa-vfttp-60.verizon-gni.net (98.114.95.1) 8.910 ms 8.760 > ms 7.026 ms > 3 g3-0-2-860.phlapa-lcr-08.verizon-gni.net (130.81.139.120) 10.711 ms > 8.466 ms 10.698 ms > 4 * * * > 5 so-13-2-0-0.res-bb-rtr2.verizon-gni.net (130.81.19.118) 14.937 ms > 15.975 ms 15.148 ms > 6 0.ae2.br2.iad8.alter.net (152.63.34.73) 14.346 ms 13.943 ms > 14.833 ms > 7 * * * > 8 * * * > > I can ssh to the box from other networks, and here's a traceroute back > to my Verzon FIOS IP...other Verizon customers (DSL, etc) report same > problem: > > 2 static-209-17-142-114.gtcust.grouptelecom.net (209.17.142.114) > 0.744 ms 0.642 ms 0.620 ms > 3 static-66-38-255-9.gtcust.grouptelecom.net (66.38.255.9) 0.750 ms > 0.657 ms 0.649 ms > 4 GE3-0.PEERA-VANCBC.IP.GROUPTELECOM.NET (66.59.190.6) 0.730 ms > 0.694 ms 0.693 ms > 5 bx4-vancouver_G1-1-6.net.bell.ca (67.69.199.105) 0.847 ms 0.836 ms > 0.828 ms > 6 core4-vancouver_ge8-0-0.net.bell.ca (64.230.183.109) 4.637 ms > core3-vancouver_ge8-0-0.net.bell.ca (64.230.183.105) 113.794 ms > 17.328 ms > 7 core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 23.686 ms > core1-seattle_pos6-0-0_core.net.bell.ca (64.230.144.89) 4.672 ms > core2-seattle_pos4-0-0_core.net.bell.ca (64.230.144.97) 5.720 ms > 8 bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.358 ms > bx2-seattle_POS11-0-0.net.bell.ca (64.230.186.26) 4.396 ms > bx2-seattle_POS10-0-0.net.bell.ca (64.230.186.22) 4.353 ms > 9 Comcast-peering.net.bell.ca (67.69.246.198) 4.991 ms 4.795 ms > 4.795 ms > 10 pos-0-4-0-0-cr01.seattle.wa.ibone.comcast.net (68.86.86.137) 8.285 > ms 5.258 ms 4.919 ms > 11 pos-0-6-0-0-cr01.denver.co.ibone.comcast.net (68.86.87.49) 46.892 > ms 46.901 ms 46.952 ms > 12 pos-0-13-0-0-cr01.chicago.il.ibone.comcast.net (68.86.85.245) > 57.243 ms 57.359 ms 57.333 ms > 13 pos-2-13-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.87.25) 85.080 > ms 85.020 ms 85.069 ms > 14 te-2-1-pe01.philadelphia.pa.ibone.comcast.net (68.86.84.194) 87.264 > ms 86.372 ms 86.453 ms > 15 75.149.230.250 (75.149.230.250) 86.548 ms 86.489 ms 86.439 ms > > > On Mon, 28 Feb 2011, Mike Tancsa wrote: > >> I was just looking at an issue between 701 in Toronto. Seems to be >> resolved now-- at least the issue I was seeing. >> >> >> the bad traceroute, looked like >> .... >> 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.988 ms 0.978 >> ms 1.578 ms >> 4 209.58.94.10 (209.58.94.10) 1.902 ms 71.416 ms 3.472 ms >> 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 22.286 ms >> 21.957 ms 29.472 ms >> 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 67.961 ms >> if-3-0-0.mcore3.NJY-Newark.as6453.net (216.6.57.121) 21.449 ms >> 20.956 ms >> 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 21.975 ms >> 22.467 ms 21.977 ms >> 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 20.977 ms * >> 30.520 ms >> 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.478 ms 21.458 ms >> 21.477 ms >> 10 * >> 11 * >> >> Now its working >> >> .... >> 3 if-3-0-2.core3.TNK-Toronto.as6453.net (64.86.81.3) 0.975 ms >> 4 209.58.94.10 (209.58.94.10) 1.975 ms >> 5 if-3-1-0-0.tcore1.NJY-Newark.as6453.net (216.6.98.34) 21.445 ms >> 6 if-12-0.mcore3.NJY-Newark.as6453.net (66.198.70.14) 54.472 ms >> 7 if-10-0.core3.NTO-NewYork.as6453.net (216.6.57.66) 112.426 ms >> 8 Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49) 22.964 ms >> 9 0.ae20.BR2.NYC4.ALTER.NET (204.255.168.173) 21.455 ms >> 10 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 21.466 ms >> 11 0.so-5-1-0.XT2.TOR2.ALTER.NET (152.63.128.121) 34.958 ms >> 12 0.POS7-1.GW2.TOR2.ALTER.NET (152.63.131.205) 33.958 ms >> >> >> When it was not working, packets would not get from my AS (11647) to >> the target in IP in AS701. But packets from 701 would get back to my >> AS. The AS path in both directions are 701-6453-11647 and 11647 6453 >> 701... I saw a similar outage to VPNs I have in AS15290 which I see >> as 11647 6453 701 15290. However, I did not have time to check if it >> was the same behaviour with loss being in one direction. In both >> cases, IPs that follow 11647 174 701 and 701 174 11647 and 11647 174 >> 7018 15290 and 15290 7018 174 11647 were not impacted. >> >> ---Mike >> >> >> >> On 2/28/2011 9:53 PM, ML wrote: >>> Seeing some packet loss via Cogent. >>> >>> www.internetpulse.net seems to be lighting up. >>> >>> >> >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike at sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >> >> > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From mike at sentex.net Wed Aug 3 14:50:03 2011 From: mike at sentex.net (Mike Tancsa) Date: Wed, 03 Aug 2011 15:50:03 -0400 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> Message-ID: <4E39A66B.4030209@sentex.net> On 8/3/2011 3:31 PM, James Smallacombe wrote: > > > However, I AM seeing problems right now as described below...anybody > aware of any Verizon issues? I was told by TATA one of their core routers in NY is not reachable. So perhaps some inadvertent black hole routing between them / by them. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From pete at altadena.net Wed Aug 3 14:53:10 2011 From: pete at altadena.net (Pete Carah) Date: Wed, 03 Aug 2011 15:53:10 -0400 Subject: assume v6 available, average cost to implement In-Reply-To: <201108031514.p73FEsq1050688@nic-naa.net> References: <201108031514.p73FEsq1050688@nic-naa.net> Message-ID: <4E39A726.3040109@altadena.net> On 08/03/2011 11:14 AM, brunner at nic-naa.net wrote: > Folks, > > In the never ending game of policy whack-a-mole, we are offered the claim that > that the cost to a small to medium business to make its operational purpose > v6 address enabled is in the mid-five figures. > > For those of you who do smb consults, some numbers to make a hypothetical > shop consisting of a quarter rack of gear running nothing more goofy than > a couple of applications on a couple of ports, basicially, a dbms plus a > bit of gorp, say in central Kansas, to which some provider, say Kansas > Telekenesis and Telefriend has just made v6 happy. > > Having renumbered hq.af.mil some time ago, I'm expecting the 50k bogie to > add colons to some retail insurance office or mortuary in central Kansas > to be on the exceedingly good dope high side. > > Thanks in advance for real numbers, which I'll sanitize before using to > attmept to keep one policy playpen slightly less crazy than normal. I have dual-stacked 4 networks so far, 3 small (soekris freebsd router) and one larger (3 7206vxr, all border+core). The first small one started with the soekris in v4-only (comcast), added a tunnel and then took a week or two of evenings to straighten out. The second (also comcast v4-only) changed out a netscreen to the soekris when we multihomed, then added a v6 tunnel and dual-stacked all 10 internal vlans; this took a few days of my time spread over a week or two (never v6-enabled the xp or win2003 systems, though. Linux, BSD, and vista+win7 all "just worked". I'm not sure if samba is properly v6-configured yet but it doesn't (so far) matter). The third small one took one evening (it was a duplicate of the first small one, both single-homed home systems with soekris freebsd routers.) The 7206 one is still progressing without (so far) a v6 IGP, and only a few vlans actually dual-stacked. It does have BGP6 working on two of the borders (and ibgp to all 3) so the system is native and not tunneled (except for one remote location with a v4-only T1 connection). So the most for a "small business" size system was the home one with the learning curve at maybe 2 weeks of evenings (probably 30 hours). The last was probably 4. -- Pete From owen at delong.com Wed Aug 3 15:14:52 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Aug 2011 13:14:52 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> References: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> Message-ID: <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> On Aug 3, 2011, at 10:53 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> On Aug 3, 2011, at 6:55 AM, Jay Ashworth wrote: >>> You guys aren't *near* paranoid enough. :-) >>> >>> If the ISP >>> >>> a) Assigns dynamic addresses to customers, and >>> b) changes those IPs on a relatively short scale (days) >>> >>> then >>> >>> c) outside parties *who are not the ISP or an LEO* will have a >>> relatively harder time tying together two visits solely by the IP >>> address. >> >> ROFL... Yeah, right... Because the MAC suffix won't do anything. > > Did I mention I haven't implemented v6 yet? :-) > No, you didn't. Perhaps you should spend some time learning about it before you opine on how it should or should not be implemented. FWIW, I have implemented IPv6 in multiple organizations, including my home where I've been running with it for several years. > *Really*? It bakes the endpoint MAC into the IP? Well, that's miserably > poor architecture design. > It can and it is a common default. It is not required. It's actually rather elegant architecture design for the goals it was implemented to accomplish. >>> While this isn't "privacy", per se, that "making harder" is at least >>> somewhat useful to a client in reducing the odds that such >>> non-ISP/LEO >>> parties will be unable to tie their visits, assuming they've >>> controlled >>> the items they *can* control (cookies, flash cookies, etc). >> >> Which is something, what, 1% of people probably even know how to do, >> let alone practice on a regular basis. > > Yup; let's go out of our way to penalize the smart people; that's a > *great* plan; I so enjoy it when people do it -- and they do it *far* > too often for my tastes. > No, my point is that if you use RFC-4193, there's not really much benefit from altering the prefix, so, nobody gets penalized and you can still have static addresses. Further, I consider myself relatively smart and by not having static prefixes, you're blocking things I want, so, arguably dynamic prefixes also penalize the smart people. >>> Imperfect security != no security, *as long as you know where the >>> holes are*. >> >> If people want this, they can use RFC-4193 to just about the same >> effect. The ISP modifying the prefix regularly simply doesn't do much. > > I'll make a note of it. > Let me know if you have further questions. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From leo.vegoda at icann.org Wed Aug 3 15:19:28 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 3 Aug 2011 13:19:28 -0700 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> References: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341824F4219A4A@EXVPMBX100-1.exc.icann.org> You wrote: [...] > > > c) outside parties *who are not the ISP or an LEO* will have a > > > relatively harder time tying together two visits solely by the IP > > > address. > > > > ROFL... Yeah, right... Because the MAC suffix won't do anything. > > Did I mention I haven't implemented v6 yet? :-) > > *Really*? It bakes the endpoint MAC into the IP? Well, that's miserably > poor architecture design. The vast majority of people use Windows as an OS and Windows defaults to using RFC 4941 privacy extensions. I *think* it changes it address every two hours. Regards, Leo From jra at baylink.com Wed Aug 3 15:38:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Aug 2011 16:38:58 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> Message-ID: <3260859.439.1312403938080.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > > Did I mention I haven't implemented v6 yet? :-) > > No, you didn't. Perhaps you should spend some time learning about > it before you opine on how it should or should not be implemented. Perhaps. But that's a SHOULD, not a MUST; it's possible to make useful observations without having every single implementation detail, quite often. > FWIW, I have implemented IPv6 in multiple organizations, including > my home where I've been running with it for several years. You continue to put your home network up as an examplar, Owen, for many things. I don't think it's an exemplar of most of the things you do -- it is *specifically* not a Home Network as that term of art is, I think, currently understood by most people, even though it's a network, in a home. > > *Really*? It bakes the endpoint MAC into the IP? Well, that's > > miserably poor architecture design. > > It can and it is a common default. It is not required. Good to know. > It's actually rather elegant architecture design for the goals it was > implemented to accomplish. I will look up what those are. I'm not wilfully blind, and I don't have opinions that are unchangeable. > Let me know if you have further questions. I'll do that, thanks. Has ORA done an IPv6 book? My Borders seems to be having a sale... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Wed Aug 3 15:39:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 3 Aug 2011 16:39:51 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341824F4219A4A@EXVPMBX100-1.exc.icann.org> Message-ID: <21570414.441.1312403991197.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Vegoda" > > *Really*? It bakes the endpoint MAC into the IP? Well, that's > > miserably poor architecture design. > > The vast majority of people use Windows as an OS and Windows defaults > to using RFC 4941 privacy extensions. I *think* it changes it address > every two hours. Microsoft did something right. ::Jay falls to the floor:: Cheers, -- jr 'ouch' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From froomkin at law.miami.edu Wed Aug 3 15:47:39 2011 From: froomkin at law.miami.edu (Michael Froomkin - U.Miami School of Law) Date: Wed, 3 Aug 2011 16:47:39 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> References: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> Message-ID: On Wed, 3 Aug 2011, Owen DeLong wrote: [...] > No, my point is that if you use RFC-4193, there's not really much benefit > from altering the prefix, so, nobody gets penalized and you can still have > static addresses. [...] If anyone is aware of any other widely-used applications in home/office computing, or apps or devices in mobile telecoms, that use RFC-4193 *by default* I would be very interested to learn about them for a paper I am working on. -- A. Michael Froomkin, http://www.law.tm Blog: http://www.discourse.net Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law Editor, Jotwell: The Journal of Things We Like (Lots), jotwell.com U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | froomkin at law.tm -->It's hot here.<-- From jason at lixfeld.ca Wed Aug 3 16:32:15 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 3 Aug 2011 17:32:15 -0400 Subject: Verizon Issues? East Coast US In-Reply-To: <4E39A66B.4030209@sentex.net> References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> <4E39A66B.4030209@sentex.net> Message-ID: On 2011-08-03, at 3:50 PM, Mike Tancsa wrote: > On 8/3/2011 3:31 PM, James Smallacombe wrote: >> >> >> However, I AM seeing problems right now as described below...anybody >> aware of any Verizon issues? > > I was told by TATA one of their core routers in NY is not reachable. So > perhaps some inadvertent black hole routing between them / by them. Do you have a ticket number, Mike? Seems like they are still blackholing traffic. From mike at sentex.net Wed Aug 3 18:05:22 2011 From: mike at sentex.net (Mike Tancsa) Date: Wed, 03 Aug 2011 19:05:22 -0400 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> <4D6C62E4.8010102@sentex.net> <4E39A66B.4030209@sentex.net> Message-ID: <4E39D432.3020209@sentex.net> On 8/3/2011 5:32 PM, Jason Lixfeld wrote: > On 2011-08-03, at 3:50 PM, Mike Tancsa wrote: > >> On 8/3/2011 3:31 PM, James Smallacombe wrote: >>> >>> >>> However, I AM seeing problems right now as described below...anybody >>> aware of any Verizon issues? >> >> I was told by TATA one of their core routers in NY is not reachable. So >> perhaps some inadvertent black hole routing between them / by them. > > Do you have a ticket number, Mike? Seems like they are still blackholing traffic. I will send the ticket offlist. The last update I got from them an hr ago ---------------- Dear Customer, Our TAC team investigated and found still our router in New York is facing issue. We have to emergency upgraded the ios and clear the issue. We will update after activity is completed. ---------------- ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From mpalmer at hezmatt.org Wed Aug 3 18:11:15 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 4 Aug 2011 09:11:15 +1000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: References: <20110803.091421.74749615.sthaug@nethelp.no> <364F1DA6-861A-46B8-95F4-5B9B0B62EF35@delong.com> <20110803.100439.74745741.sthaug@nethelp.no> <4E397D55.1000203@gmail.com> Message-ID: <20110803231115.GV3135@hezmatt.org> On Wed, Aug 03, 2011 at 10:00:37AM -0700, Bill Woodcock wrote: > Also good for customer privacy. LE can still subpoena ISP logs, but > e-commerce sites can't track users quite as easily. So... you're in that alternate universe populated by people who *aren't* constantly logged onto facebook. Good to know. - Matt From Valdis.Kletnieks at vt.edu Wed Aug 3 18:31:53 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Aug 2011 19:31:53 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: Your message of "Tue, 02 Aug 2011 22:37:55 PDT." <6BE2E719-710A-4A8C-9B58-BC2924088107@bogus.com> References: <877h6w9emi.fsf@nemi.mork.no> <20110802143239.028B31261C13@drugs.dv.isc.org> <042AB424-C9AF-4460-96D0-96FB2BB100D1@delong.com> <4E38C59D.8000201@jima.tk> <0A9ED519-D8CB-4AD2-8B6B-42D4AEEFA15D@internode.com.au> <6BE2E719-710A-4A8C-9B58-BC2924088107@bogus.com> Message-ID: <114038.1312414313@turing-police.cc.vt.edu> On Tue, 02 Aug 2011 22:37:55 PDT, Joel Jaeggli said: > there are 38453 ASes that appear in the DFZ this week and I don't see > that number growing to 1 billion anytime soon. Exactly. Right now, how many routes flap if Comcast drops a state's worth of cable customers for a moment? What does *your* router do when that happens? Does it even notice or care? And what will your router do with the tsunami of link updates if all those customers were multihomed? Yeah, there's that whole routing table explosion problem when everybody and their pet llama multihomes. And till you address that little problem, 99.44% of people's multihoming will be "Darn, Comcast died again, let me turn on the AT&T wifi card and try that instead". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mmc at internode.com.au Wed Aug 3 20:12:04 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 4 Aug 2011 01:12:04 +0000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <17340112.373.1312379751660.JavaMail.root@benjamin.baylink.com> References: <17340112.373.1312379751660.JavaMail.root@benjamin.baylink.com> Message-ID: <180B117F-D1CE-4B24-B04A-096E28801CB6@internode.com.au> On 03/08/2011, at 11:25 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Mikael Abrahamsson" > >> On Wed, 3 Aug 2011, Owen DeLong wrote: >> >>> Europe is a little odd in that way, especially DE and NO in that there >>> seems to be this weird FUD running around claiming that static addresses >>> are in some way more antithetical to privacy. >> >> Yes, I agree. I know people who choose provider based on the availability >> of static addresses, I know very few who avoid static address ISPs because >> of this fact. >> >> FUD indeed. > > You guys aren't *near* paranoid enough. :-) > > If the ISP > > a) Assigns dynamic addresses to customers, and > b) changes those IPs on a relatively short scale (days) > > then > > c) outside parties *who are not the ISP or an LEO* will have a > relatively harder time tying together two visits solely by the IP > address. > > While this isn't "privacy", per se, that "making harder" is at least > somewhat useful to a client in reducing the odds that such non-ISP/LEO > parties will be unable to tie their visits, assuming they've controlled > the items they *can* control (cookies, flash cookies, etc). > > We've gone with static /56 v6 ranges for customers. Why? Customers told us they wanted address stability. Pretty much more than anything else. Admittedly the people who opt'ed into the trial part are not typical customers, but it's something they were all fairly adamant about. We're small globally, but we're the 5th largest broadband provider in Australia and we've actually gone and delivered IPv6 natively to our broadband customer base (as well as corporate and other clients). We also sell only v6 capable ADSL CPE (ie. have actual firmware that works with dual stack broadband. MMC From davehart at gmail.com Thu Aug 4 00:06:13 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 4 Aug 2011 05:06:13 +0000 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <3260859.439.1312403938080.JavaMail.root@benjamin.baylink.com> References: <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> <3260859.439.1312403938080.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Aug 3, 2011 at 20:38 UTC, Jay Ashworth wrote: >> From: "Owen DeLong" >> > Did I mention I haven't implemented v6 yet? :-) >> >> No, you didn't. Perhaps you should spend some time learning about >> it before you opine on how it should or should not be implemented. > > Perhaps. ?But that's a SHOULD, not a MUST; it's possible to make useful > observations without having every single implementation detail, quite often. It's also possible to demonstrate you're talking out your ass with IPv4 assumptions about IPv6 issues in front of a few thousand people who aren't ignorant of IPv6. Cheers, Dave Hart From jamie at photon.com Thu Aug 4 06:26:36 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 4 Aug 2011 07:26:36 -0400 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <17132633.281.1312314965192.JavaMail.root@benjamin.baylink.com> References: <17132633.281.1312314965192.JavaMail.root@benjamin.baylink.com> Message-ID: <275FEA2949B48341A3B46F424B613D857CC7@WDC-MX.photon.com> Oh please, you know practical, operational, and security concerns mean nothing next to the beauty and purity of the perfect network protocol design. Jamie -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Tuesday, August 02, 2011 3:56 PM To: NANOG Subject: Re: dynamic or static IPv6 prefixes to residential customers ----- Original Message ----- > From: "james machado" > Complain about NAT all you want but NAT + RFC 1918 addressing in IPv4 > made things such as these much nicer in a home and business setting. An argument I've been making right along. Concern about what's happening network-wise outside my edge router belongs to my edge router, *and no other device on my LAN* should be held hostage by problems there. That's my best practice advice (to my clients, at least), and if IPv6 makes that impossible, well, then, things are gonna get messy, until someone figures out a way around it, cause I'm sure I'm not the only person who views it that way... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From hannes at stressinduktion.org Thu Aug 4 07:00:56 2011 From: hannes at stressinduktion.org (Hannes Frederic Sowa) Date: Thu, 4 Aug 2011 14:00:56 +0200 Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> References: <12577234.405.1312393991908.JavaMail.root@benjamin.baylink.com> <78D5861B-A854-44C8-ABD1-62B783885733@delong.com> Message-ID: <20110804120055.GC12632@order.stressinduktion.org> On Wed, Aug 03, 2011 at 01:14:52PM -0700, Owen DeLong wrote: > > *Really*? It bakes the endpoint MAC into the IP? Well, that's miserably > > poor architecture design. > > > > It can and it is a common default. It is not required. > > It's actually rather elegant architecture design for the goals it was > implemented to accomplish. warned against using hardware serial numbers in End-to-End protocols. As Privacy Extensions and DAD actually work great in my environments I will stay with that option. Servers will get static IP addresses. I don't see a need for embedding serial numbers into IP addresses. gruss, Hannes From jason at lixfeld.ca Thu Aug 4 09:57:45 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 4 Aug 2011 10:57:45 -0400 Subject: FTTH CPE landscape Message-ID: <5E8EFA26-CE1B-430A-93A4-9EF89A3B9295@lixfeld.ca> This isn't necessarily operational content, so I apologize in advance for the noise and thus encourage off-list replies (and/or flames). I figure the NANOG demographic might be able to point me in the right direction seeing as how far reaching into the industry the readership is. I'm doing research on potential FTTH CPE vendors and I'd like to poke around for some potential vendors to see who I've missed. The feature wish list more or less looks like so: - Small, wall-mount'ish form factor - 6-8 wire speed 10/100/1000 LAN ports - Generic consumer grade NAT/Firewall - Fixed BX WAN port - 1-2 POTS ports with SIP UA - TR-69 support for full CPE configuration (User features/configuration and SP features/configuration) - No Wifi (or the ability to disable it from the SP provisioning side) - DHCP client - 802.1q on LAN and WAN ports - Multicast - -48v input - Per VLAN egress shaping/policing over WAN port - DHCP option 82 support If anyone has something like this in the field or knows of a vendor who can meet these requirements in some fashion by product line or custom build, please drop me a line. Also, if anyone knows of any NANOG'esque FTTH lists, I'd welcome a subscribe URL. Thanks in advance. From rps at maine.edu Thu Aug 4 10:50:48 2011 From: rps at maine.edu (Ray Soucy) Date: Thu, 4 Aug 2011 11:50:48 -0400 Subject: assume v6 available, average cost to implement In-Reply-To: <201108031514.p73FEsq1050688@nic-naa.net> References: <201108031514.p73FEsq1050688@nic-naa.net> Message-ID: As much of an IPv6 advocate as I am, I think the TCO for the SMB regarding IPv6 is often cost- prohibitive. Not because of CapEx, mind you, but OpEx. That's something we need to fix within the next year if we want to see real IPv6 adoption. Strong IPv6 knowledge is still very rare, especially in the SMB IT workforce. Right now, deploying IPv6 doesn't mean just deploying one technology but several. Do you have an IPv6 firewall? IPS? IPv6 address management solution? Monitoring? Security Policy? The list goes on. To be honest, I'd put the TCO of IPv6 for an SMB to be much closer to six figures than five. There is simply no good solution for them right now. Remember that for IPv4, most of the systems mentioned above are provided through a unified, inexpensive, and easily managed, multi-function firewall. No such product exists for the IPv6 world, at least not in a mature state; so the knowledge required is much higher; the number of systems and services required is much higher; the cost is... higher. I'm sure a few consultants making bank on "deploying" IPv6 for organizations without giving any thought to security, operational, or performance concerns will be more than happy to chime in and say how wrong I am. But trust me, the majority of SMBs aren't completely brainless, and all you have to do is talk to them to know that they have the exact concerns and conclusions mentioned here. On Wed, Aug 3, 2011 at 11:14 AM, wrote: > Folks, > > In the never ending game of policy whack-a-mole, we are offered the claim that > that the cost to a small to medium business to make its operational purpose > v6 address enabled is in the mid-five figures. > > For those of you who do smb consults, some numbers to make a hypothetical > shop consisting of a quarter rack of gear running nothing more goofy than > a couple of applications on a couple of ports, basicially, a dbms plus a > bit of gorp, say in central Kansas, to which some provider, say Kansas > Telekenesis and Telefriend has just made v6 happy. > > Having renumbered hq.af.mil some time ago, I'm expecting the 50k bogie to > add colons to some retail insurance office or mortuary in central Kansas > to be on the exceedingly good dope high side. > > Thanks in advance for real numbers, which I'll sanitize before using to > attmept to keep one policy playpen slightly less crazy than normal. > > Eric > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From raltmann at bbn.com Thu Aug 4 11:07:22 2011 From: raltmann at bbn.com (Rick Altmann) Date: Thu, 4 Aug 2011 12:07:22 -0400 Subject: Errant Advertisement - 128.1/16 Message-ID: Is there anyone from AT&T on the list that could help with a likely misconfiguration? I have not received any response yet to my complaint (see below) submitted to the abuse address on July 26. We have since started advertising this space and would like to resolve the MOAS condition we have created. //////////////// The 128.1.0.0/16 address block is registered to BBN Technologies (AS11488) but is currently unused on any BBN networks. BBN would like to begin using this address space however AS7018 is currently originating public BGP routes for this address block. We believe this to be a configuration error. Please help us resolve this. A traceroute to 128.1.0.1 shows the following routers as the last 4 responding hops: cr1.n54ny.ip.att.net (12.122.81.106) cr81.nw2nj.ip.att.net (12.122.105.30) gar18.n54ny.ip.att.net (12.122.105.101) 12.89.231.190 //////////////// Thanks, Rick From pascal.charest at labsphoenix.com Thu Aug 4 13:43:11 2011 From: pascal.charest at labsphoenix.com (Pascal Charest) Date: Thu, 4 Aug 2011 14:43:11 -0400 Subject: Expanding into China (data center info required) Message-ID: Hi, Sorry to use the NANOG mailing list for such request, but time is of the essence here: One of my client is looking into expanding into China and requested that I get him a ball-park price range for the following requirement. The project is kind of getting out of control and he'd like to receive a range by end-of-day. Any soft quote or anecdotal feedback is accepted - Feel free to answer off list, as to not spam NANOG more. + a 10x20feet cage + 4x50 amps/208v circuits (redundancy is already taken into account here) + 4x30 amps/208v circuits (redundancy is already taken into account here) + 2x20 amps/208v circuits (redundancy is already taken into account here) note on power: we expect to requires something like 25k watts... any limits? note on location: Hong Kong seem to be a good spot, but there is no restriction on the exact location. Also: Is ipv4/ipv6 connectivity included (what kind of price/bandwidth can we expect? We are looking into a giga connection with 100Mb commited), or is it better to go for our own BGP setup with 2 independents connections (no idea about the state of things in China) ? Any availability of remote 'english speaking' technical hand-on?, P. -- Pascal Charest, Cutting-edge technology consultant @ Les Laboratoires Phoenix http://www.labsphoenix.com From jra at baylink.com Thu Aug 4 10:24:30 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Aug 2011 11:24:30 -0400 (EDT) Subject: dynamic or static IPv6 prefixes to residential customers In-Reply-To: <275FEA2949B48341A3B46F424B613D857CC7@WDC-MX.photon.com> Message-ID: <16104550.487.1312471470618.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jamie Bowden" > Oh please, you know practical, operational, and security concerns mean > nothing next to the beauty and purity of the perfect network protocol > design. I was just replying to Dave, who reminded me that IPv6 is not v4 with bigger addresses, that I thought that was the Worst Imaginable Approach. :-) Cheers -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From tvest at eyeconomics.com Thu Aug 4 14:25:45 2011 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 4 Aug 2011 15:25:45 -0400 Subject: Expanding into China (data center info required) In-Reply-To: References: Message-ID: Hi Pascal, A friendly fyi from a former China and HK surveyor and colocator: Topologically, China and Hong Kong are not the same place at all; in fact for some/many requirement-site pairings, Hong Kong may not not even be the closest place to China. I don't think it's possible to be both sufficiently-informed about operating conditions in the region and completely ambivalent about the China vs. HK choice at the same time. Best of luck with your search, TV On Aug 4, 2011, at 2:43 PM, Pascal Charest wrote: > Hi, > > Sorry to use the NANOG mailing list for such request, but time is of the > essence here: One of my client is looking into expanding into China and > requested that I get him a ball-park price range for the following > requirement. The project is kind of getting out of control and he'd like to > receive a range by end-of-day. Any soft quote or anecdotal feedback is > accepted - Feel free to answer off list, as to not spam NANOG more. > > + a 10x20feet cage > + 4x50 amps/208v circuits (redundancy is already taken into account here) > + 4x30 amps/208v circuits (redundancy is already taken into account here) > + 2x20 amps/208v circuits (redundancy is already taken into account here) > > note on power: we expect to requires something like 25k watts... any limits? > > note on location: Hong Kong seem to be a good spot, but there is no > restriction on the exact location. > > Also: > > Is ipv4/ipv6 connectivity included (what kind of price/bandwidth can we > expect? We are looking into a giga connection with 100Mb commited), or is it > better to go for our own BGP setup with 2 independents connections (no idea > about the state of things in China) ? Any availability of remote 'english > speaking' technical hand-on?, > > > P. > > -- > Pascal Charest, > Cutting-edge technology consultant @ Les Laboratoires Phoenix > http://www.labsphoenix.com From owen at delong.com Thu Aug 4 14:45:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Aug 2011 12:45:25 -0700 Subject: assume v6 available, average cost to implement In-Reply-To: References: <201108031514.p73FEsq1050688@nic-naa.net> Message-ID: On Aug 4, 2011, at 8:50 AM, Ray Soucy wrote: > As much of an IPv6 advocate as I am, I think the TCO for the SMB > regarding IPv6 is often cost- prohibitive. Not because of CapEx, mind > you, but OpEx. That's something we need to fix within the next year > if we want to see real IPv6 adoption. > > Strong IPv6 knowledge is still very rare, especially in the SMB IT workforce. > > Right now, deploying IPv6 doesn't mean just deploying one technology > but several. Do you have an IPv6 firewall? IPS? IPv6 address > management solution? Monitoring? Security Policy? The list goes on. > > To be honest, I'd put the TCO of IPv6 for an SMB to be much closer to > six figures than five. > You're looking at a much larger SMB than most SMBs actually are. For a very large proportion of SMBs, replacing a single CPE device covers the firewall, address management, and if you think they've got IPS, monitoring, or a security policy today for IPv4, well, you're simply delusional. There are a few CPE devices out today that can do this, but, we definitely need more and a wider variety of feature sets. > There is simply no good solution for them right now. Remember that > for IPv4, most of the systems mentioned above are provided through a > unified, inexpensive, and easily managed, multi-function firewall. No > such product exists for the IPv6 world, at least not in a mature > state; so the knowledge required is much higher; the number of systems > and services required is much higher; the cost is... higher. > Seems to me that the SRX-100 comes reasonably close and has relatively proximal capabilities in IPv4 and IPv6. However, at $600, it's probably a bit on the pricey side of many SMB resources. > I'm sure a few consultants making bank on "deploying" IPv6 for > organizations without giving any thought to security, operational, or > performance concerns will be more than happy to chime in and say how > wrong I am. But trust me, the majority of SMBs aren't completely > brainless, and all you have to do is talk to them to know that they > have the exact concerns and conclusions mentioned here. > As a consultant making "bank" to some extent helping others to deploy IPv6, I resent your generalization that we must be ignoring all of those concerns. It's simply not true. I agree that many SMBs aren't completely brainless, but, to say most ignores the reality that most SMBs are someone running a shop to make money doing what they are passionate about, such as SCUBA, sewing, or whatever. The majority of money comes from larger SMBs, but, the vast majority of SMBs in the US are actually single-proprietor businesses with 1-5 employees almost always without any sort of dedicated IT person in the mix. They aren't brainless, but, networking isn't their focus and all they know about any of those issues is the FUD they occasionally hear on TV about someone getting hacked. A responsible consultant will help them apply reasonable measures to protect themselves and explain the cost/benefit tradeoffs of various solutions so that they can make a (more) informed decision. There may be IPv6 consultants out there deploying SMBs on IPv6 irresponsibly, but, not all of us fall into that category. Owen > On Wed, Aug 3, 2011 at 11:14 AM, wrote: >> Folks, >> >> In the never ending game of policy whack-a-mole, we are offered the claim that >> that the cost to a small to medium business to make its operational purpose >> v6 address enabled is in the mid-five figures. >> >> For those of you who do smb consults, some numbers to make a hypothetical >> shop consisting of a quarter rack of gear running nothing more goofy than >> a couple of applications on a couple of ports, basicially, a dbms plus a >> bit of gorp, say in central Kansas, to which some provider, say Kansas >> Telekenesis and Telefriend has just made v6 happy. >> >> Having renumbered hq.af.mil some time ago, I'm expecting the 50k bogie to >> add colons to some retail insurance office or mortuary in central Kansas >> to be on the exceedingly good dope high side. >> >> Thanks in advance for real numbers, which I'll sanitize before using to >> attmept to keep one policy playpen slightly less crazy than normal. >> >> Eric >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jra at baylink.com Thu Aug 4 10:35:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Aug 2011 11:35:50 -0400 (EDT) Subject: FTTH CPE landscape In-Reply-To: <5E8EFA26-CE1B-430A-93A4-9EF89A3B9295@lixfeld.ca> Message-ID: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> > - Generic consumer grade NAT/Firewall Hobby horse: please make sure it support bridge mode? Those of us who want to put our own routers on the wire will hate you otherwise. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Thu Aug 4 15:30:35 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Aug 2011 13:30:35 -0700 Subject: FTTH CPE landscape In-Reply-To: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> Message-ID: On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >> - Generic consumer grade NAT/Firewall > > Hobby horse: please make sure it support bridge mode? Those of us who > want to put our own routers on the wire will hate you otherwise. > Why? As long as it can be a transparent router, why would it need to be a bridge? Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From nathan at atlasnetworks.us Thu Aug 4 15:54:23 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 4 Aug 2011 20:54:23 +0000 Subject: FTTH CPE landscape In-Reply-To: References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B516005@ex-mb-1.corp.atlasnetworks.us> > Why? As long as it can be a transparent router, why would it need to be > a bridge? Layer 2 CPE capability is a big deal, especially if you're doing unrouted multicast (see many TV/VoD over ethernet platforms for details). But it's also nice for handing the customer a layer-2 service port like they're used to getting, if they want it that way. The routing engine in CPE's is often simply not as capable as the bridging mechanism, so there's an end-user experience to consider. It's also worth noting that this feature will probably become less important as IPv6 and DHCP6-PD becomes more widely deployed. Until then, the extra routing in IPv4 starts to chew up some serious address space if you're rolling out thousands or more of the CPEs. See most national ISP's CPE configuration if you think it's unusual to want to hand off services on a bridged interface- it's not, at all. Nathan Eisenberg From jra at baylink.com Thu Aug 4 16:08:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Aug 2011 17:08:28 -0400 (EDT) Subject: FTTH CPE landscape In-Reply-To: Message-ID: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: > > >> - Generic consumer grade NAT/Firewall > > > > Hobby horse: please make sure it support bridge mode? Those of us who > > want to put our own routers on the wire will hate you otherwise. > > Why? As long as it can be a transparent router, why would it need to > be a bridge? Ask a Verizon FiOS customer who wants to run IPv4 VPNs. He didn't say IPv6 only, right? I have a couple of customers who can't get bridge mode on residence FiOS service, and therefore can't run their own routers to terminate IPsec. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From owen at delong.com Thu Aug 4 16:32:22 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Aug 2011 14:32:22 -0700 Subject: FTTH CPE landscape In-Reply-To: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> Message-ID: <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >> >>>> - Generic consumer grade NAT/Firewall >>> >>> Hobby horse: please make sure it support bridge mode? Those of us who >>> want to put our own routers on the wire will hate you otherwise. >> >> Why? As long as it can be a transparent router, why would it need to >> be a bridge? > > Ask a Verizon FiOS customer who wants to run IPv4 VPNs. > > He didn't say IPv6 only, right? > > I have a couple of customers who can't get bridge mode on residence FiOS > service, and therefore can't run their own routers to terminate IPsec. > If they could get routed static IPv4 rather than bridge, why wouldn't they be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. That would mean no NAT and routed static IPv4. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dwhite at olp.net Thu Aug 4 16:55:35 2011 From: dwhite at olp.net (Dan White) Date: Thu, 4 Aug 2011 16:55:35 -0500 Subject: FTTH CPE landscape In-Reply-To: <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> Message-ID: <20110804215535.GA4756@dan.olp.net> On 04/08/11?14:32?-0700, Owen DeLong wrote: > >On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Owen DeLong" >> >>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>> >>>>> - Generic consumer grade NAT/Firewall >>>> >>>> Hobby horse: please make sure it support bridge mode? Those of us who >>>> want to put our own routers on the wire will hate you otherwise. >>> >>> Why? As long as it can be a transparent router, why would it need to >>> be a bridge? >> >> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. >> >> He didn't say IPv6 only, right? >> >> I have a couple of customers who can't get bridge mode on residence FiOS >> service, and therefore can't run their own routers to terminate IPsec. >> >If they could get routed static IPv4 rather than bridge, why wouldn't they >be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. >That would mean no NAT and routed static IPv4. For residential use, for users currently requesting one public address, that's a waste of a /30 block (sans routing tricks requiring higher end customer equipment). Multiply that by the number of residential customers you have and that's bordering on mismanagement of your address space. If you're dealing with business customers, then your usage versus wasted ratio is much higher and less of a concern, but what's the point? Are you trying to cut down on a large broadcast domain? -- Dan White From khelms at ispalliance.net Thu Aug 4 17:07:40 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 04 Aug 2011 18:07:40 -0400 Subject: FTTH CPE landscape In-Reply-To: <20110804215535.GA4756@dan.olp.net> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> Message-ID: <4E3B182C.80706@ispalliance.net> > For residential use, for users currently requesting one public address, > that's a waste of a /30 block (sans routing tricks requiring higher end > customer equipment). Multiply that by the number of residential customers > you have and that's bordering on mismanagement of your address space. > > If you're dealing with business customers, then your usage versus wasted > ratio is much higher and less of a concern, but what's the point? Are you > trying to cut down on a large broadcast domain? > Any rational layer 2 access gear regardless of the technology (DSL, FTTx, wireless, or DOCSIS) will/can handle layer 2 isolation already. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From frnkblk at iname.com Thu Aug 4 17:10:41 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 4 Aug 2011 17:10:41 -0500 Subject: FTTH CPE landscape In-Reply-To: <5E8EFA26-CE1B-430A-93A4-9EF89A3B9295@lixfeld.ca> References: <5E8EFA26-CE1B-430A-93A4-9EF89A3B9295@lixfeld.ca> Message-ID: <002701cc52f3$590c2340$0b2469c0$@iname.com> Are you looking for an xPON ONT? Frank -----Original Message----- From: Jason Lixfeld [mailto:jason at lixfeld.ca] Sent: Thursday, August 04, 2011 9:58 AM To: nanog at nanog.org Subject: FTTH CPE landscape This isn't necessarily operational content, so I apologize in advance for the noise and thus encourage off-list replies (and/or flames). I figure the NANOG demographic might be able to point me in the right direction seeing as how far reaching into the industry the readership is. I'm doing research on potential FTTH CPE vendors and I'd like to poke around for some potential vendors to see who I've missed. The feature wish list more or less looks like so: - Small, wall-mount'ish form factor - 6-8 wire speed 10/100/1000 LAN ports - Generic consumer grade NAT/Firewall - Fixed BX WAN port - 1-2 POTS ports with SIP UA - TR-69 support for full CPE configuration (User features/configuration and SP features/configuration) - No Wifi (or the ability to disable it from the SP provisioning side) - DHCP client - 802.1q on LAN and WAN ports - Multicast - -48v input - Per VLAN egress shaping/policing over WAN port - DHCP option 82 support If anyone has something like this in the field or knows of a vendor who can meet these requirements in some fashion by product line or custom build, please drop me a line. Also, if anyone knows of any NANOG'esque FTTH lists, I'd welcome a subscribe URL. Thanks in advance. From jason at lixfeld.ca Thu Aug 4 17:33:24 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 4 Aug 2011 18:33:24 -0400 Subject: FTTH CPE landscape In-Reply-To: <002701cc52f3$590c2340$0b2469c0$@iname.com> References: <5E8EFA26-CE1B-430A-93A4-9EF89A3B9295@lixfeld.ca> <002701cc52f3$590c2340$0b2469c0$@iname.com> Message-ID: <693412D7-29EC-4949-A615-3F25C4760B11@lixfeld.ca> Nope, Ethernet. -- Sent from my mobile device. On 2011-08-04, at 6:10 PM, "Frank Bulk" wrote: > Are you looking for an xPON ONT? > > Frank > > -----Original Message----- > From: Jason Lixfeld [mailto:jason at lixfeld.ca] > Sent: Thursday, August 04, 2011 9:58 AM > To: nanog at nanog.org > Subject: FTTH CPE landscape > > This isn't necessarily operational content, so I apologize in advance for > the noise and thus encourage off-list replies (and/or flames). > > I figure the NANOG demographic might be able to point me in the right > direction seeing as how far reaching into the industry the readership is. > > I'm doing research on potential FTTH CPE vendors and I'd like to poke around > for some potential vendors to see who I've missed. > > The feature wish list more or less looks like so: > > - Small, wall-mount'ish form factor > - 6-8 wire speed 10/100/1000 LAN ports > - Generic consumer grade NAT/Firewall > - Fixed BX WAN port > - 1-2 POTS ports with SIP UA > - TR-69 support for full CPE configuration (User features/configuration and > SP features/configuration) > - No Wifi (or the ability to disable it from the SP provisioning side) > - DHCP client > - 802.1q on LAN and WAN ports > - Multicast > - -48v input > - Per VLAN egress shaping/policing over WAN port > - DHCP option 82 support > > If anyone has something like this in the field or knows of a vendor who can > meet these requirements in some fashion by product line or custom build, > please drop me a line. > > Also, if anyone knows of any NANOG'esque FTTH lists, I'd welcome a subscribe > URL. > > Thanks in advance. > From owen at delong.com Thu Aug 4 17:43:58 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Aug 2011 15:43:58 -0700 Subject: FTTH CPE landscape In-Reply-To: <20110804215535.GA4756@dan.olp.net> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> Message-ID: <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> On Aug 4, 2011, at 2:55 PM, Dan White wrote: > On 04/08/11 14:32 -0700, Owen DeLong wrote: >> >> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Owen DeLong" >>> >>>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>>> >>>>>> - Generic consumer grade NAT/Firewall >>>>> >>>>> Hobby horse: please make sure it support bridge mode? Those of us who >>>>> want to put our own routers on the wire will hate you otherwise. >>>> >>>> Why? As long as it can be a transparent router, why would it need to >>>> be a bridge? >>> >>> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. >>> >>> He didn't say IPv6 only, right? >>> >>> I have a couple of customers who can't get bridge mode on residence FiOS >>> service, and therefore can't run their own routers to terminate IPsec. >>> >> If they could get routed static IPv4 rather than bridge, why wouldn't they >> be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. >> That would mean no NAT and routed static IPv4. > > For residential use, for users currently requesting one public address, > that's a waste of a /30 block (sans routing tricks requiring higher end > customer equipment). Multiply that by the number of residential customers > you have and that's bordering on mismanagement of your address space. > You say waste, I say perfectly valid use. > If you're dealing with business customers, then your usage versus wasted > ratio is much higher and less of a concern, but what's the point? Are you > trying to cut down on a large broadcast domain? > Why is it less of a waste to allocate a /30 to a business using a single public IP than it is to a residence? This makes no sense to me. I simply prefer the additional troubleshooting and other capabilities given to me in a routed environment in most cases. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dan at beanfield.com Thu Aug 4 18:08:30 2011 From: dan at beanfield.com (Dan Armstrong) Date: Thu, 4 Aug 2011 19:08:30 -0400 Subject: FTTH CPE landscape In-Reply-To: <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: On 2011-08-04, at 6:43 PM, Owen DeLong wrote: > > On Aug 4, 2011, at 2:55 PM, Dan White wrote: > >> On 04/08/11 14:32 -0700, Owen DeLong wrote: >>> >>> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: >>> >>>> ----- Original Message ----- >>>>> From: "Owen DeLong" >>>> >>>>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>>>> >>>>>>> - Generic consumer grade NAT/Firewall >>>>>> >>>>>> Hobby horse: please make sure it support bridge mode? Those of us who >>>>>> want to put our own routers on the wire will hate you otherwise. >>>>> >>>>> Why? As long as it can be a transparent router, why would it need to >>>>> be a bridge? >>>> >>>> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. >>>> >>>> He didn't say IPv6 only, right? >>>> >>>> I have a couple of customers who can't get bridge mode on residence FiOS >>>> service, and therefore can't run their own routers to terminate IPsec. >>>> >>> If they could get routed static IPv4 rather than bridge, why wouldn't they >>> be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. >>> That would mean no NAT and routed static IPv4. >> >> For residential use, for users currently requesting one public address, >> that's a waste of a /30 block (sans routing tricks requiring higher end >> customer equipment). Multiply that by the number of residential customers >> you have and that's bordering on mismanagement of your address space. >> > You say waste, I say perfectly valid use. > >> If you're dealing with business customers, then your usage versus wasted >> ratio is much higher and less of a concern, but what's the point? Are you >> trying to cut down on a large broadcast domain? >> > Why is it less of a waste to allocate a /30 to a business using a single public > IP than it is to a residence? This makes no sense to me. > > I simply prefer the additional troubleshooting and other capabilities given > to me in a routed environment in most cases. > > Owen > Realistically, how many home Internet consumers terminate IPSec VPNs? It seems kind of silly to engineer a network around a tiny fraction of less than 1% of the population, doesn't it? From paul4004 at gmail.com Thu Aug 4 18:49:48 2011 From: paul4004 at gmail.com (PC) Date: Thu, 4 Aug 2011 17:49:48 -0600 Subject: FTTH CPE landscape In-Reply-To: References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: IPSEC Not so common. At least it's easy enough for them to be the initiator, in most cases, and IPSEC NAT-T works great. Much more common application would include PC gamers, xbox live, remote desktop, slingbox, windows home server, and torrents. Granted, some of these support UPNP (if your router does too...), but others simply do not do so as easily, or prefer a more static external access solution. On Thu, Aug 4, 2011 at 5:08 PM, Dan Armstrong wrote: > > On 2011-08-04, at 6:43 PM, Owen DeLong wrote: > > > > > On Aug 4, 2011, at 2:55 PM, Dan White wrote: > > > >> On 04/08/11 14:32 -0700, Owen DeLong wrote: > >>> > >>> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: > >>> > >>>> ----- Original Message ----- > >>>>> From: "Owen DeLong" > >>>> > >>>>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: > >>>>> > >>>>>>> - Generic consumer grade NAT/Firewall > >>>>>> > >>>>>> Hobby horse: please make sure it support bridge mode? Those of us > who > >>>>>> want to put our own routers on the wire will hate you otherwise. > >>>>> > >>>>> Why? As long as it can be a transparent router, why would it need to > >>>>> be a bridge? > >>>> > >>>> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. > >>>> > >>>> He didn't say IPv6 only, right? > >>>> > >>>> I have a couple of customers who can't get bridge mode on residence > FiOS > >>>> service, and therefore can't run their own routers to terminate IPsec. > >>>> > >>> If they could get routed static IPv4 rather than bridge, why wouldn't > they > >>> be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. > >>> That would mean no NAT and routed static IPv4. > >> > >> For residential use, for users currently requesting one public address, > >> that's a waste of a /30 block (sans routing tricks requiring higher end > >> customer equipment). Multiply that by the number of residential > customers > >> you have and that's bordering on mismanagement of your address space. > >> > > You say waste, I say perfectly valid use. > > > >> If you're dealing with business customers, then your usage versus wasted > >> ratio is much higher and less of a concern, but what's the point? Are > you > >> trying to cut down on a large broadcast domain? > >> > > Why is it less of a waste to allocate a /30 to a business using a single > public > > IP than it is to a residence? This makes no sense to me. > > > > I simply prefer the additional troubleshooting and other capabilities > given > > to me in a routed environment in most cases. > > > > Owen > > > > Realistically, how many home Internet consumers terminate IPSec VPNs? > > It seems kind of silly to engineer a network around a tiny fraction of less > than 1% of the population, doesn't it? > > > From owen at delong.com Thu Aug 4 19:22:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Aug 2011 17:22:29 -0700 Subject: FTTH CPE landscape In-Reply-To: References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: Among the people I know, on the order of 35%. Not a majority, but, I would not call 1/3rd less than 1%. Owen On Aug 4, 2011, at 4:08 PM, Dan Armstrong wrote: > > On 2011-08-04, at 6:43 PM, Owen DeLong wrote: > >> >> On Aug 4, 2011, at 2:55 PM, Dan White wrote: >> >>> On 04/08/11 14:32 -0700, Owen DeLong wrote: >>>> >>>> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: >>>> >>>>> ----- Original Message ----- >>>>>> From: "Owen DeLong" >>>>> >>>>>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>>>>> >>>>>>>> - Generic consumer grade NAT/Firewall >>>>>>> >>>>>>> Hobby horse: please make sure it support bridge mode? Those of us who >>>>>>> want to put our own routers on the wire will hate you otherwise. >>>>>> >>>>>> Why? As long as it can be a transparent router, why would it need to >>>>>> be a bridge? >>>>> >>>>> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. >>>>> >>>>> He didn't say IPv6 only, right? >>>>> >>>>> I have a couple of customers who can't get bridge mode on residence FiOS >>>>> service, and therefore can't run their own routers to terminate IPsec. >>>>> >>>> If they could get routed static IPv4 rather than bridge, why wouldn't they >>>> be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. >>>> That would mean no NAT and routed static IPv4. >>> >>> For residential use, for users currently requesting one public address, >>> that's a waste of a /30 block (sans routing tricks requiring higher end >>> customer equipment). Multiply that by the number of residential customers >>> you have and that's bordering on mismanagement of your address space. >>> >> You say waste, I say perfectly valid use. >> >>> If you're dealing with business customers, then your usage versus wasted >>> ratio is much higher and less of a concern, but what's the point? Are you >>> trying to cut down on a large broadcast domain? >>> >> Why is it less of a waste to allocate a /30 to a business using a single public >> IP than it is to a residence? This makes no sense to me. >> >> I simply prefer the additional troubleshooting and other capabilities given >> to me in a routed environment in most cases. >> >> Owen >> > > Realistically, how many home Internet consumers terminate IPSec VPNs? > > It seems kind of silly to engineer a network around a tiny fraction of less than 1% of the population, doesn't it? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Aug 4 19:38:39 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Aug 2011 20:38:39 -0400 Subject: FTTH CPE landscape In-Reply-To: Your message of "Thu, 04 Aug 2011 13:30:35 PDT." References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> Message-ID: <56449.1312504719@turing-police.cc.vt.edu> On Thu, 04 Aug 2011 13:30:35 PDT, Owen DeLong said: > On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: > >> - Generic consumer grade NAT/Firewall > > > > Hobby horse: please make sure it support bridge mode? Those of us who > > want to put our own routers on the wire will hate you otherwise. > > > > Why? As long as it can be a transparent router, why would it need to be > a bridge? I must be having a senior moment, but what in the world is a "transparent router" and how is it different from running in bridged mode? (Note that if if it's transmogrifying the packets in some way, it's not really transparent, and if it's not, it's basically bridging...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From james.cutler at consultant.com Thu Aug 4 21:25:19 2011 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 4 Aug 2011 22:25:19 -0400 Subject: FTTH CPE landscape In-Reply-To: References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: <3E8EC8C1-B2E0-4598-8A2E-FD58AF2B20E0@consultant.com> On Aug 4, 2011, at 7:08 PM, Dan Armstrong wrote: > > On 2011-08-04, at 6:43 PM, Owen DeLong wrote: > >> >> On Aug 4, 2011, at 2:55 PM, Dan White wrote: >> >>> On 04/08/11 14:32 -0700, Owen DeLong wrote: >>>> >>>> On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: >>>> >>>>> ----- Original Message ----- >>>>>> From: "Owen DeLong" >>>>> >>>>>> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>>>>> >>>>>>>> - Generic consumer grade NAT/Firewall >>>>>>> >>>>>>> Hobby horse: please make sure it support bridge mode? Those of us who >>>>>>> want to put our own routers on the wire will hate you otherwise. >>>>>> >>>>>> Why? As long as it can be a transparent router, why would it need to >>>>>> be a bridge? >>>>> >>>>> Ask a Verizon FiOS customer who wants to run IPv4 VPNs. >>>>> >>>>> He didn't say IPv6 only, right? >>>>> >>>>> I have a couple of customers who can't get bridge mode on residence FiOS >>>>> service, and therefore can't run their own routers to terminate IPsec. >>>>> >>>> If they could get routed static IPv4 rather than bridge, why wouldn't they >>>> be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. >>>> That would mean no NAT and routed static IPv4. >>> >>> For residential use, for users currently requesting one public address, >>> that's a waste of a /30 block (sans routing tricks requiring higher end >>> customer equipment). Multiply that by the number of residential customers >>> you have and that's bordering on mismanagement of your address space. >>> >> You say waste, I say perfectly valid use. >> >>> If you're dealing with business customers, then your usage versus wasted >>> ratio is much higher and less of a concern, but what's the point? Are you >>> trying to cut down on a large broadcast domain? >>> >> Why is it less of a waste to allocate a /30 to a business using a single public >> IP than it is to a residence? This makes no sense to me. >> >> I simply prefer the additional troubleshooting and other capabilities given >> to me in a routed environment in most cases. >> >> Owen >> > > Realistically, how many home Internet consumers terminate IPSec VPNs? > > It seems kind of silly to engineer a network around a tiny fraction of less than 1% of the population, doesn't it? > > It seems kind of silly to engineer a network against a tiny fraction of less than 1% of the population, doesn't it? James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1861 bytes Desc: not available URL: From owen at delong.com Fri Aug 5 03:23:55 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 01:23:55 -0700 Subject: FTTH CPE landscape In-Reply-To: <56449.1312504719@turing-police.cc.vt.edu> References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> <56449.1312504719@turing-police.cc.vt.edu> Message-ID: <89D7E0CE-BDE0-441A-AF71-F9DD500AE95C@delong.com> On Aug 4, 2011, at 5:38 PM, wrote: > On Thu, 04 Aug 2011 13:30:35 PDT, Owen DeLong said: >> On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: >>>> - Generic consumer grade NAT/Firewall >>> >>> Hobby horse: please make sure it support bridge mode? Those of us who >>> want to put our own routers on the wire will hate you otherwise. >>> >> >> Why? As long as it can be a transparent router, why would it need to be >> a bridge? > > I must be having a senior moment, but what in the world is a "transparent > router" and how is it different from running in bridged mode? (Note that if if > it's transmogrifying the packets in some way, it's not really transparent, and > if it's not, it's basically bridging...) > A transparent router (sorry, poor choice of terminology on my part) is a router which doesn't NAT or become selectively opaque (firewall). In other words, it forwards packets and it doesn't do any other arbitrary things to them at the whim of the ISP, but, rather passes along what the customer gives it to the ISP and vice versa without interference. It differs from a bridge in that it terminates the collision and broadcast domains on either side of it. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From tom at ninjabadger.net Fri Aug 5 03:59:38 2011 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 05 Aug 2011 09:59:38 +0100 Subject: FTTH CPE landscape In-Reply-To: <89D7E0CE-BDE0-441A-AF71-F9DD500AE95C@delong.com> References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> <56449.1312504719@turing-police.cc.vt.edu> <89D7E0CE-BDE0-441A-AF71-F9DD500AE95C@delong.com> Message-ID: <1312534781.2016.6.camel@teh-desktop> On Fri, 2011-08-05 at 01:23 -0700, Owen DeLong wrote: > A transparent router (sorry, poor choice of terminology on my part) is > a router which doesn't NAT or become selectively opaque (firewall). In > other words, it forwards packets and it doesn't do any other arbitrary > things to them at the whim of the ISP, but, rather passes along what > the customer gives it to the ISP and vice versa without interference. So... It's a router? I'm confused as to why the definition "router" exists to describe a device that NATs/selectively firewalls traffic, where "transparent router" describes something that just routes traffic. What? From lists at cluebat.net Fri Aug 5 04:22:00 2011 From: lists at cluebat.net (Kenneth Ratliff) Date: Fri, 5 Aug 2011 05:22:00 -0400 Subject: FTTH CPE landscape In-Reply-To: <1312534781.2016.6.camel@teh-desktop> References: <3559110.499.1312472150246.JavaMail.root@benjamin.baylink.com> <56449.1312504719@turing-police.cc.vt.edu> <89D7E0CE-BDE0-441A-AF71-F9DD500AE95C@delong.com> <1312534781.2016.6.camel@teh-desktop> Message-ID: <307388BD-093A-44C4-A4E1-06657C3BAFA9@cluebat.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 5, 2011, at 4:59 AM, Tom Hill wrote: > On Fri, 2011-08-05 at 01:23 -0700, Owen DeLong wrote: >> A transparent router (sorry, poor choice of terminology on my part) is >> a router which doesn't NAT or become selectively opaque (firewall). In >> other words, it forwards packets and it doesn't do any other arbitrary >> things to them at the whim of the ISP, but, rather passes along what >> the customer gives it to the ISP and vice versa without interference. > > So... It's a router? > > I'm confused as to why the definition "router" exists to describe a > device that NATs/selectively firewalls traffic, where "transparent > router" describes something that just routes traffic. > > What? In the context of taking about CPE gear, it does seem wise to make the distinction. I suppose we can thank Linksys for that. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOO7Y5AAoJEDSV5GS4KsJ4HeYIAIgFepq6FE58MXrUNXDrLxmq HojnMUmcjMuK1esyYwLTRUP5C8rGeGrvLRTABdVyilPuSwGcWZAs3lae+GTOutHF Q9vLn5czh/G56xBC+S+ksFBbkTplPP6T9O2rWWTJE4jZxrB947HeJeD1r0s1MLnc pHiIac2VNIhQngZviIREYa6SYrg0k+XYhgVIKJluVEeyk8YRaBueHkyADKQ1mpmq xbfXz0Xcc2RcPvEcLuVf46J8NE2fkE57c1/BlW2WnIcU5hg9Fr1PPxJ2qm83s+S6 OpgRyMfctSzGTg24RU06pcRvIdfZSduM17yBbo4vP6f5ka2c0CowUl180w8C8tc= =V1dA -----END PGP SIGNATURE----- From jamie at photon.com Fri Aug 5 07:28:32 2011 From: jamie at photon.com (Jamie Bowden) Date: Fri, 5 Aug 2011 08:28:32 -0400 Subject: FTTH CPE landscape In-Reply-To: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> Message-ID: <275FEA2949B48341A3B46F424B613D857CCA@WDC-MX.photon.com> You don't have to use bridge mode for this (and the Actiontec router VZ supplies with FiOS is capable of doing bridge mode, but unless you jump through some fairly esoteric hoops, doing so breaks the guide and VOD, trust me on this...oh and you have to jump through them every time you reset the damn thing for any reason). I set mine with my D-Link as the DMZ host and forward all traffic on all ports unimpeded to it, and it works; Poor Man's Bridge, but it works. Jamie -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, August 04, 2011 5:08 PM To: NANOG Subject: Re: FTTH CPE landscape ----- Original Message ----- > From: "Owen DeLong" > On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: > > >> - Generic consumer grade NAT/Firewall > > > > Hobby horse: please make sure it support bridge mode? Those of us who > > want to put our own routers on the wire will hate you otherwise. > > Why? As long as it can be a transparent router, why would it need to > be a bridge? Ask a Verizon FiOS customer who wants to run IPv4 VPNs. He didn't say IPv6 only, right? I have a couple of customers who can't get bridge mode on residence FiOS service, and therefore can't run their own routers to terminate IPsec. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Aug 5 09:10:41 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Aug 2011 10:10:41 -0400 (EDT) Subject: FTTH CPE landscape In-Reply-To: <89D7E0CE-BDE0-441A-AF71-F9DD500AE95C@delong.com> Message-ID: <11022682.565.1312553441324.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > A transparent router (sorry, poor choice of terminology on my part) is > a router > which doesn't NAT or become selectively opaque (firewall). In other > words, > it forwards packets and it doesn't do any other arbitrary things to > them at the > whim of the ISP, but, rather passes along what the customer gives it > to the > ISP and vice versa without interference. > > It differs from a bridge in that it terminates the collision and > broadcast domains > on either side of it. It differs from a bridge in that *it requires a chunk of routable IP space to put behind it*, and a route to go there. For the specific situation I posited, a consumer connection, you can get a static IP, but you *will not* get routable space; you have to go to a business connection for that, at 2-4 times the cost. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From khelms at ispalliance.net Fri Aug 5 10:13:38 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 05 Aug 2011 11:13:38 -0400 Subject: FTTH CPE landscape In-Reply-To: <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: <4E3C08A2.8080302@ispalliance.net> > You say waste, I say perfectly valid use. Its waste to carve out of that many subnets without a good reason (and no the reason presented so far are NOT compelling, IPSEC works perfectly over a bridged interface). > >> If you're dealing with business customers, then your usage versus wasted >> ratio is much higher and less of a concern, but what's the point? Are you >> trying to cut down on a large broadcast domain? >> > Why is it less of a waste to allocate a /30 to a business using a single public > IP than it is to a residence? This makes no sense to me. > > I simply prefer the additional troubleshooting and other capabilities given > to me in a routed environment in most cases. If you want that then you need to run a router not have a /30 routed over your WAN interface. Its far better for your WAN interface to be part of a much larger subnet that we can in turn route a network to. > > Owen > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at ispalliance.net Fri Aug 5 10:17:47 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 05 Aug 2011 11:17:47 -0400 Subject: FTTH CPE landscape In-Reply-To: References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> Message-ID: <4E3C099B.6010404@ispalliance.net> On 8/4/2011 8:22 PM, Owen DeLong wrote: > Among the people I know, on the order of 35%. > > Not a majority, but, I would not call 1/3rd less than 1%. > Again, you're not in any way shape or form representative. IPSEC IS less than 1% for residential Internet customers in the US and its not even 30% for business accounts. I have visibility into access networks around North America which gives me a sample size that is far larger than required for statistical significance. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Fri Aug 5 10:35:46 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Aug 2011 11:35:46 -0400 (EDT) Subject: FTTH CPE landscape In-Reply-To: <4E3C099B.6010404@ispalliance.net> Message-ID: <3176485.579.1312558546103.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Again, you're not in any way shape or form representative. IPSEC IS > less than 1% for residential Internet customers in the US and its not > even 30% for business accounts. I have visibility into access networks > around North America which gives me a sample size that is far larger > than required for statistical significance. Which is fine, but it does *not* justify not putting the check on the tick-list. You merely assign it a lower weight. "Whether to do it" is a cost-benefit analysis. "Not checking to see if you can have it for free" is malpractice. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From paul4004 at gmail.com Fri Aug 5 11:11:27 2011 From: paul4004 at gmail.com (PC) Date: Fri, 5 Aug 2011 10:11:27 -0600 Subject: FTTH CPE landscape In-Reply-To: <3176485.579.1312558546103.JavaMail.root@benjamin.baylink.com> References: <4E3C099B.6010404@ispalliance.net> <3176485.579.1312558546103.JavaMail.root@benjamin.baylink.com> Message-ID: There continue to be many legitimate reasons why a consumer might not want NAT on their connection. I wouldn't' consider IPSEC the primary one, as even having one side under NAT is generally not an issue in most cases if it's the initiator (further skewing your netflow statistics to even less than the 1% figure as a business case). You've explicitly asked for a CPE without wifi (or one where the SP can disable it). Yes, I know you could buy a wireless "access point", but no consumer will do that. They will run to best buy and come home with a "wireless router". They when they want a "public" IP on _their_ router they will (try) to follow all the guides on xbox.com/slingbox.com/torrentsite.com/ that advise how to bridge the Provider's CPE and run DHCP/PPPOE/L2TP/whatever on their linksys home router. They won't be able to do this with your service. In turn two levels of NAT will break all sorts of stuff, including stuff UPNP commonly handles today, only resolvable via a CPE that can bridge. Stuff far more common than IPSEC. Most other prominent access technologies supports bridging (ADSL, Cable, etc.), it probably wouldn't be too much effort to have a tick box to do the same for your consumer, consider bridging is typically supported in the bottom of the CPE barrel. On Fri, Aug 5, 2011 at 9:35 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > Again, you're not in any way shape or form representative. IPSEC IS > > less than 1% for residential Internet customers in the US and its not > > even 30% for business accounts. I have visibility into access networks > > around North America which gives me a sample size that is far larger > > than required for statistical significance. > > Which is fine, but it does *not* justify not putting the check on the > tick-list. You merely assign it a lower weight. "Whether to do it" is > a cost-benefit analysis. "Not checking to see if you can have it for free" > is malpractice. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > From bmengel at gmail.com Fri Aug 5 11:17:48 2011 From: bmengel at gmail.com (Brian Mengel) Date: Fri, 5 Aug 2011 12:17:48 -0400 Subject: IPv6 end user addressing Message-ID: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? From swmike at swm.pp.se Fri Aug 5 11:29:52 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 5 Aug 2011 18:29:52 +0200 (CEST) Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: On Fri, 5 Aug 2011, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home. > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik. > Does anyone have opinions on the BCP for end user addressing in IPv6? Yes, there are plenty of people with opinions. This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works. -- Mikael Abrahamsson email: swmike at swm.pp.se From Valdis.Kletnieks at vt.edu Fri Aug 5 11:38:16 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 Aug 2011 12:38:16 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Fri, 05 Aug 2011 12:17:48 EDT." References: Message-ID: <11591.1312562296@turing-police.cc.vt.edu> On Fri, 05 Aug 2011 12:17:48 EDT, Brian Mengel said: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. Basically, the thinking was a /56 is still "cheap" as far as allocating space, so if you need more than a /64, might as well go to /56 and avoid the mess if a user needs a 17th subnet. This isn't IPv4, where you have to actually worry about burning through your IP allocation doling it out to customers. Even a single /32 will service a *lot* of /56's, and I don't think *anybody* is big enough to actually burn through a /24 allocation (feel free to prove me wrong.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bruns at 2mbit.com Fri Aug 5 11:56:25 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 05 Aug 2011 10:56:25 -0600 Subject: IPv6 end user addressing In-Reply-To: <11591.1312562296@turing-police.cc.vt.edu> References: <11591.1312562296@turing-police.cc.vt.edu> Message-ID: <4E3C20B9.9050809@2mbit.com> On 8/5/11 10:38 AM, Valdis.Kletnieks at vt.edu wrote: > and I don't think*anybody* is big > enough to actually burn through a /24 allocation (feel free to prove me wrong.. > ;) Never doubt the ability of certain Asian countries to burn through IP space at blistering speed when their citizens can't even directly access the internet without going through a massive firewall and proxy system. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From owen at delong.com Fri Aug 5 12:06:38 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 10:06:38 -0700 Subject: FTTH CPE landscape In-Reply-To: <11022682.565.1312553441324.JavaMail.root@benjamin.baylink.com> References: <11022682.565.1312553441324.JavaMail.root@benjamin.baylink.com> Message-ID: <7686BB11-BC3C-4D06-B384-0709EC7E8D1D@delong.com> On Aug 5, 2011, at 7:10 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > > >> A transparent router (sorry, poor choice of terminology on my part) is >> a router >> which doesn't NAT or become selectively opaque (firewall). In other >> words, >> it forwards packets and it doesn't do any other arbitrary things to >> them at the >> whim of the ISP, but, rather passes along what the customer gives it >> to the >> ISP and vice versa without interference. >> >> It differs from a bridge in that it terminates the collision and >> broadcast domains >> on either side of it. > > It differs from a bridge in that *it requires a chunk of routable IP space > to put behind it*, and a route to go there. For the specific situation > I posited, a consumer connection, you can get a static IP, but you *will > not* get routable space; you have to go to a business connection for that, > at 2-4 times the cost. > That really depends on the ISP, doesn't it? Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From snow at teardrop.org Fri Aug 5 12:13:02 2011 From: snow at teardrop.org (James Snow) Date: Fri, 5 Aug 2011 10:13:02 -0700 Subject: RoadRunner contact? Message-ID: <20110805171301.GB92283@teardrop.org> Pardon the noise. Would greatly appreciate it if someone from RoadRunner could contact me off-list. It's regarding one of the RBL's you use. Thanks, -Snow From bhmccie at gmail.com Fri Aug 5 12:14:06 2011 From: bhmccie at gmail.com (Wile E. Coyote) Date: Fri, 05 Aug 2011 12:14:06 -0500 Subject: RoadRunner contact? In-Reply-To: <20110805171301.GB92283@teardrop.org> References: <20110805171301.GB92283@teardrop.org> Message-ID: <4E3C24DE.5040204@gmail.com> I too would like to have words with this individual... W.E. On 08/05/2011 12:13 PM, James Snow wrote: > Pardon the noise. Would greatly appreciate it if someone from RoadRunner > could contact me off-list. It's regarding one of the RBL's you use. > > Thanks, > > > -Snow > > > From owen at delong.com Fri Aug 5 12:16:47 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 10:16:47 -0700 Subject: FTTH CPE landscape In-Reply-To: <4E3C08A2.8080302@ispalliance.net> References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> <4E3C08A2.8080302@ispalliance.net> Message-ID: On Aug 5, 2011, at 8:13 AM, Scott Helms wrote: > >> You say waste, I say perfectly valid use. > > Its waste to carve out of that many subnets without a good reason (and no the reason presented so far are NOT compelling, IPSEC works perfectly over a bridged interface). >> >>> If you're dealing with business customers, then your usage versus wasted >>> ratio is much higher and less of a concern, but what's the point? Are you >>> trying to cut down on a large broadcast domain? >>> >> Why is it less of a waste to allocate a /30 to a business using a single public >> IP than it is to a residence? This makes no sense to me. >> >> I simply prefer the additional troubleshooting and other capabilities given >> to me in a routed environment in most cases. > If you want that then you need to run a router not have a /30 routed over your WAN interface. Its far better for your WAN interface to be part of a much larger subnet that we can in turn route a network to. I was speaking from the service provider perspective. If I deploy CPE to a customer, I want it to be a router, not a bridge. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Fri Aug 5 12:20:45 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 10:20:45 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> /56 is definitely preferable to /64, but, /48 really is a better choice. /56 is very limiting for autonomous hierarchical deployments. It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically. Owen On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. > > Does anyone have opinions on the BCP for end user addressing in IPv6? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Fri Aug 5 12:22:53 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 10:22:53 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <959BF91F-C017-40DC-81DE-89A223DBD374@delong.com> On Aug 5, 2011, at 9:29 AM, Mikael Abrahamsson wrote: > On Fri, 5 Aug 2011, Brian Mengel wrote: > >> In reviewing IPv6 end user allocation policies, I can find little >> agreement on what prefix length is appropriate for residential end >> users. /64 and /56 seem to be the favorite candidates, with /56 being >> slightly preferred. > > Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home. > I would say /56 is slightly preferred and that /48 is very much preferred. >> I am most curious as to why a /60 prefix is not considered when trying >> to address this problem. It provides 16 /64 subnetworks, which seems >> like an adequate amount for an end user. > > Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik. > All RIRs allow /48s actually. Some policies measure in increments of /56, BUT, even those policies consider issuing a customer a /48 to be a valid use of 256 /56s for measurement purposes. >> Does anyone have opinions on the BCP for end user addressing in IPv6? > > Yes, there are plenty of people with opinions. > > This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works. > If you really want to do it right, go for /48? It works better. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From khelms at ispalliance.net Fri Aug 5 12:27:38 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 05 Aug 2011 13:27:38 -0400 Subject: FTTH CPE landscape In-Reply-To: References: <28518052.523.1312492108772.JavaMail.root@benjamin.baylink.com> <947A1ADA-8ED6-4484-9E53-7E8110F28792@delong.com> <20110804215535.GA4756@dan.olp.net> <6EC94BAF-4EE0-4C1C-A44B-E3D51631B870@delong.com> <4E3C08A2.8080302@ispalliance.net> Message-ID: <4E3C280A.5090501@ispalliance.net> > I was speaking from the service provider perspective. If I deploy CPE to a customer, I want it to be a router, not a bridge. > > Owen > Why? What is/are the technical or marketing reason(s) that make you want to deploy routers over bridges knowing that they are more expensive? For what kinds of customers? What kinds of access networks? How much do you want to spend on CPE gear? How much remote manageability? How much customer manageability? What about mass firmware upgrades, diagnostics, and other OSS functions? (AFAIK the only standards based option for management behind a router is TR-069). -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Fri Aug 5 12:47:18 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 5 Aug 2011 13:47:18 -0400 (EDT) Subject: FTTH CPE landscape In-Reply-To: <7686BB11-BC3C-4D06-B384-0709EC7E8D1D@delong.com> Message-ID: <4243442.587.1312566438538.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > > It differs from a bridge in that *it requires a chunk of routable IP space > > to put behind it*, and a route to go there. For the specific situation > > I posited, a consumer connection, you can get a static IP, but you *will > > not* get routable space; you have to go to a business connection for > > that, at 2-4 times the cost. > > That really depends on the ISP, doesn't it? Sure. If you'd prefer, substitute "large, consumer ISP -- on the order of Verizon DSL or Road Runner". Both of those have told me that in the past, and, these days, I don't think they're unrepresentative of the common case. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From Valdis.Kletnieks at vt.edu Fri Aug 5 12:58:01 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 Aug 2011 13:58:01 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Fri, 05 Aug 2011 10:56:25 MDT." <4E3C20B9.9050809@2mbit.com> References: <11591.1312562296@turing-police.cc.vt.edu> <4E3C20B9.9050809@2mbit.com> Message-ID: <14932.1312567081@turing-police.cc.vt.edu> On Fri, 05 Aug 2011 10:56:25 MDT, Brielle Bruns said: > On 8/5/11 10:38 AM, Valdis.Kletnieks at vt.edu wrote: > > and I don't think*anybody* is big > > enough to actually burn through a /24 allocation (feel free to prove me wrong.. > > ;) > > Never doubt the ability of certain Asian countries to burn through IP > space at blistering speed when their citizens can't even directly access > the internet without going through a massive firewall and proxy system. :) Those cases are probably best handled as a /16 delegation from a regional RIR to a national RIR or similar. And they can just ULA themselves a /16 for inside the country if they really feel the need ;) And yes, I know a single /24 won't quite cover all of Comcast's customers if they give them all a /48. They're welcome to prove me wrong by turning up enough customers on IPv6 to need a second /24. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Fri Aug 5 12:59:41 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Aug 2011 10:59:41 -0700 Subject: FTTH CPE landscape In-Reply-To: <4243442.587.1312566438538.JavaMail.root@benjamin.baylink.com> References: <4243442.587.1312566438538.JavaMail.root@benjamin.baylink.com> Message-ID: <88B3955E-C6F2-418F-9246-1DE73985B198@delong.com> On Aug 5, 2011, at 10:47 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >>> It differs from a bridge in that *it requires a chunk of routable IP space >>> to put behind it*, and a route to go there. For the specific situation >>> I posited, a consumer connection, you can get a static IP, but you *will >>> not* get routable space; you have to go to a business connection for >>> that, at 2-4 times the cost. >> >> That really depends on the ISP, doesn't it? > > Sure. If you'd prefer, substitute "large, consumer ISP -- on the order of > Verizon DSL or Road Runner". Both of those have told me that in the past, > and, these days, I don't think they're unrepresentative of the common case. > Sure, but, there's more than one way to solve the problem. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From EWieling at nyigc.com Fri Aug 5 13:04:26 2011 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 5 Aug 2011 14:04:26 -0400 Subject: FTTH CPE landscape In-Reply-To: <4243442.587.1312566438538.JavaMail.root@benjamin.baylink.com> References: <7686BB11-BC3C-4D06-B384-0709EC7E8D1D@delong.com> <4243442.587.1312566438538.JavaMail.root@benjamin.baylink.com> Message-ID: > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Friday, August 05, 2011 1:47 PM > To: NANOG > Subject: Re: FTTH CPE landscape > > ----- Original Message ----- > > From: "Owen DeLong" > > > > It differs from a bridge in that *it requires a chunk of routable IP > > > space to put behind it*, and a route to go there. For the specific > > > situation I posited, a consumer connection, you can get a static IP, > > > but you *will > > > not* get routable space; you have to go to a business connection for > > > that, at 2-4 times the cost. > > > > That really depends on the ISP, doesn't it? > > Sure. If you'd prefer, substitute "large, consumer ISP -- on the order of > Verizon DSL or Road Runner". Both of those have told me that in the past, > and, these days, I don't think they're unrepresentative of the common case. Knology DOCSIS (residential) here in Huntsville uses a bridged CPE, Arris brand. I like that, as I can use my own router and handle any NAT if I want. From cscora at apnic.net Fri Aug 5 14:06:24 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Aug 2011 05:06:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201108051906.p75J6O9f018683@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Aug, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 366101 Prefixes after maximum aggregation: 165963 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 181822 Total ASes present in the Internet Routing Table: 38388 Prefixes per ASN: 9.54 Origin-only ASes present in the Internet Routing Table: 31868 Origin ASes announcing only one prefix: 15337 Transit ASes present in the Internet Routing Table: 5220 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (22394) 31 Prefixes from unregistered ASNs in the Routing Table: 1040 Unregistered ASNs in the Routing Table: 593 Number of 32-bit ASNs allocated by the RIRs: 1620 Number of 32-bit ASNs visible in the Routing Table: 1300 Prefixes from 32-bit ASNs in the Routing Table: 3022 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 120 Number of addresses announced to Internet: 2489833856 Equivalent to 148 /8s, 103 /16s and 217 /24s Percentage of available address space announced: 67.2 Percentage of allocated address space announced: 67.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.2 Total number of prefixes smaller than registry allocations: 152918 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 91398 Total APNIC prefixes after maximum aggregation: 30293 APNIC Deaggregation factor: 3.02 Prefixes being announced from the APNIC address blocks: 87871 Unique aggregates announced from the APNIC address blocks: 37679 APNIC Region origin ASes present in the Internet Routing Table: 4531 APNIC Prefixes per ASN: 19.39 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 715 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 69 Number of APNIC addresses announced to Internet: 623300640 Equivalent to 37 /8s, 38 /16s and 208 /24s Percentage of available APNIC address space announced: 79.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 141963 Total ARIN prefixes after maximum aggregation: 73199 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 113809 Unique aggregates announced from the ARIN address blocks: 46854 ARIN Region origin ASes present in the Internet Routing Table: 14537 ARIN Prefixes per ASN: 7.83 ARIN Region origin ASes announcing only one prefix: 5583 ARIN Region transit ASes present in the Internet Routing Table: 1538 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 34 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 803328640 Equivalent to 47 /8s, 225 /16s and 210 /24s Percentage of available ARIN address space announced: 63.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 87286 Total RIPE prefixes after maximum aggregation: 49562 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 80544 Unique aggregates announced from the RIPE address blocks: 53233 RIPE Region origin ASes present in the Internet Routing Table: 15857 RIPE Prefixes per ASN: 5.08 RIPE Region origin ASes announcing only one prefix: 7913 RIPE Region transit ASes present in the Internet Routing Table: 2508 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 934 Number of RIPE addresses announced to Internet: 484720448 Equivalent to 28 /8s, 228 /16s and 63 /24s Percentage of available RIPE address space announced: 78.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 33995 Total LACNIC prefixes after maximum aggregation: 7596 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 33197 Unique aggregates announced from the LACNIC address blocks: 17229 LACNIC Region origin ASes present in the Internet Routing Table: 1490 LACNIC Prefixes per ASN: 22.28 LACNIC Region origin ASes announcing only one prefix: 441 LACNIC Region transit ASes present in the Internet Routing Table: 280 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 281 Number of LACNIC addresses announced to Internet: 87399680 Equivalent to 5 /8s, 53 /16s and 157 /24s Percentage of available LACNIC address space announced: 57.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8269 Total AfriNIC prefixes after maximum aggregation: 1986 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6558 Unique aggregates announced from the AfriNIC address blocks: 2029 AfriNIC Region origin ASes present in the Internet Routing Table: 483 AfriNIC Prefixes per ASN: 13.58 AfriNIC Region origin ASes announcing only one prefix: 155 AfriNIC Region transit ASes present in the Internet Routing Table: 105 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 26905344 Equivalent to 1 /8s, 154 /16s and 139 /24s Percentage of available AfriNIC address space announced: 40.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2491 11045 947 Korea Telecom (KIX) 17974 1784 516 31 PT TELEKOMUNIKASI INDONESIA 7545 1560 301 85 TPG Internet Pty Ltd 4755 1522 635 170 TATA Communications formerly 24560 1196 336 187 Bharti Airtel Ltd., Telemedia 9829 1114 929 42 BSNL National Internet Backbo 9583 1070 78 491 Sify Limited 4808 1056 2097 300 CNCGROUP IP network: China169 7552 999 1062 11 Vietel Corporation 17488 980 188 123 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3586 3817 231 bellsouth.net, inc. 18566 1913 365 240 Covad Communications 1785 1814 681 121 PaeTec Communications, Inc. 4323 1616 1082 400 Time Warner Telecom 7029 1605 993 230 Windstream Communications Inc 20115 1591 1538 623 Charter Communications 19262 1413 4792 392 Verizon Global Networks 22773 1405 2900 90 Cox Communications, Inc. 7018 1359 7052 888 AT&T WorldNet Services 2386 1253 520 903 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 534 106 185 BILISIM TELEKOM 6830 511 1788 316 UPC Distribution Services 3292 470 2080 405 TDC Tele Danmark 20940 470 134 363 Akamai Technologies European 12479 455 593 7 Uni2 Autonomous System 8866 454 133 26 Bulgarian Telecommunication C 29049 434 32 52 AzerSat LLC. 3320 424 8151 370 Deutsche Telekom AG 8551 404 354 44 Bezeq International 3301 397 1855 346 TeliaNet Sweden Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1565 289 163 TVCABLE BOGOTA 8151 1424 2766 352 UniNet S.A. de C.V. 28573 1278 996 67 NET Servicos de Comunicao S.A 7303 1067 578 175 Telecom Argentina Stet-France 6503 767 450 78 AVANTEL, S.A. 14420 703 56 84 CORPORACION NACIONAL DE TELEC 22047 578 322 17 VTR PUNTO NET S.A. 3816 531 232 97 Empresa Nacional de Telecomun 7738 516 986 31 Telecomunicacoes da Bahia S.A 11172 513 85 90 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 803 147 42 LINKdotNET AS number 8452 799 445 11 TEDATA 15475 512 74 8 Nile Online 36992 306 415 14 Etisalat MISR 3741 265 937 226 The Internet Solution 6713 260 519 14 Itissalat Al-MAGHRIB 15706 230 32 6 Sudatel Internet Exchange Aut 33776 229 13 8 Starcomms Nigeria Limited 24835 176 78 10 RAYA Telecom - Egypt 29571 158 17 11 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3586 3817 231 bellsouth.net, inc. 23456 3022 728 1620 32-bit ASN transition 4766 2491 11045 947 Korea Telecom (KIX) 18566 1913 365 240 Covad Communications 1785 1814 681 121 PaeTec Communications, Inc. 17974 1784 516 31 PT TELEKOMUNIKASI INDONESIA 4323 1616 1082 400 Time Warner Telecom 7029 1605 993 230 Windstream Communications Inc 20115 1591 1538 623 Charter Communications 10620 1565 289 163 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 1784 1753 PT TELEKOMUNIKASI INDONESIA 1785 1814 1693 PaeTec Communications, Inc. 18566 1913 1673 Covad Communications 4766 2491 1544 Korea Telecom (KIX) 7545 1560 1475 TPG Internet Pty Ltd 23456 3022 1402 32-bit ASN transition 10620 1565 1402 TVCABLE BOGOTA 7029 1605 1375 Windstream Communications Inc 4755 1522 1352 TATA Communications formerly 22773 1405 1315 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.192.96.0/21 44611 RIPE Network Coordination Cen 31.209.136.0/21 51896 Hestaleit ehf 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:12 /10:27 /11:80 /12:233 /13:465 /14:800 /15:1410 /16:12052 /17:5906 /18:9911 /19:19523 /20:26343 /21:26393 /22:34986 /23:34062 /24:190548 /25:1096 /26:1285 /27:731 /28:201 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2214 3586 bellsouth.net, inc. 18566 1869 1913 Covad Communications 23456 1485 3022 32-bit ASN transition 10620 1460 1565 TVCABLE BOGOTA 7029 1304 1605 Windstream Communications Inc 11492 1096 1142 Cable One 7011 1058 1160 Citizens Utilities 1785 1053 1814 PaeTec Communications, Inc. 6478 932 960 AT&T Worldnet Services 22773 904 1405 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:348 2:46 4:15 5:1 6:3 8:339 12:1960 13:1 14:502 15:15 16:3 17:5 20:10 23:19 24:1677 27:863 31:517 32:64 33:4 34:2 36:4 38:727 40:106 41:2573 42:37 44:3 46:1071 47:3 49:202 50:384 52:13 54:2 55:4 56:2 57:35 58:865 59:492 60:378 61:1171 62:1056 63:1931 64:3996 65:2298 66:3908 67:1887 68:1099 69:3034 70:774 71:373 72:1866 74:2427 75:329 76:339 77:861 78:705 79:475 80:1124 81:839 82:504 83:465 84:683 85:1066 86:517 87:836 88:334 89:1537 90:224 91:4001 92:525 93:1121 94:1332 95:868 96:420 97:264 98:920 99:37 101:85 103:186 106:79 107:30 108:71 109:1040 110:613 111:722 112:307 113:406 114:559 115:676 116:993 117:668 118:864 119:1182 120:210 121:680 122:1613 123:991 124:1372 125:1289 128:246 129:171 130:171 131:575 132:102 133:21 134:214 135:52 136:215 137:138 138:296 139:115 140:483 141:270 142:380 143:422 144:488 145:57 146:455 147:213 148:682 149:252 150:156 151:190 152:347 153:182 154:5 155:400 156:199 157:355 158:139 159:457 160:319 161:206 162:310 163:163 164:513 165:366 166:532 167:432 168:738 169:153 170:841 171:81 172:1 173:1627 174:619 175:393 176:147 177:195 178:1014 180:917 181:26 182:508 183:237 184:361 185:1 186:1348 187:751 188:913 189:972 190:5086 192:5923 193:4980 194:3511 195:3063 196:1199 197:112 198:3590 199:4015 200:5529 201:1476 202:8426 203:8462 204:4253 205:2317 206:2670 207:2803 208:3994 209:3408 210:2710 211:1410 212:2088 213:1754 214:800 215:70 216:4896 217:1629 218:530 219:348 220:1203 221:485 222:360 223:239 End of report From dougb at dougbarton.us Fri Aug 5 14:18:28 2011 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 05 Aug 2011 12:18:28 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <4E3C4204.4020902@dougbarton.us> On 08/05/2011 09:17, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. > > Does anyone have opinions on the BCP for end user addressing in IPv6? You've had a lot of good opinions already, but here's one more vote for /56 being the absolute minimum. That said, the strategy I've suggested in the past is to reserve for each customer the largest block that your RIR will recognize as reasonable (note, that's reasonable, not theoretically justifiable) for end user assignment. Then if down the road it turns out that you need more space and for some unimaginable reason you can't get more from the RIR you can go back and start bifurcating the blocks you've reserved. For example, if you reserve a /48 per customer but actually use the first /56 out of it, you are safe if _you_ need the other /56 for some reason, or if the customer needs to expand into the full /48. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From cidr-report at potaroo.net Fri Aug 5 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Aug 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201108052200.p75M01qS008847@wattle.apnic.net> BGP Update Report Interval: 28-Jul-11 -to- 04-Aug-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45899 90492 5.6% 323.2 -- VNPT-AS-VN VNPT Corp 2 - AS9829 59250 3.7% 59.7 -- BSNL-NIB National Internet Backbone 3 - AS4755 29848 1.9% 31.9 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 4 - AS17974 26006 1.6% 15.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS35819 24471 1.5% 86.8 -- MOBILY-AS Etihad Etisalat Company (Mobily) 6 - AS6316 18418 1.1% 184.2 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - AS38511 16832 1.0% 271.5 -- TACHYON-AS-ID PT Remala Abadi 8 - AS38040 15476 1.0% 1289.7 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 9 - AS7552 14765 0.9% 10.5 -- VIETEL-AS-AP Vietel Corporation 10 - AS9498 13830 0.9% 16.6 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS24863 10041 0.6% 13.9 -- LINKdotNET-AS 12 - AS28573 9955 0.6% 7.2 -- NET Servicos de Comunicao S.A. 13 - AS9534 9876 0.6% 167.4 -- MAXIS-AS1-AP Binariang Berhad 14 - AS45528 9842 0.6% 30.9 -- TDN Tikona Digital Networks Pvt Ltd. 15 - AS45595 9042 0.6% 25.1 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS8452 9012 0.6% 14.2 -- TE-AS TE-AS 17 - AS36958 8887 0.6% 202.0 -- Atlas-AS 18 - AS8151 8450 0.5% 9.8 -- Uninet S.A. de C.V. 19 - AS5976 8292 0.5% 76.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS17726 8119 0.5% 541.3 -- CAMNET-AS CAMNET is an ISP of Ministry of Posts TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44609 7579 0.5% 2526.3 -- FNA Fars News Agency Cultural Arts Institute 2 - AS22793 1974 0.1% 1974.0 -- CASSOCORP - CASSO Corporation 3 - AS7586 1815 0.1% 1815.0 -- PDOX-AS-AP Paradox Digital Pty Ltd 4 - AS38040 15476 1.0% 1289.7 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 5 - AS17408 3707 0.2% 1235.7 -- ABOVE-AS-AP AboveNet Communications Taiwan 6 - AS3454 7582 0.5% 947.8 -- Universidad Autonoma de Nuevo Leon 7 - AS32528 5528 0.3% 921.3 -- ABBOTT Abbot Labs 8 - AS44145 574 0.0% 574.0 -- PRINTDESIGN-AS Print and Design LTD 9 - AS44025 562 0.0% 562.0 -- KAMTELEKOM-NET Kamtelekom Ltd. 10 - AS17726 8119 0.5% 541.3 -- CAMNET-AS CAMNET is an ISP of Ministry of Posts 11 - AS32323 517 0.0% 517.0 -- EQUINIX-EDMA-CHI-ASN - Equinix, Inc. 12 - AS49987 414 0.0% 414.0 -- SPARK-AS Stroy Park - R Ltd 13 - AS8491 1487 0.1% 371.8 -- BSH-AS Business Sviaz Inc. 14 - AS38518 4955 0.3% 353.9 -- LINTASWAVENET-AS-ID Lintas Wave Network Solution, PT. 15 - AS12170 346 0.0% 346.0 -- PENTELOFAMERICA - Pentel of America, LTD. 16 - AS9476 340 0.0% 340.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 17 - AS45899 90492 5.6% 323.2 -- VNPT-AS-VN VNPT Corp 18 - AS38528 320 0.0% 320.0 -- LANIC-AS-AP Lao National Internet Committee 19 - AS55764 319 0.0% 319.0 -- HGSL-IN HGSL House, No.614, 20 - AS38167 2731 0.2% 303.4 -- ANITTEL-AS-AP Anittel Communications Pty Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 9235 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 200.23.202.0/24 7561 0.4% AS3454 -- Universidad Autonoma de Nuevo Leon 3 - 178.22.72.0/21 7444 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 4 - 66.248.104.0/21 6805 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - 180.180.248.0/24 6517 0.4% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 6 - 66.248.120.0/21 5943 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 66.248.96.0/21 5442 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 202.54.86.0/24 4876 0.3% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 9 - 202.153.174.0/24 3703 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 10 - 180.180.253.0/24 2978 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 180.180.255.0/24 2974 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 12 - 130.36.34.0/24 2744 0.2% AS32528 -- ABBOTT Abbot Labs 13 - 130.36.35.0/24 2744 0.2% AS32528 -- ABBOTT Abbot Labs 14 - 202.41.70.0/24 2704 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 15 - 123.17.240.0/20 2293 0.1% AS45899 -- VNPT-AS-VN VNPT Corp 16 - 123.17.160.0/20 2292 0.1% AS45899 -- VNPT-AS-VN VNPT Corp 17 - 123.18.160.0/19 2292 0.1% AS45899 -- VNPT-AS-VN VNPT Corp 18 - 123.18.224.0/19 2290 0.1% AS45899 -- VNPT-AS-VN VNPT Corp 19 - 123.18.96.0/19 2290 0.1% AS45899 -- VNPT-AS-VN VNPT Corp 20 - 123.18.128.0/19 2290 0.1% AS45899 -- VNPT-AS-VN VNPT Corp Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Aug 5 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Aug 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201108052200.p75M00Qt008842@wattle.apnic.net> This report has been generated at Fri Aug 5 21:12:16 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 29-07-11 368779 217283 30-07-11 368982 217262 31-07-11 368911 216969 01-08-11 368488 217255 02-08-11 368988 217372 03-08-11 369110 217985 04-08-11 369304 217608 05-08-11 369556 217469 AS Summary 38507 Number of ASes in routing system 16232 Number of ASes announcing only one prefix 3584 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109748448 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 05Aug11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 369593 217561 152032 41.1% All ASes AS6389 3584 235 3349 93.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2491 966 1525 61.2% KIXS-AS-KR Korea Telecom AS18566 1913 496 1417 74.1% COVAD - Covad Communications Co. AS4755 1518 190 1328 87.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1405 99 1306 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4323 1617 402 1215 75.1% TWTC - tw telecom holdings, inc. AS1785 1818 768 1050 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1413 392 1021 72.3% VZGNI-TRANSIT - Verizon Online LLC AS10620 1565 624 941 60.1% Telmex Colombia S.A. AS28573 1278 389 889 69.6% NET Servicos de Comunicao S.A. AS24560 1196 319 877 73.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7552 999 148 851 85.2% VIETEL-AS-AP Vietel Corporation AS7545 1560 713 847 54.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 934 146 788 84.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7303 1067 317 750 70.3% Telecom Argentina S.A. AS8151 1434 686 748 52.2% Uninet S.A. de C.V. AS4808 1059 335 724 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1117 458 659 59.0% LEVEL3 Level 3 Communications AS17488 980 348 632 64.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS14420 703 88 615 87.5% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS20115 1591 981 610 38.3% CHARTER-NET-HKY-NC - Charter Communications AS22561 966 365 601 62.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 668 71 597 89.4% GIGAINFRA Softbank BB Corp. AS3549 997 426 571 57.3% GBLX Global Crossing Ltd. AS4804 642 86 556 86.6% MPX-AS Microplex PTY LTD AS4780 775 229 546 70.5% SEEDNET Digital United Inc. AS22047 578 32 546 94.5% VTR BANDA ANCHA S.A. AS17974 1784 1240 544 30.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7011 1160 624 536 46.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS9443 570 78 492 86.3% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 39382 12251 27131 68.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 31.192.96.0/21 AS44611 TALKINTERNET Talk Internet 31.209.136.0/21 AS51896 HRINGDU-AS Hringdu ehf 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.17.128.0/19 AS51896 HRINGDU-AS Hringdu ehf 93.180.88.0/21 AS42410 PTP-AS Point To Point Ltd. AS 103.22.96.0/22 AS55641 PENCENT Shenzhen Pencent Communication Technology Co.,ltd. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 116.193.152.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.153.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.154.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.193.155.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 191.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 193.111.87.0/24 AS24812 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.63.80.0/24 AS9557 PKTELECOM-AS-PK Paknet Limited Merged into PTCL 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From frnkblk at iname.com Fri Aug 5 17:56:18 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 5 Aug 2011 17:56:18 -0500 Subject: IPv6 end user addressing In-Reply-To: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> Message-ID: <005f01cc53c2$e52b4200$af81c600$@iname.com> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be zeroing in on a /56 for production. Though some ISPs are using /64 for their trials. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, August 05, 2011 12:21 PM To: Brian Mengel Cc: nanog at nanog.org Subject: Re: IPv6 end user addressing /56 is definitely preferable to /64, but, /48 really is a better choice. /56 is very limiting for autonomous hierarchical deployments. It's not about number of subnets. It's about the ability to provide some flexibility in the breadth and depth of bit fields used for creating hierarchical topologies automatically. Owen On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. > > Does anyone have opinions on the BCP for end user addressing in IPv6? From Bino.Gopal at citrix.com Fri Aug 5 19:04:51 2011 From: Bino.Gopal at citrix.com (Bino Gopal) Date: Fri, 5 Aug 2011 17:04:51 -0700 Subject: US internet providers hijacking users' search queries Message-ID: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html Thoughts? From mpalmer at hezmatt.org Fri Aug 5 19:45:49 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 6 Aug 2011 10:45:49 +1000 Subject: US internet providers hijacking users' search queries In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> Message-ID: <20110806004549.GD2510@hezmatt.org> On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: > http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html I hope more ISPs start doing this; it'll increase the take up of HTTPS. - Matt -- Part[s] of .us are the global benchmark for pumpkin being a verb. -- Anthony de Boer From tony at pardini.org Fri Aug 5 19:47:48 2011 From: tony at pardini.org (Anthony Pardini) Date: Fri, 5 Aug 2011 19:47:48 -0500 Subject: US internet providers hijacking users' search queries Message-ID: Not surprising.. Ten years ago a vender pitched inserting referral cookies when customers visted shopping sites. We ultimately convinced management that collecting comissions in this manner wasn't the best of ideas. On Aug 5, 2011 7:05 PM, "Bino Gopal" wrote: From bruns at 2mbit.com Fri Aug 5 19:53:50 2011 From: bruns at 2mbit.com (Brielle) Date: Fri, 5 Aug 2011 18:53:50 -0600 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806004549.GD2510@hezmatt.org> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> Message-ID: <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> Until they start MitM the ssl traffic, fake certs and all. Didn't a certain repressive regime already do this tactic with facebook or some other major site? -- Brielle (sent from my iPhone) On Aug 5, 2011, at 6:45 PM, Matthew Palmer wrote: > On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: >> http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html > > I hope more ISPs start doing this; it'll increase the take up of HTTPS. > > - Matt > > > -- > Part[s] of .us are the global benchmark for pumpkin being a verb. > -- Anthony de Boer > > From Valdis.Kletnieks at vt.edu Fri Aug 5 19:59:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 Aug 2011 20:59:42 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: Your message of "Fri, 05 Aug 2011 17:04:51 PDT." <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> Message-ID: <34037.1312592382@turing-police.cc.vt.edu> On Fri, 05 Aug 2011 17:04:51 PDT, Bino Gopal said: > http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html > > Thoughts? You're new here, aren't you? ;) Anybody who was around when a certain DNS provider started providing a wildcard for *.com and *.net so they could funnel the web page hits to their redirector shouldn't be surprised. Unless they're surprised it took this long to make the news again. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From paul at paulgraydon.co.uk Fri Aug 5 20:00:24 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 05 Aug 2011 15:00:24 -1000 Subject: US internet providers hijacking users' search queries In-Reply-To: <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> Message-ID: <4E3C9228.4050808@paulgraydon.co.uk> On 08/05/2011 02:53 PM, Brielle wrote: > Until they start MitM the ssl traffic, fake certs and all. Didn't a certain repressive regime already do this tactic with facebook or some other major site? > Syria did: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook From marka at isc.org Fri Aug 5 20:03:36 2011 From: marka at isc.org (Mark Andrews) Date: Sat, 06 Aug 2011 11:03:36 +1000 Subject: US internet providers hijacking users' search queries In-Reply-To: Your message of "Fri, 05 Aug 2011 15:00:24 -1000." <4E3C9228.4050808@paulgraydon.co.uk> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> <4E3C9228.4050808@paulgraydon.co.uk> Message-ID: <20110806010336.825891284C3D@drugs.dv.isc.org> In message <4E3C9228.4050808 at paulgraydon.co.uk>, Paul Graydon writes: > On 08/05/2011 02:53 PM, Brielle wrote: > > Until they start MitM the ssl traffic, fake certs and all. Didn't a certai > n repressive regime already do this tactic with facebook or some other major > site? > > > Syria did: > https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook s://www.facebook.com/note.php?note_id=10150178983622358&comments> Which is countered by DNSSEC + DANE. A country may be able to fake everything under their tld but not the rest of the net. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeff-kell at utc.edu Fri Aug 5 20:08:34 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 5 Aug 2011 21:08:34 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> Message-ID: <4E3C9412.2090702@utc.edu> On 8/5/2011 8:53 PM, Brielle wrote: > Until they start MitM the ssl traffic, fake certs and all. Didn't a certain repressive regime already do this tactic with facebook or some other major site? > Marketscore did (via installing root certs in the victim's machines), and as far as I know, still does. Jeff From mysidia at gmail.com Fri Aug 5 20:10:07 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 5 Aug 2011 20:10:07 -0500 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806004549.GD2510@hezmatt.org> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> Message-ID: On Fri, Aug 5, 2011 at 7:45 PM, Matthew Palmer wrote: > On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: > > > http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html > I hope more ISPs start doing this; it'll increase the take up of HTTPS. > - Matt > I'd rather someone start making a blacklist of ISPs that "inspect and modify packets" in transit through their network in any way ( other than TTL decrementing ), so search engines could collectively identify these ISPs and choose to require _all_ connections from them be over SSL. You know what's going to happen. The regulators are going to get involved in response to things like this, with sufficient outcry from the public. Once ISPs show the industry can't be trusted to moderate itself, a new government body is likely to be formed for the sole purpose of passing as many arbitrary, arcane, bureaucratic, and otherwise burdensome rules ISPs will have to follow as possible. ISP's 'redirection' of certain search terms is proof that they have the full capability to block search terms, if it becomes widespread it would show that it's not unreasonable to demand ISPs intercept or block certain search queries. So eventually, there could be a government body saying what any ISP may do to search engine queries, and even mandating that ISPs do examine searches and block certain keywords or phrases.... -- -JH From nanog-post at rsuc.gweep.net Fri Aug 5 20:14:00 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 5 Aug 2011 21:14:00 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> Message-ID: <20110806011359.GA24602@gweep.net> On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: > http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html It is more than slightly misleading to say "hijacking search queries"; paxfire is evil as it hijacks dns and breaks NXDOMAIN and they've been doing that for ages. The user behavior of searching in the address bar has become more common place, and browser behavior to try and resolve first, fallback to search for the same input field has both trained the humans to keep doing this and made it possible for DNS query interlopers to appear to be generic-search interlopers. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From mpalmer at hezmatt.org Fri Aug 5 20:53:41 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 6 Aug 2011 11:53:41 +1000 Subject: US internet providers hijacking users' search queries In-Reply-To: <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> Message-ID: <20110806015341.GE2510@hezmatt.org> On Fri, Aug 05, 2011 at 06:53:50PM -0600, Brielle wrote: > Until they start MitM the ssl traffic, fake certs and all. Didn't a > certain repressive regime already do this tactic with facebook or some > other major site? Yes, there's plenty of rogue CAs. That's an easier problem to solve (though still difficult) than trying to stop traffic interception with plain HTTP. - Matt -- There's a term for those who fantasize that the world works in precisely the way that produces maximum convenience for them, despite years of evidence to the contrary. The term is "Morons". -- Greg Andrews, in the Monastery From lists at knotclan.com Fri Aug 5 21:17:17 2011 From: lists at knotclan.com (Bradford Chatterjee) Date: Fri, 5 Aug 2011 19:17:17 -0700 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> Message-ID: Search engines are the ones that are paying for this redirection. Most of the companies that approached us about this technology partner with Yahoo for their error monetization. They want the eyeballs that come from redirecting these mistyped URIs. -Bradford Chatterjee On Fri, Aug 5, 2011 at 6:10 PM, Jimmy Hess wrote: > > I'd rather someone start making a blacklist of ISPs that "inspect and > modify packets" in transit > through their network in any way ( other than TTL decrementing ), so > search engines could collectively > identify these ISPs and choose to require _all_ connections from them be > over SSL. > > From slz at baycix.de Sat Aug 6 02:47:00 2011 From: slz at baycix.de (Sascha Lenz) Date: Sat, 6 Aug 2011 09:47:00 +0200 Subject: IPv6 end user addressing In-Reply-To: <005f01cc53c2$e52b4200$af81c600$@iname.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> Message-ID: <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> Hi, > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be > zeroing in on a /56 for production. Though some ISPs are using /64 for > their trials. IIRC, there's RfC6177 - covering almost exactly what the original poster asked for. Not sure if it was mentioned already. /48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies, and there are close to zero reasons not to use a /48. It also eases your administration processes and also operational things. Of course, if you only have John Average residential customers or whatever, use a /56 or /60. It's your choice. You know your customers best. We're not in a classful world again :-) But do your math, there is no address shortage, handing out a /48 to every type of customer as a single assignment size should be the sane choice. You waste precious time thinking too much about it. At least don't make your life miserable by experimenting with too many different assignment sizes, or advocate /64s or something, that's considered a design fault which will come back to you some day. Read the RfCs and RIR policy discussions in the archives some years ago. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From owen at delong.com Sat Aug 6 04:06:46 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 02:06:46 -0700 Subject: IPv6 end user addressing In-Reply-To: <005f01cc53c2$e52b4200$af81c600$@iname.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> Message-ID: <5421066B-0F87-40C5-B1F9-1F46C0CF39D1@delong.com> I'm not the only person who prefers /48 and hopefully most ISPs will eventually come around and realize that /56s don't really benefit anyone vs. /48s. Hurricane Electric has been handing out /48s upon request to our customers and users of our IPv6 tunnel services. We do not anticipate changing that policy. Owen On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote: > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be > zeroing in on a /56 for production. Though some ISPs are using /64 for > their trials. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, August 05, 2011 12:21 PM > To: Brian Mengel > Cc: nanog at nanog.org > Subject: Re: IPv6 end user addressing > > /56 is definitely preferable to /64, but, /48 really is a better choice. > > /56 is very limiting for autonomous hierarchical deployments. > > It's not about number of subnets. It's about the ability to provide some > flexibility > in the breadth and depth of bit fields used for creating hierarchical > topologies > automatically. > > Owen > > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > >> In reviewing IPv6 end user allocation policies, I can find little >> agreement on what prefix length is appropriate for residential end >> users. /64 and /56 seem to be the favorite candidates, with /56 being >> slightly preferred. >> >> I am most curious as to why a /60 prefix is not considered when trying >> to address this problem. It provides 16 /64 subnetworks, which seems >> like an adequate amount for an end user. >> >> Does anyone have opinions on the BCP for end user addressing in IPv6? > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sat Aug 6 04:14:16 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 02:14:16 -0700 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806010336.825891284C3D@drugs.dv.isc.org> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> <4E3C9228.4050808@paulgraydon.co.uk> <20110806010336.825891284C3D@drugs.dv.isc.org> Message-ID: On Aug 5, 2011, at 6:03 PM, Mark Andrews wrote: > > In message <4E3C9228.4050808 at paulgraydon.co.uk>, Paul Graydon writes: >> On 08/05/2011 02:53 PM, Brielle wrote: >>> Until they start MitM the ssl traffic, fake certs and all. Didn't a certai >> n repressive regime already do this tactic with facebook or some other major >> site? >>> >> Syria did: >> https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook> s://www.facebook.com/note.php?note_id=10150178983622358&comments> > > Which is countered by DNSSEC + DANE. A country may be able to fake everything > under their tld but not the rest of the net. > Unless they start proxying all queries and putting their own trust anchors on all the results. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sat Aug 6 04:21:27 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 02:21:27 -0700 Subject: IPv6 end user addressing In-Reply-To: <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> Message-ID: <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> On Aug 6, 2011, at 12:47 AM, Sascha Lenz wrote: > Hi, > > >> Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be >> zeroing in on a /56 for production. Though some ISPs are using /64 for >> their trials. > > > IIRC, there's RfC6177 - covering almost exactly what the original poster asked for. > Not sure if it was mentioned already. > RFC6177 sort of appears to recommend /56 if you don't look at it too closely. What it really says is essentially "The IETF throws its hands up in the air and refuses to make any recommendations in this arena leaving the entire thing to RIRs and service providers where we probably should have put it in the first place." > /48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies, > and there are close to zero reasons not to use a /48. It also eases your administration > processes and also operational things. > AMEN, Brother! ;-) > Of course, if you only have John Average residential customers or whatever, use a /56 or /60. > It's your choice. You know your customers best. We're not in a classful world again :-) > But do your math, there is no address shortage, handing out a /48 to every type of customer > as a single assignment size should be the sane choice. > You waste precious time thinking too much about it. > Yep. Even if you only have John Average residential customer. Residential customers today are not going to be the same as residential customers in 5, 15, or 25 years. Giving them /48s will save you (and them) a lot of heartache down the road. (and yes, I mean a /48 per end site structure or per tenant in a multi-tenant structure). > At least don't make your life miserable by experimenting with too many different assignment sizes, > or advocate /64s or something, that's considered a design fault which will come back to you some day. > Read the RfCs and RIR policy discussions in the archives some years ago. > Also, please don't make your life miserable by trying to align things on odd bit boundaries. Stick to nibbles. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jsw at inconcepts.biz Sat Aug 6 05:15:01 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 6 Aug 2011 06:15:01 -0400 Subject: IPv6 end user addressing In-Reply-To: <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> Message-ID: On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong wrote: >> At least don't make your life miserable by experimenting with too many different assignment sizes, >> or advocate /64s or something, that's considered a design fault which will come back to you some day. >> Read the RfCs and RIR policy discussions in the archives some years ago. Note that in this thread, you advocate three things that are a little tough to make work together: * hierarchical addressing plan / routing * nibble-aligned addressing plan * minimum /48 per customer If I were, for example, a hosting company with IPv6 terminated at the layer-3 ToR switch, I would then use a /40 per rack of typical "dedicated servers." If you then want some bits to be a POP-locator field for your hierarchical routing scheme, you are already forced to request more than a /32. The number of customers per layer-3 device for typical end-user access networks was around the same into the late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever box of choice for terminating dial-up. Densities have changed, but this doesn't necessarily win you an advantage when combining those three properties. This is especially true if you consider that density may change in a difficult-to-predict manner in the future -- a BRAS box with a couple thousand customers today might have three times as many in a couple of years (IPv6 is supposed to help us avoid renumbering or injecting additional routes into our network, right?) As an access provider, if I shared your view, I would be reserving a /36 or /32 per BRAS box. If I then want some additional bits for hierarchical routing ... I'm going to need a pretty large address block for perhaps a pretty small number of customers. After all, my scheme, applying your logic, dictates that I should use a /32 or perhaps a /28 per each POP or city (I need to plan for several BRAS each), even if I don't have a lot of customers today! I think /56 is more sensible than /48, given the above, for most end-users. Either way, the users will be gaining a lot more flexibility than they have with IPv4 today, where they probably get just one IP address and have to pay a fee for any extras. Giving the typical end-user 8 fewer bits worth of address space allows the ISP network more flexibility for hierarchical routing before they have to go to their RIR and figure out how to justify an out-sized allocation. Also, if folks would stop thinking that every subnet should be a /64, they will see that end-users, makers of set-top-gateways, or whatever, can certainly address a whole lot of devices in a whole lot of subnets even if the user is only given a /64. Do we think DHCPv6 won't be the most common way of assigning addresses on SOHO LANs, and that SLAAC will be essential? I, for one, think that some ISPs will be sick and twisted enough to hand out /128s so they can continue charging for more IP addresses; but certainly the makers of IPv6-enabled devices will foresee that end-user LANs might not be /64 and include the necessary functionality to work correctly with smaller subnets. Before you beat me to it, yes, we seem to have completely opposing views on this subject. I will change my mind when I can go to the RIR and get a IPv6 /24 for a small ISP with a few POPs and a few tens of thousands of customers. Should RIR policy permit that sort of thing? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mukom.tamon at gmail.com Sat Aug 6 05:40:27 2011 From: mukom.tamon at gmail.com (Mukom Akong Tamon) Date: Sat, 6 Aug 2011 14:40:27 +0400 Subject: IPv6 end user addressing In-Reply-To: <4E3C4204.4020902@dougbarton.us> References: <4E3C4204.4020902@dougbarton.us> Message-ID: On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton wrote: > For example, if you reserve a /48 per customer but actually use the > first /56 out of it, you are safe if _you_ need the other /56 for some > reason, or if the customer needs to expand into the full /48. +1. Be generous in planning and then assign what makes operational sense. Be sure to make sure that as you dole out smaller than blocks to customers that requested from your RIR, you preserve your ability to give a client a second block from the same aggregatable range. -- Mukom Akong Tamon _______________ "A man owns nothing, not land or money, only his character, the loyalty & courage in his heart" - Commander Chakotay - StarTrek Voyager [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [Leadership Lessons from Movies] -?http://thbs.wordpress.com From cb.list6 at gmail.com Sat Aug 6 09:19:10 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 6 Aug 2011 07:19:10 -0700 Subject: IPv6 end user addressing In-Reply-To: <5421066B-0F87-40C5-B1F9-1F46C0CF39D1@delong.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <5421066B-0F87-40C5-B1F9-1F46C0CF39D1@delong.com> Message-ID: On Aug 6, 2011 2:11 AM, "Owen DeLong" wrote: > > I'm not the only person who prefers /48 and hopefully most ISPs will eventually > come around and realize that /56s don't really benefit anyone vs. /48s. > > Hurricane Electric has been handing out /48s upon request to our customers and > users of our IPv6 tunnel services. We do not anticipate changing that policy. > > Owen > A lot of good that /48 will do while HE rides out their on going peering war and customers are missing a wide swath of the ipv6 routing table. Cb > On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote: > > > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be > > zeroing in on a /56 for production. Though some ISPs are using /64 for > > their trials. > > > > Frank > > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Friday, August 05, 2011 12:21 PM > > To: Brian Mengel > > Cc: nanog at nanog.org > > Subject: Re: IPv6 end user addressing > > > > /56 is definitely preferable to /64, but, /48 really is a better choice. > > > > /56 is very limiting for autonomous hierarchical deployments. > > > > It's not about number of subnets. It's about the ability to provide some > > flexibility > > in the breadth and depth of bit fields used for creating hierarchical > > topologies > > automatically. > > > > Owen > > > > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > > > >> In reviewing IPv6 end user allocation policies, I can find little > >> agreement on what prefix length is appropriate for residential end > >> users. /64 and /56 seem to be the favorite candidates, with /56 being > >> slightly preferred. > >> > >> I am most curious as to why a /60 prefix is not considered when trying > >> to address this problem. It provides 16 /64 subnetworks, which seems > >> like an adequate amount for an end user. > >> > >> Does anyone have opinions on the BCP for end user addressing in IPv6? > > > From khelms at ispalliance.net Sat Aug 6 09:41:10 2011 From: khelms at ispalliance.net (Scott Helms) Date: Sat, 06 Aug 2011 10:41:10 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806011359.GA24602@gweep.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> Message-ID: <4E3D5286.7080307@ispalliance.net> Correct, I don't believe that any of the providers noted are actually hijacking HTTP sessions instead all of these are DNS based tricks. Since the service providers are also providing DNS (via Paxfire and others) users don't have a lot of choice. You can switch to using a known public name server (Google's 8.8.8.8 for example) but I hesitate to recommend that to most end users because in non-evil networks its better to have local name resolution (because of GSLB & other reasons). On 8/5/2011 9:14 PM, Joe Provo wrote: > On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: >> http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html > It is more than slightly misleading to say "hijacking search > queries"; paxfire is evil as it hijacks dns and breaks NXDOMAIN > and they've been doing that for ages. The user behavior of > searching in the address bar has become more common place, and > browser behavior to try and resolve first, fallback to search > for the same input field has both trained the humans to keep > doing this and made it possible for DNS query interlopers to > appear to be generic-search interlopers. > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Sat Aug 6 11:36:33 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 09:36:33 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> Message-ID: On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote: > On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong wrote: >>> At least don't make your life miserable by experimenting with too many different assignment sizes, >>> or advocate /64s or something, that's considered a design fault which will come back to you some day. >>> Read the RfCs and RIR policy discussions in the archives some years ago. > > Note that in this thread, you advocate three things that are a little > tough to make work together: > * hierarchical addressing plan / routing > * nibble-aligned addressing plan > * minimum /48 per customer > Hasn't been hard so far. > If I were, for example, a hosting company with IPv6 terminated at the > layer-3 ToR switch, I would then use a /40 per rack of typical > "dedicated servers." If you then want some bits to be a POP-locator > field for your hierarchical routing scheme, you are already forced to > request more than a /32. The number of customers per layer-3 device > for typical end-user access networks was around the same into the > late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever > box of choice for terminating dial-up. > I think we were talking about access customers. I don't see giving /48s to individual dedicated servers as I don't see them having hierarchy behind them. I would think that a /48 per TOR switch would be reasonable in that case. However, requesting more than a /32 is perfectly reasonable. In the ARIN region, policy 2011-3. > Densities have changed, but this doesn't necessarily win you an > advantage when combining those three properties. This is especially > true if you consider that density may change in a difficult-to-predict > manner in the future -- a BRAS box with a couple thousand customers > today might have three times as many in a couple of years (IPv6 is > supposed to help us avoid renumbering or injecting additional routes > into our network, right?) As an access provider, if I shared your > view, I would be reserving a /36 or /32 per BRAS box. If I then want > some additional bits for hierarchical routing ... I'm going to need a > pretty large address block for perhaps a pretty small number of > customers. After all, my scheme, applying your logic, dictates that I > should use a /32 or perhaps a /28 per each POP or city (I need to plan > for several BRAS each), even if I don't have a lot of customers today! > Correct? I think a /36 per BRAS seems about right, but if you want to put more than 3072 customers on a single BRAS and expect technology to eventually support that, sure, go for a /32 per BRAS. If you want to isolate your routing down to per BRAS (most providers I'm aware of that have multiple BRAS have it set up so any customer in a given POP may connect to any BRAS and they carry the customer prefixes within the POP's routing table), then, I think a /36 per BRAS is probably OK (up to 3072 customers at 75% utilization, 4096 max), but, if you really think you will have 6,000 customer BRAS units, then, yes, a /32 would be correct. However, I would be more likely to assign hierarchy per POP instead. Figure out how many customers are likely in my largest POP and allocate based on /48 per customer+growth in that POP. For example, if my largest POP would serve 2,000 customer end-sites, I'd be looking at a /36 per POP. If the largest POP served 3,073 customer end-sites or even 49,000 customer end-sites, I'd plan on a /32 per POP. Basically take the number of customer end-sites in your largest POP, divide by 0.75 (keep 25% headroom minimum) and then round up to the nearest nibble. If you really think you will have more than 786,432 customer sites served from your largest POP, then, I suppose a /28 per POP is a reasonable request. That seems like pretty unlikely density, even in 20 years. I realize that customer density in urban areas does tend to increase, but, assuming a maximum 50% market penetration, serving a city the size of Philadelphia out of a single POP still seems unlikely to me. > I think /56 is more sensible than /48, given the above, for most > end-users. Either way, the users will be gaining a lot more > flexibility than they have with IPv4 today, where they probably get > just one IP address and have to pay a fee for any extras. Giving the > typical end-user 8 fewer bits worth of address space allows the ISP > network more flexibility for hierarchical routing before they have to > go to their RIR and figure out how to justify an out-sized allocation. > Why? You point out that giving out /48s would require larger IPv6 allocations than /32, but, you don't give any reason to think this is bad. Let's look at the math. Let's assume a moderately large provider expects to serve 45,000 customer end-sites out of their largest POP (does anyone actually expect numbers this large in a single POP)? Now, let's say you have 50 POPs across your service region and expect to triple in size over the next 5 years. That's 150 total POPs planned. 45,000 customer end sites with 25% minfree is 60,000 which, when rounded up to a nibble is 16 bits for 65,536. 150 POPs with 25% minfree is 200 which, when rounded up to a nibble is 8 bits for 256 total POPs possible. 16+8 = 24, so, such a provider would need a /24 for their access network. There are 512 /24s in each of the /12s (what the IANA issues to RIRs). > Also, if folks would stop thinking that every subnet should be a /64, > they will see that end-users, makers of set-top-gateways, or whatever, > can certainly address a whole lot of devices in a whole lot of subnets > even if the user is only given a /64. Do we think DHCPv6 won't be the > most common way of assigning addresses on SOHO LANs, and that SLAAC > will be essential? I, for one, think that some ISPs will be sick and Yes. > twisted enough to hand out /128s so they can continue charging for > more IP addresses; but certainly the makers of IPv6-enabled devices > will foresee that end-user LANs might not be /64 and include the > necessary functionality to work correctly with smaller subnets. > I think natural selection in the market will solve that problem relatively quickly. > Before you beat me to it, yes, we seem to have completely opposing > views on this subject. I will change my mind when I can go to the RIR > and get a IPv6 /24 for a small ISP with a few POPs and a few tens of > thousands of customers. Should RIR policy permit that sort of thing? > OK? Start changing your mind? Read 2011-3. It's been adopted in the ARIN region. I'd also like to suggest you consider supporting APNIC proposal 98 which is essentially the same policy and will be discussed at the Busan meeting. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sat Aug 6 11:48:55 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 09:48:55 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <4E3C4204.4020902@dougbarton.us> Message-ID: <6FD9FF69-4E7C-4796-8235-5D3490EAA243@delong.com> On Aug 6, 2011, at 3:40 AM, Mukom Akong Tamon wrote: > On Fri, Aug 5, 2011 at 11:18 PM, Doug Barton wrote: >> For example, if you reserve a /48 per customer but actually use the >> first /56 out of it, you are safe if _you_ need the other /56 for some >> reason, or if the customer needs to expand into the full /48. > > +1. Be generous in planning and then assign what makes operational > sense. Be sure to make sure that as you dole out smaller than blocks > to customers that requested from your RIR, you preserve your ability > to give a client a second block from the same aggregatable range. > The way to address this better is to use allocation by bisection to your customers rather than giving them /56s. If you give a site a /48, it is very unlikely they will ever need an additional prefix for that site. Of course if you're talking about a customer that is using a single connection to you to feed multiple sites, that's a different issue and will require additional planning. For anyone that already understands allocation by bisection, you can skip the rest of this message. What I mean by allocation by bisection is simply issuing prefixes such that each issued prefix has the largest possible contiguous aligned space available for expansion. Let's assume 2001:db8::/32 as our starting point and that we are assigning /48s to 50 end sites from it. (I'm skipping the whole hierarchy to fit inside a /32 and keep the example simple). We'd assign 2001:db8::/48 for our own infrastructure and support machines. The first customer would get 2001:db8:8000::/48. The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48. In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48, 2001:db8:a000::/48 and 2001:db8:e000::/48 This would be followed by ?1000::/48, ?3000::/48, ?5000::/48, ?7000::/48, ?9000::/48, ?b000::/48, ?d000::/48, and ?f000::/48. At this point, we've assigned 15 customers, and each of them could be expanded from /48 to /36 without invading any of our existing assignments. Continuing, we would assign the next 16 customers as: 2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48, 2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48, 2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48, 2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48, 2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48, 2001:db8:f800::/48 That brings us to 31 customers all of whom have room to expand their /48 up to a /37 (though I wouldn't recommend doing /37s as they are not nibble-aligned, so, outside of exceptional circumstances, you would be unlikely to expand in place beyond /40 at this point.) The next 32 customers would fill in the 2001:db8:?400::/48 ranges and the 2001:db8:?c00::/48 ranges. This limits those customers now to /38s. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Sat Aug 6 11:55:34 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 09:55:34 -0700 Subject: US internet providers hijacking users' search queries In-Reply-To: <4E3D5286.7080307@ispalliance.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> Message-ID: I prefer running my own resolver. It's pretty trivial to do on a Mac and I would tend to think wouldn't be all that hard on Windows, though I have no idea. A resolver doesn't get much more local than ::1/128. Owen On Aug 6, 2011, at 7:41 AM, Scott Helms wrote: > Correct, I don't believe that any of the providers noted are actually hijacking HTTP sessions instead all of these are DNS based tricks. Since the service providers are also providing DNS (via Paxfire and others) users don't have a lot of choice. You can switch to using a known public name server (Google's 8.8.8.8 for example) but I hesitate to recommend that to most end users because in non-evil networks its better to have local name resolution (because of GSLB & other reasons). > > On 8/5/2011 9:14 PM, Joe Provo wrote: >> On Fri, Aug 05, 2011 at 05:04:51PM -0700, Bino Gopal wrote: >>> http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html >> It is more than slightly misleading to say "hijacking search >> queries"; paxfire is evil as it hijacks dns and breaks NXDOMAIN >> and they've been doing that for ages. The user behavior of >> searching in the address bar has become more common place, and >> browser behavior to try and resolve first, fallback to search >> for the same input field has both trained the humans to keep >> doing this and made it possible for DNS query interlopers to >> appear to be generic-search interlopers. >> >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From nanog-post at rsuc.gweep.net Sat Aug 6 12:08:01 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 6 Aug 2011 13:08:01 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <4E3D5286.7080307@ispalliance.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> Message-ID: <20110806170801.GA21712@gweep.net> On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote: > Correct, I don't believe that any of the providers noted are actually [snip] Belief has nothing to do with it. The article is vaguely referring to 'search' and incorrectly jumps to https. Disappointing that nanog readers can't read http://www.paxfire.com/faqs.php and get a clue, instead all the mouth-flapping about MItM and https. While collectively encouraging more https is a *good* thing, it is utterly tangential and misses the meat of this matter. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From joelja at bogus.com Sat Aug 6 13:16:28 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 6 Aug 2011 11:16:28 -0700 Subject: IPv6 end user addressing In-Reply-To: <005f01cc53c2$e52b4200$af81c600$@iname.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> Message-ID: On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote: > Let's clarify -- /48 is much preferred by Owen, It's is also supported by RIR policy, and the RFC series. It would unfair to characterize owen as the only holder of that preference. > but most ISPs seem to be > zeroing in on a /56 for production. Though some ISPs are using /64 for > their trials. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, August 05, 2011 12:21 PM > To: Brian Mengel > Cc: nanog at nanog.org > Subject: Re: IPv6 end user addressing > > /56 is definitely preferable to /64, but, /48 really is a better choice. > > /56 is very limiting for autonomous hierarchical deployments. > > It's not about number of subnets. It's about the ability to provide some > flexibility > in the breadth and depth of bit fields used for creating hierarchical > topologies > automatically. > > Owen > > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > >> In reviewing IPv6 end user allocation policies, I can find little >> agreement on what prefix length is appropriate for residential end >> users. /64 and /56 seem to be the favorite candidates, with /56 being >> slightly preferred. >> >> I am most curious as to why a /60 prefix is not considered when trying >> to address this problem. It provides 16 /64 subnetworks, which seems >> like an adequate amount for an end user. >> >> Does anyone have opinions on the BCP for end user addressing in IPv6? > > > From mysidia at gmail.com Sat Aug 6 13:25:18 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 6 Aug 2011 13:25:18 -0500 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806170801.GA21712@gweep.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> Message-ID: On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo wrote: > On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote: > > Correct, I don't believe that any of the providers noted are actually > [snip] > Disappointing that nanog readers can't read > http://www.paxfire.com/faqs.php and get a clue, instead all the mouth-flapping about MItM and https. a clue, > instead all the mouth-flapping about MItM and https. While Maybe instead of jumping to the conclusion NANOG readuers should "get a clue", you should actually do a little more research than reading a glossyware/ vacant FAQ that doesn't actually explain everything Paxfire is reported to do, how it works, and what the criticism is? I mean... don't you see a problem relying on _their own publication_ to say what they are doing, when they might like to keep their methods quiet to avoid negative attention? Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat, and not the issue. What the FAQ doesn't tell you is that the Paxfire appliances can tamper with DNS traffic received from authoritative DNS servers not operated by the ISP. A paxfire box can alter NXDOMAIN queries, and queries that respond with known search engines' IPs. to send your HTTP traffic to their HTTP proxies instead. Ty, http://netalyzr.icsi.berkeley.edu/blog/ " In addition, some ISPs employ an optional, unadvertised Paxfire feature that redirects the entire stream of affected customers' web search requests to Bing, Google, and Yahoo via HTTP proxies operated by Paxfire. These proxies seemingly relay most searches and their corresponding results passively, in a process that remains invisible to the user. Certain keyword searches, however, trigger active interference by the HTTP proxies. " http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf http://newswire.xbiz.com/view.php?id=137208 -- -JH From bill at herrin.us Sat Aug 6 13:28:41 2011 From: bill at herrin.us (William Herrin) Date: Sat, 6 Aug 2011 14:28:41 -0400 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. ?/64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. Hi Brian, /64 is *strongly* discouraged. I'd go so far as to say that when we look back 3 years from now, anybody who assigned /64's to end user networks will be considered short-sighted bordering on foolish. Assign a /128 if you know the downstream is exactly 1 host (not a LAN, not a PC with virtual machines, exactly one computer) or else assign at least a /60. > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. ?It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. Every time someone needs more than the standard assignment, you have to make a custom assignment with the manpower cost to make it and maintain it. This will happen often with /64, occasionally with /60 and rarely with /56. On the flip side, /56 allows for 16M end-users in your /32 ISP allocation. After which you can trivially get as many additional /32's as you want. Is there any reason you want to super-optimize to get 268M end-users squashed in that /32? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Aug 6 13:44:45 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 6 Aug 2011 13:44:45 -0500 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: On Sat, Aug 6, 2011 at 1:28 PM, William Herrin wrote: > On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel wrote: > > On the flip side, /56 allows for 16M end-users in your /32 ISP > allocation. After which you can trivially get as many additional /32's > as you want. Is there any reason you want to super-optimize to get > 268M end-users squashed in that /32? > Arguably, if you only have one /32, and you ever get 65,536 customers each with a /48, getting as many /32s as you need should be no problem, also. But you might want to give them /56s, so you have more bits to logically divide those customers by region, or some other criteria to enable more efficient aggregation. That's the problem with the RIR's choice of issuing only /32s from which /48s are to be assigned. The customer has 80 bits to work with in organizing their hosts. But the ISP has only 16 bits in a /32 to work with. -- -JH From bruns at 2mbit.com Sat Aug 6 13:48:12 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 06 Aug 2011 12:48:12 -0600 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110806170801.GA21712@gweep.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> Message-ID: <4E3D8C6C.3000204@2mbit.com> On 8/6/11 11:08 AM, Joe Provo wrote: > Belief has nothing to do with it. The article is vaguely referring > to 'search' and incorrectly jumps to https. Disappointing that > nanog readers can't readhttp://www.paxfire.com/faqs.php and get > a clue, instead all the mouth-flapping about MItM and https. While > collectively encouraging more https is a*good* thing, it is utterly > tangential and misses the meat of this matter. Disappointing that certain nanog readers depend on information put out by the vendor to be 100% honest and forthcoming in what their product does. There's more to hijacking queries/dns/etc then just ISPs mucking with queries. MitM attacks, SSL hijacking, etc is all a valid concern, and completely within the realm of the discussion here and this topic. As pointed out, there are ISPs and whole countries who have no qualms with doing this type of thing. Further, who cares if the company says their product isn't made or won't do what it may be doing? We all know full well that people use products in ways they aren't meant or intended to be used. When companies realize that they can't just transparently muck with traffic anymore because 90% of customer traffic is encrypted, do you really think, in all honesty, that companies won't find a way to regain this revenue stream, even if it runs afoul of laws/ethics/etc? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From owen at delong.com Sat Aug 6 15:05:44 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 13:05:44 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <338C1C99-C2A6-4C59-A85B-230363A0CAE2@delong.com> On Aug 6, 2011, at 11:44 AM, Jimmy Hess wrote: > On Sat, Aug 6, 2011 at 1:28 PM, William Herrin wrote: > >> On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel wrote: >> > > >> On the flip side, /56 allows for 16M end-users in your /32 ISP >> allocation. After which you can trivially get as many additional /32's >> as you want. Is there any reason you want to super-optimize to get >> 268M end-users squashed in that /32? >> > > Arguably, if you only have one /32, and you ever get 65,536 customers > each with a /48, getting as many /32s as you need should be no problem, > also. > > But you might want to give them /56s, so you have more bits to logically > divide those customers by region, or some other criteria to enable > more efficient aggregation. > Policy supports you getting those bits left of the /32 instead now. Look at ARIN 2011-3 which was adopted and ratified by the board and is awaiting implementation by staff. If you like this idea, support APNIC prop 98, too, please. > That's the problem with the RIR's choice of issuing only /32s from which > /48s are to be assigned. > The customer has 80 bits to work with in organizing their hosts. > The /32 is only the default minimum for an ISP. A small ISP can probably work with 16 bits. Larger ISPs were always expected to get more than a /32. > But the ISP has only 16 bits in a /32 to work with. > Only if they're very small or not very intelligent in their RIR application. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jsw at inconcepts.biz Sat Aug 6 15:14:08 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 6 Aug 2011 16:14:08 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> Message-ID: On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong wrote: > On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote: >> Note that in this thread, you advocate three things that are a little >> tough to make work together: >> * hierarchical addressing plan / routing >> * nibble-aligned addressing plan >> * minimum /48 per customer >> > Hasn't been hard so far. Well, you aren't actually doing this on your network today. If you practiced what you are preaching, you would not be carrying aggregate routes to your tunnel broker gateways across your whole backbone. Perhaps you also wouldn't use one allocation on the tunnel broker gateway for /64s and another, a /37 in the case of Ashburn for example, for users who self-provision a /48 from it. Also, of course, your default assignment plan is /64, not /48, even though there are typically around, what, 10k tunnels active network-wide? To be clear, you don't do any of the three things you advocate above where Hurricane Electric's tunnel broker service is concerned. > I think we were talking about access customers. I don't see giving /48s > to individual dedicated servers as I don't see them having hierarchy > behind them. I would think that a /48 per TOR switch would be > reasonable in that case. I wish there was more discussion about IPv6 addressing plans in hosting environments on this list. I think that, rarely, customers will decide to tunnel from their home or office to their "dedicated server," co-lo rack, etc. My addressing policies provide for this type of customer to receive a /56 upon request without breaking my hierarchical addressing scheme. If they need more than that, the layer-3 aggregator has to inject an additional route into the POP area. If a whole bunch of customers on one aggregator ask for /56, then the aggregator needs an extra /48 (which might really mean growing its existing /48 to a shorter route.) > However, requesting more than a /32 is perfectly reasonable. In > the ARIN region, policy 2011-3. My read of that policy, and please correct me if I misunderstand, is that it recognizes only a two-level hierarchy. This would mean that an ISP could use some bits to represent a geographic region, a POP, or an aggregation router / address pool, but it does not grant them justification to reserve bits for all these purposes. > density, even in 20 years. I realize that customer density in > urban areas does tend to increase, but, assuming a maximum > 50% market penetration, serving a city the size of Philadelphia > out of a single POP still seems unlikely to me. AT&T serves some entire states out of a single POP, as far as layer-3 termination is concerned. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From ipv4brokers at gmail.com Sat Aug 6 17:31:04 2011 From: ipv4brokers at gmail.com (IPv4 Brokers) Date: Sat, 6 Aug 2011 18:31:04 -0400 Subject: Corporation for Sale with IPv4 Assets Message-ID: North American Corporation (domiciled in Nevada) is for sale. All non-IPv4 assets and debts (and other liabilities) have been transferred to another related corporation. IPv4 Assets include: 1 - ASN; and 3 - /20 networks (12,288 IP Addresses) direct allocations (non-legacy). Multiple options available for sale/purchase. Motivated sellers. Please e-mail: ipv4brokers at gmail.com or call/text: (404) 532-9535. Available on Saturday and Sunday for discussion. From owen at delong.com Sat Aug 6 18:26:48 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Aug 2011 16:26:48 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> Message-ID: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote: > On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong wrote: >> On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote: >>> Note that in this thread, you advocate three things that are a little >>> tough to make work together: >>> * hierarchical addressing plan / routing >>> * nibble-aligned addressing plan >>> * minimum /48 per customer >>> >> Hasn't been hard so far. > > Well, you aren't actually doing this on your network today. If you > practiced what you are preaching, you would not be carrying aggregate > routes to your tunnel broker gateways across your whole backbone. Yes we would. > Perhaps you also wouldn't use one allocation on the tunnel broker > gateway for /64s and another, a /37 in the case of Ashburn for > example, for users who self-provision a /48 from it. Also, of course, > your default assignment plan is /64, not /48, even though there are > typically around, what, 10k tunnels active network-wide? > Those are artifacts of a small allocation (/32) from a prior RIR policy. The fact that those things haven't worked out so well for us was one of the motivations behind developing policy 2011-3. > To be clear, you don't do any of the three things you advocate above > where Hurricane Electric's tunnel broker service is concerned. > Yes we do. We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. We will be implementing a nibble-aligned addressing plan as soon as we can get enough space from the RIR. That's pending implementation of 2011-3. We do have a hierarchical addressing plan. I said nothing about routing, but, we certainly could implement hierarchical routing if we arrived at a point where it was advantageous because we have designed for it. >> I think we were talking about access customers. I don't see giving /48s >> to individual dedicated servers as I don't see them having hierarchy >> behind them. I would think that a /48 per TOR switch would be >> reasonable in that case. > > I wish there was more discussion about IPv6 addressing plans in > hosting environments on this list. I think that, rarely, customers > will decide to tunnel from their home or office to their "dedicated > server," co-lo rack, etc. My addressing policies provide for this > type of customer to receive a /56 upon request without breaking my > hierarchical addressing scheme. If they need more than that, the > layer-3 aggregator has to inject an additional route into the POP > area. If a whole bunch of customers on one aggregator ask for /56, > then the aggregator needs an extra /48 (which might really mean > growing its existing /48 to a shorter route.) > Sounds like a mess. We'll stick with /48s for people that need more than a /64. >> However, requesting more than a /32 is perfectly reasonable. In >> the ARIN region, policy 2011-3. > > My read of that policy, and please correct me if I misunderstand, is > that it recognizes only a two-level hierarchy. This would mean that > an ISP could use some bits to represent a geographic region, a POP, or > an aggregation router / address pool, but it does not grant them > justification to reserve bits for all these purposes. > While that's theoretically true, the combination of 25% minfree , nibble boundaries, and equal sized allocations for all POPs based on your largest one allows for that in practical terms in most circumstances. >> density, even in 20 years. I realize that customer density in >> urban areas does tend to increase, but, assuming a maximum >> 50% market penetration, serving a city the size of Philadelphia >> out of a single POP still seems unlikely to me. > > AT&T serves some entire states out of a single POP, as far as layer-3 > termination is concerned. > Are any of the states with populations larger than Philadelphia among them? Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From khelms at ispalliance.net Sat Aug 6 21:03:32 2011 From: khelms at ispalliance.net (Scott Helms) Date: Sat, 06 Aug 2011 22:03:32 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> Message-ID: <4E3DF274.6050709@ispalliance.net> Not trying to be obtuse, but none of the technical docs you cite appear to talk about HTTP proxies nor does the newswire report have any technical details. I have tested several of the networks listed in the report and in none of the cases I saw was there HTTP proxy activity. Picking up on WCCP/TCS isn't that hard (I used to install those myself) so unless there is some functionality in IOS and/or JUNOS that allows I don't see it happening. Paxfire can operate all of the proxies they want but the network infrastructure has to be able to pass the traffic over to those proxies and I don't see it (on at least 3 of the networks cited). > What the FAQ doesn't tell you is that the Paxfire appliances can > tamper with DNS > traffic received from authoritative DNS servers not operated by the ISP. > A paxfire box can alter NXDOMAIN queries, and queries that respond > with known search engines' IPs. > to send your HTTP traffic to their HTTP proxies instead. > > Ty, http://netalyzr.icsi.berkeley.edu/blog/ > " > In addition, some ISPs employ an optional, unadvertised Paxfire > feature that redirects the entire stream of affected customers' web > search requests to Bing, Google, and Yahoo via HTTP proxies operated > by Paxfire. These proxies seemingly relay most searches and their > corresponding results passively, in a process that remains invisible > to the user. Certain keyword searches, however, trigger active > interference by the HTTP proxies. > " > > http://www.icir.org/christian/publications/2011-satin-netalyzr.pdf > http://newswire.xbiz.com/view.php?id=137208 > > > -- > -JH -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From marka at isc.org Sat Aug 6 21:08:39 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 07 Aug 2011 12:08:39 +1000 Subject: US internet providers hijacking users' search queries In-Reply-To: Your message of "Sat, 06 Aug 2011 02:14:16 MST." References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806004549.GD2510@hezmatt.org> <19EF6609-90C4-4B4F-AB59-D099FD6B194E@2mbit.com> <4E3C9228.4050808@paulgraydon.co.uk> <20110806010336.825891284C3D@drugs.dv.isc.org> Message-ID: <20110807020839.F1B461286997@drugs.dv.isc.org> In message , Owen DeLong write s: > On Aug 5, 2011, at 6:03 PM, Mark Andrews wrote: > > >=20 > > In message <4E3C9228.4050808 at paulgraydon.co.uk>, Paul Graydon writes: > >> On 08/05/2011 02:53 PM, Brielle wrote: > >>> Until they start MitM the ssl traffic, fake certs and all. Didn't a = > certai > >> n repressive regime already do this tactic with facebook or some = > other major=20 > >> site? > >>>=20 > >> Syria did:=20 > >> = > https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook ttp > >> s://www.facebook.com/note.php?note_id=3D10150178983622358&comments>=20= > > >=20 > > Which is countered by DNSSEC + DANE. A country may be able to fake = > everything > > under their tld but not the rest of the net. > >=20 > Unless they start proxying all queries and putting their own trust = > anchors on all the > results. Which still won't work unless they can get a false trust anchor for the root installed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From graham at g-rock.net Sat Aug 6 21:51:32 2011 From: graham at g-rock.net (Graham Wooden) Date: Sat, 06 Aug 2011 21:51:32 -0500 Subject: AT&T -> Qwest ... Localpref issue? Message-ID: Hi folks, Anyone else noticed a localpref change on Qwest network in regards to AT&T prefixes? I noticed my AT&T assigned prefixes dropping to 80, causing my backup transit peering with Centurylink to take preference with Qwest originators ... All was working fine with my prepends .. But not anymore... Any insight would be great. I haven?t reached out to AT&T or Qwest yet. Curious if this is a bigger change than just me. Thanks, -graham From damian at google.com Sat Aug 6 22:03:22 2011 From: damian at google.com (Damian Menscher) Date: Sat, 6 Aug 2011 20:03:22 -0700 Subject: US internet providers hijacking users' search queries In-Reply-To: <4E3DF274.6050709@ispalliance.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: I can confirm the report is about DNS providers that are doing hijacking by sending the traffic through dedicated proxies, either in the ISP's network or in the DNS provider's network. If you didn't see this happening, it might be because you were testing on www.google.com rather than on Yahoo or Bing traffic. While the hijacking *used* to affect Google also, we took a fairly aggressive stance and got it stopped a while ago. The fact that there are no currently-known cases where it affects Google was unfortunately not made clear in the Netalyzer/EFF reports. If any of you find evidence of hijacking of Google, please shoot me an email with details (DNS server, destination IP, etc) and I'll do what I can to get it stopped. Damian On Sat, Aug 6, 2011 at 7:03 PM, Scott Helms wrote: > Not trying to be obtuse, but none of the technical docs you cite appear to > talk about HTTP proxies nor does the newswire report have any technical > details. I have tested several of the networks listed in the report and in > none of the cases I saw was there HTTP proxy activity. Picking up on > WCCP/TCS isn't that hard (I used to install those myself) so unless there is > some functionality in IOS and/or JUNOS that allows I don't see it happening. > Paxfire can operate all of the proxies they want but the network > infrastructure has to be able to pass the traffic over to those proxies and > I don't see it (on at least 3 of the networks cited). > > > > > What the FAQ doesn't tell you is that the Paxfire appliances can tamper >> with DNS >> traffic received from authoritative DNS servers not operated by the ISP. >> A paxfire box can alter NXDOMAIN queries, and queries that respond with >> known search engines' IPs. >> to send your HTTP traffic to their HTTP proxies instead. >> >> Ty, http://netalyzr.icsi.berkeley.**edu/blog/ >> " >> In addition, some ISPs employ an optional, unadvertised Paxfire feature >> that redirects the entire stream of affected customers' web search requests >> to Bing, Google, and Yahoo via HTTP proxies operated by Paxfire. These >> proxies seemingly relay most searches and their corresponding results >> passively, in a process that remains invisible to the user. Certain keyword >> searches, however, trigger active interference by the HTTP proxies. >> " >> >> http://www.icir.org/christian/**publications/2011-satin-**netalyzr.pdf >> http://newswire.xbiz.com/view.**php?id=137208 >> >> >> -- >> -JH >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > ------------------------------**-- > http://twitter.com/kscotthelms > ------------------------------**-- > > > -- Damian Menscher :: Security Reliability Engineer :: Google From paul4004 at gmail.com Sat Aug 6 23:57:47 2011 From: paul4004 at gmail.com (PC) Date: Sat, 6 Aug 2011 22:57:47 -0600 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: References: Message-ID: Qwest uses 80 for peers; 100 for customers. As I'm sure Qwest had AT&T as a peer prior to today (and you tagged as a customer), it probably should have been 80 since the beginning. What was the local pref to AT&T before? Maybe they found a misconfiguration on a router. If your only objective is to make your Qwest peering "backup", send community 209:70 to Qwest and it'll drop your local pref on their network to 70. This will cause their 80 local pref peering with AT&T to be preferred. I also suggest you read: http://www.onesc.net/communities/as209/ and http://www.onesc.net/communities/as7018/ However, depending on if your network topology and situational circumstances permit it, it may not be a bad idea to take on-net customer routes for performance reasons. On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden wrote: > Hi folks, > > Anyone else noticed a localpref change on Qwest network in regards to AT&T > prefixes? I noticed my AT&T assigned prefixes dropping to 80, causing my > backup transit peering with Centurylink to take preference with Qwest > originators ... All was working fine with my prepends .. But not > anymore... > > Any insight would be great. I haven?t reached out to AT&T or Qwest yet. > Curious if this is a bigger change than just me. > > Thanks, > > -graham > From jra at baylink.com Sun Aug 7 00:14:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Aug 2011 01:14:42 -0400 (EDT) Subject: STRIKE: VZN Message-ID: <31225253.655.1312694082694.JavaMail.root@benjamin.baylink.com> As of midnight, 45,000 IBEW and CWA members are striking Verizon, as their contract has expired. http://www.reuters.com/article/2011/08/07/us-verizon-labor-idUSTRE7760C320110807 It's not clear how this might affect what we do, but it might, and I figured the heads up would probably be useful. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From zaid at zaidali.com Sun Aug 7 00:39:19 2011 From: zaid at zaidali.com (Zaid Ali) Date: Sat, 6 Aug 2011 22:39:19 -0700 Subject: STRIKE: VZN In-Reply-To: <31225253.655.1312694082694.JavaMail.root@benjamin.baylink.com> References: <31225253.655.1312694082694.JavaMail.root@benjamin.baylink.com> Message-ID: <6FAD1050-2200-4C2E-A0A9-00C40300BB4B@zaidali.com> I heard a few days ago this might happen through another carrier who depends on a local loop from VZ. If you are waiting on circuit installs or someone has to swap out an NI card this may impact you. Thanks for the link. Zaid Sent from my iPhone On Aug 6, 2011, at 10:14 PM, Jay Ashworth wrote: > As of midnight, 45,000 IBEW and CWA members are striking Verizon, as their > contract has expired. > > http://www.reuters.com/article/2011/08/07/us-verizon-labor-idUSTRE7760C320110807 > > It's not clear how this might affect what we do, but it might, and I > figured the heads up would probably be useful. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > From it8844 at gmail.com Sun Aug 7 01:50:26 2011 From: it8844 at gmail.com (IT 8844) Date: Sun, 7 Aug 2011 14:50:26 +0800 Subject: Errant Advertisement - 128.1/16 In-Reply-To: References: Message-ID: Did you fix it? My traceroute shows last hop is 64.119.128.44. On Fri, Aug 5, 2011 at 12:07 AM, Rick Altmann wrote: > Is there anyone from AT&T on the list that could help with a likely misconfiguration? ?I have not received any response yet to my complaint (see below) submitted to the abuse address on July 26. ?We have since started advertising this space and would like to resolve the MOAS condition we have created. > > //////////////// > > The 128.1.0.0/16 address block is registered to BBN Technologies (AS11488) but is currently unused on any BBN networks. ?BBN would like to begin using this address space however AS7018 is currently originating public BGP routes for this address block. ?We believe this to be a configuration error. ?Please help us resolve this. > > A traceroute to 128.1.0.1 shows the following routers as the last 4 responding hops: > > cr1.n54ny.ip.att.net (12.122.81.106) > cr81.nw2nj.ip.att.net (12.122.105.30) > gar18.n54ny.ip.att.net (12.122.105.101) > 12.89.231.190 > > //////////////// > > Thanks, > Rick > From graham at g-rock.net Sun Aug 7 08:30:39 2011 From: graham at g-rock.net (Graham Wooden) Date: Sun, 07 Aug 2011 08:30:39 -0500 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: Message-ID: Thanks Paul. Localpref with Qwest on my AT&T prefixes was 100 until last week ... So my prepends to balance between the two was working just fine for the past 2 years or so. My announcements to CenturyLink to Qwest are coming out as 100. I am not a direct customer of Qwest, so sending the community of 209:70 won?t work (already tried that). I am a direct customer of CenturyLink and unfortunately the two networks haven?t really come together as one just yet. I sent a note to AT&T ? maybe the can help do something, as I reviewed the communities with them and I am already doing what I need to do. The main problem here is that our CenturyLink connection is pure crap ... Even originating routes from their network, I had them take our AT&T (the other transit at this particular POP) - faster and less hops (go figure). At our other pops with more than 1 transits, we like to utilize both as much as possible. Contract is up in December ... can?t wait until it?s gone. On 8/6/11 11:57 PM, "PC" wrote: > Qwest uses 80 for peers; 100 for customers.? As I'm sure Qwest had AT&T as a > peer prior to today (and you tagged as a customer), it probably should have > been 80 since the beginning.? What was the local pref to AT&T before?? Maybe > they found a misconfiguration on a router. > > If your only objective is to make your Qwest peering "backup", send community > 209:70 to Qwest and it'll drop your local pref on their network to 70.? This > will cause their 80 local pref peering with AT&T to be preferred. > > I also suggest you read: > http://www.onesc.net/communities/as209/ > and > http://www.onesc.net/communities/as7018/ > > However, depending on if your network topology and situational circumstances > permit it, it may not be a bad idea to take on-net customer routes for > performance reasons. > > On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden wrote: >> Hi folks, >> >> Anyone else noticed a localpref change on Qwest network in regards to AT&T >> prefixes? ?I noticed my AT&T assigned prefixes dropping to 80, causing my >> backup transit peering with Centurylink to take preference with Qwest >> originators ... ?All was working fine with my prepends .. But not anymore... >> >> Any insight would be great. I haven?t reached out to AT&T or Qwest yet. >> Curious if this is a bigger change than just me. >> >> Thanks, >> >> -graham > > From graham at g-rock.net Sun Aug 7 08:53:05 2011 From: graham at g-rock.net (Graham Wooden) Date: Sun, 07 Aug 2011 08:53:05 -0500 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: Message-ID: I should also note that Centurylink has been less than cooperative on even thinking about changing my routes to a pref of 70 on our behalf (they don't accept communities). I think time to get the account rep involved ... On 8/7/11 8:30 AM, "Graham Wooden" wrote: > Thanks Paul. > > Localpref with Qwest on my AT&T prefixes was 100 until last week ... So my > prepends to balance between the two was working just fine for the past 2 > years or so. > My announcements to CenturyLink to Qwest are coming out as 100. > > I am not a direct customer of Qwest, so sending the community of 209:70 > won?t work (already tried that). I am a direct customer of CenturyLink and > unfortunately the two networks haven?t really come together as one just yet. > I sent a note to AT&T ? maybe the can help do something, as I reviewed the > communities with them and I am already doing what I need to do. > > The main problem here is that our CenturyLink connection is pure crap ... > Even originating routes from their network, I had them take our AT&T (the > other transit at this particular POP) - faster and less hops (go figure). > At our other pops with more than 1 transits, we like to utilize both as much > as possible. > > Contract is up in December ... can?t wait until it?s gone. > > > On 8/6/11 11:57 PM, "PC" wrote: > >> Qwest uses 80 for peers; 100 for customers.? As I'm sure Qwest had AT&T as a >> peer prior to today (and you tagged as a customer), it probably should have >> been 80 since the beginning.? What was the local pref to AT&T before?? Maybe >> they found a misconfiguration on a router. >> >> If your only objective is to make your Qwest peering "backup", send community >> 209:70 to Qwest and it'll drop your local pref on their network to 70.? This >> will cause their 80 local pref peering with AT&T to be preferred. >> >> I also suggest you read: >> http://www.onesc.net/communities/as209/ >> and >> http://www.onesc.net/communities/as7018/ >> >> However, depending on if your network topology and situational circumstances >> permit it, it may not be a bad idea to take on-net customer routes for >> performance reasons. >> >> On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden wrote: >>> Hi folks, >>> >>> Anyone else noticed a localpref change on Qwest network in regards to AT&T >>> prefixes? ?I noticed my AT&T assigned prefixes dropping to 80, causing my >>> backup transit peering with Centurylink to take preference with Qwest >>> originators ... ?All was working fine with my prepends .. But not anymore... >>> >>> Any insight would be great. I haven?t reached out to AT&T or Qwest yet. >>> Curious if this is a bigger change than just me. >>> >>> Thanks, >>> >>> -graham >> >> > From joelja at bogus.com Sun Aug 7 10:26:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 7 Aug 2011 08:26:09 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <404AD93A-F84C-4ABD-8954-216109F22C60@bogus.com> On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. > > Does anyone have opinions on the BCP for end user addressing in IPv6? When you have a device that delegates, e.g. a cpe taking it's assigned prefix, and delegating a fraction of it to a downstream device, you need enough bits that you can make them out, possibly more than once. if you want that to happen automatically you want enough bits that user-intervention is never (for small values of never) required in to subnet when connecting devices together... the homenet wg is exploring how devices in the home might address the issue of topology discovery in conjunction with delegation, which realistically home networks are going to have to do... https://www.ietf.org/mailman/listinfo/homenet From Valdis.Kletnieks at vt.edu Sun Aug 7 10:39:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 07 Aug 2011 11:39:31 -0400 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: Your message of "Sun, 07 Aug 2011 08:53:05 CDT." References: Message-ID: <121127.1312731571@turing-police.cc.vt.edu> On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: > I should also note that Centurylink has been less than cooperative on even > thinking about changing my routes to a pref of 70 on our behalf (they don't > accept communities). I think time to get the account rep involved ... "they don't accept communities"??!? Just... wow. ;) (That's if they flat out don't support it - there's a separate ring of Hell reserved for the ones who do support it but forget to document the part about singing the Zimbabwe national anthem backwards while standing on your head...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Sun Aug 7 10:48:14 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 7 Aug 2011 08:48:14 -0700 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: <121127.1312731571@turing-police.cc.vt.edu> References: <121127.1312731571@turing-police.cc.vt.edu> Message-ID: <96A9BBE9-A50A-4D4A-9309-A344C5656E90@bogus.com> This is one of the reasons that I thought a useful output from the opsec or idr working group would be a documented set of community functions. Not mapped to values mind you. but I really like to say to providers "do you support rfc blah communities" or "what's your rfc blah community mapping" rather than "what communities do you support". On Aug 7, 2011, at 8:39 AM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: >> I should also note that Centurylink has been less than cooperative on even >> thinking about changing my routes to a pref of 70 on our behalf (they don't >> accept communities). I think time to get the account rep involved ... > > "they don't accept communities"??!? Just... wow. ;) > > (That's if they flat out don't support it - there's a separate ring of Hell > reserved for the ones who do support it but forget to document the part > about singing the Zimbabwe national anthem backwards while standing on > your head...) From nanog-post at rsuc.gweep.net Sun Aug 7 11:10:30 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 7 Aug 2011 12:10:30 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> Message-ID: <20110807161029.GA50031@gweep.net> On Sat, Aug 06, 2011 at 01:25:18PM -0500, Jimmy Hess wrote: > On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo wrote: > > > On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote: > > > Correct, I don't believe that any of the providers noted are actually > > [snip] > > Disappointing that nanog readers can't read > > http://www.paxfire.com/faqs.php and get > > a clue, instead all the mouth-flapping about MItM and https. a clue, > > instead all the mouth-flapping about MItM and https. While > > > Maybe instead of jumping to the conclusion NANOG readuers should "get a > clue", > you should actually do a little more research than reading a glossyware/ > vacant FAQ that doesn't actually explain everything Paxfire is reported to > do, how it works, and what the criticism is? I'm not jumping to conclusions, merely speaking to evidence. My personal experience involves leaving a job at a network that insisted on implementing some of this dreck. There is a well-known, long-standing "monetization" by breaking NXDOMAIN. DSLreports and plenty of other end-user fora have been full of information regarding this since Earthlink starded doing it in ... 2006? > Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat, > and not the issue. That sentence makes no sense. Hijacking NXDOMAIN doesn't have anything to do with pointing to a recursive resolver, but returning a partner/ affiliate web site, search "helper" site or proxy instead of the NXDOMAIN. > What the FAQ doesn't tell you is that the Paxfire appliances can tamper > with DNS > traffic received from authoritative DNS servers not operated by the ISP. > A paxfire box can alter NXDOMAIN queries, and queries that respond with > known search engines' IPs. > to send your HTTP traffic to their HTTP proxies instead. > > Ty, http://netalyzr.icsi.berkeley.edu/blog/ This is finally something new, and I retract my assertion that the new scientist got it wrong. Drilling through to actual evidence and details, rather than descriptions which match previous behavior, we have both http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little indirect with 'example.com', etc) and http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual domains) provide detail on the matter. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From jsw at inconcepts.biz Sun Aug 7 14:00:39 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 7 Aug 2011 15:00:39 -0400 Subject: IPv6 end user addressing In-Reply-To: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> Message-ID: On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong wrote: >> Well, you aren't actually doing this on your network today. ?If you >> practiced what you are preaching, you would not be carrying aggregate >> routes to your tunnel broker gateways across your whole backbone. > > Yes we would. No, if you actually had a hierarchical addressing scheme, you would issue tunnel broker customer /64s from the same aggregate prefix that is used for their /48s. You'd then summarize at your ABRs so the entire POP need only inject one route for customer addressing into the backbone. Of course, this is not what you do today, and not because of limited RIR allocation policies -- but because you simply did not design your network with such route aggregation in mind. > Those are artifacts of a small allocation (/32) from a prior RIR policy. > The fact that those things haven't worked out so well for us was one of > the motivations behind developing policy 2011-3. There was nothing stopping you from using one /48 out of the /37s you use to issue customer /48 networks for issuing the default /64 blocks your tunnel broker hands out. > We give a minimum /48 per customer with the small exception that > customers who only want one subnet get a /64. You assign a /64 by default. Yes, customers can click a button and get themselves a /48 instantly, but let's tell the truth when talking about your current defaults -- customers are assigned a /64, not a /48. > We do have a hierarchical addressing plan. I said nothing about routing, > but, we certainly could implement hierarchical routing if we arrived at a > point where it was advantageous because we have designed for it. How have you designed for it? You already missed easy opportunities to inject fewer routes into your backbone, simply by using different aggregate prefixes for customer /64s vs /48s. >>> However, requesting more than a /32 is perfectly reasonable. In >>> the ARIN region, policy 2011-3. >> >> My read of that policy, and please correct me if I misunderstand, is >> that it recognizes only a two-level hierarchy. ?This would mean that >> an ISP could use some bits to represent a geographic region, a POP, or >> an aggregation router / address pool, but it does not grant them >> justification to reserve bits for all these purposes. >> > > While that's theoretically true, the combination of 25% minfree , > nibble boundaries, and equal sized allocations for all POPs based > on your largest one allows for that in practical terms in most > circumstances. I don't think it does allow for that. I think it requires you to have at least one "POP prefix" 75% full before you can get any additional space from the RIR, where 75% full means routed to customers, not reserved for aggregation router pools. This is not a hierarchy, it is simply a scheme to permit ISPs to bank on having at least one level of summarization in their addressing and routing scheme. 2011-3 does not provide for an additional level to summarize on the aggregation routers themselves. It should, but my read is that the authors have a very different opinion about what "hierarchical" addressing means than I do. It should provide for route aggregation on both the ABR and the aggregation router itself. >> AT&T serves some entire states out of a single POP, as far as layer-3 >> termination is concerned. >> > > Are any of the states with populations larger than Philadelphia among > them? Yes, for example, Indiana. Pretty much every state in the former Ameritech service territory. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Jonathon.Exley at kordia.co.nz Sun Aug 7 17:09:11 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Mon, 8 Aug 2011 10:09:11 +1200 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Jonathon This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From joelja at bogus.com Sun Aug 7 17:41:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 7 Aug 2011 15:41:23 -0700 Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> Message-ID: On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote: > This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. > All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? 2000::/3 is 1/8th of the address range. There are other things worth conserving not just /48s like the ability aggregate your whole assignment. 3.5 * 10^13 is a lot of /48s, but it's likely not enough so we'll get to crack the seal on 4000::/3 eventually and so on. > After all, there are only 4 bits of IP version field so the basic packet format won't last forever. > > Jonathon > > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > > > > From drc at virtualized.org Sun Aug 7 17:44:00 2011 From: drc at virtualized.org (David Conrad) Date: Sun, 7 Aug 2011 12:44:00 -1000 Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> Message-ID: Jonathon, On Aug 7, 2011, at 12:09 PM, Jonathon Exley wrote: > This has probably been said before, Once or twice :-) > but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. This isn't where the worry should be. Do the math. Right now, we're allocating something like 300,000,000 IPv4 addresses per year with a reasonable (handwave) percentage being used as NAT endpoints. If you cross your eyes sufficiently, that can look a bit like 300,000,000 networks being added per year. Translate that to IPv6 and /48s: There are 35,184,372,088,832 /48s in the format specifier currently defined for "global unicast". For the sake of argument, let's increase the the 'network addition' rate by 3 orders of magnitude to 300,000,000,000 per year. At that rate, which is equivalent to allocating 42 /48s per person on the planet per year, the current format specifier will last about 100 years. And there are 7 more format specifiers. > but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? The area to be more conservative is, perhaps unsurprisingly, in the network bureaucratic layer. I believe current allocation policy states an ISP gets a minimum of a /32 (allowing them to assign 65536 /48s), but "if justified" an ISP can get more. There have been allocations of all sorts of shorter prefixes, e.g., /19s, /18s, and even (much) shorter. An ISP that has received a /19 has the ability to allocate half a billion /48s. And of course, there are the same number of /19s, /18s, and even (much) shorter prefixes in IPv6 as there are in IPv4... > After all, there are only 4 bits of IP version field so the basic packet format won't last forever. True. There is no finite resource poor policy making can't make scarce. Regards, -drc From matthew at corp.crocker.com Sun Aug 7 17:55:31 2011 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Sun, 07 Aug 2011 18:55:31 -0400 (EDT) Subject: STRIKE: VZN In-Reply-To: <6FAD1050-2200-4C2E-A0A9-00C40300BB4B@zaidali.com> Message-ID: <37b62a8d-5dc0-4e95-98da-3ef84bfd5496@zimbra1.crocker.com> Historically the network gets more stable when they are on strike. It is amazing how well stuff works when nobody is mucking with the network. We received new keys for all of our Verizon colos the other day, first time that has happened. ----- Original Message ----- > From: "Zaid Ali" > To: "Jay Ashworth" > Cc: "NANOG" > Sent: Sunday, August 7, 2011 1:39:19 AM > Subject: Re: STRIKE: VZN > > I heard a few days ago this might happen through another carrier who > depends on a local loop from VZ. If you are waiting on circuit > installs or someone has to swap out an NI card this may impact you. > > Thanks for the link. > > Zaid > > Sent from my iPhone > > On Aug 6, 2011, at 10:14 PM, Jay Ashworth wrote: > > > As of midnight, 45,000 IBEW and CWA members are striking Verizon, > > as their > > contract has expired. > > > > http://www.reuters.com/article/2011/08/07/us-verizon-labor-idUSTRE7760C320110807 > > > > It's not clear how this might affect what we do, but it might, and > > I > > figured the heads up would probably be useful. > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think > > RFC 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 > > Land Rover DII > > St Petersburg FL USA http://photo.imageinc.us +1 > > 727 647 1274 > > > > > From marka at isc.org Sun Aug 7 17:58:51 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 08 Aug 2011 08:58:51 +1000 Subject: IPv6 end user addressing In-Reply-To: Your message of "Sun, 07 Aug 2011 15:00:39 -0400." References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> Message-ID: <20110807225851.0D52D128A49D@drugs.dv.isc.org> In message , Jeff Wheeler writes: > On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong wrote: > >> Well, you aren't actually doing this on your network today. =A0If you > >> practiced what you are preaching, you would not be carrying aggregate > >> routes to your tunnel broker gateways across your whole backbone. > > > > Yes we would. > > No, if you actually had a hierarchical addressing scheme, you would > issue tunnel broker customer /64s from the same aggregate prefix that > is used for their /48s. You'd then summarize at your ABRs so the > entire POP need only inject one route for customer addressing into the > backbone. Of course, this is not what you do today, and not because > of limited RIR allocation policies -- but because you simply did not > design your network with such route aggregation in mind. > > > Those are artifacts of a small allocation (/32) from a prior RIR policy. > > The fact that those things haven't worked out so well for us was one of > > the motivations behind developing policy 2011-3. > > There was nothing stopping you from using one /48 out of the /37s you > use to issue customer /48 networks for issuing the default /64 blocks > your tunnel broker hands out. So you want HE to force all their clients to renumber. > > We give a minimum /48 per customer with the small exception that > > customers who only want one subnet get a /64. > > You assign a /64 by default. Yes, customers can click a button and > get themselves a /48 instantly, but let's tell the truth when talking > about your current defaults -- customers are assigned a /64, not a > /48. The client can request a /48 or /64 as the initial allocation. > > We do have a hierarchical addressing plan. I said nothing about routing, > > but, we certainly could implement hierarchical routing if we arrived at a > > point where it was advantageous because we have designed for it. > > How have you designed for it? You already missed easy opportunities > to inject fewer routes into your backbone, simply by using different > aggregate prefixes for customer /64s vs /48s. > > >>> However, requesting more than a /32 is perfectly reasonable. In > >>> the ARIN region, policy 2011-3. > >> > >> My read of that policy, and please correct me if I misunderstand, is > >> that it recognizes only a two-level hierarchy. =A0This would mean that > >> an ISP could use some bits to represent a geographic region, a POP, or > >> an aggregation router / address pool, but it does not grant them > >> justification to reserve bits for all these purposes. > >> > > > > While that's theoretically true, the combination of 25% minfree , > > nibble boundaries, and equal sized allocations for all POPs based > > on your largest one allows for that in practical terms in most > > circumstances. > > I don't think it does allow for that. I think it requires you to have > at least one "POP prefix" 75% full before you can get any additional > space from the RIR, where 75% full means routed to customers, not > reserved for aggregation router pools. This is not a hierarchy, it is > simply a scheme to permit ISPs to bank on having at least one level of > summarization in their addressing and routing scheme. > > 2011-3 does not provide for an additional level to summarize on the > aggregation routers themselves. It should, but my read is that the > authors have a very different opinion about what "hierarchical" > addressing means than I do. It should provide for route aggregation > on both the ABR and the aggregation router itself. > > >> AT&T serves some entire states out of a single POP, as far as layer-3 > >> termination is concerned. > >> > > > > Are any of the states with populations larger than Philadelphia among > > them? > > Yes, for example, Indiana. Pretty much every state in the former > Ameritech service territory. > > --=20 > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jsw at inconcepts.biz Sun Aug 7 18:26:21 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 7 Aug 2011 19:26:21 -0400 Subject: IPv6 end user addressing In-Reply-To: <20110807225851.0D52D128A49D@drugs.dv.isc.org> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> Message-ID: On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews wrote: > So you want HE to force all their clients to renumber. No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough. Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise: There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization efficiency within ISP networks and individual aggregation router pools. That is foolish. We can all pull out a calculator and figure that 2000::/3 has space for 35 trillion /48 networks. That isn't how they will be assigned or routed. The effect of 2011-3 is that an out-sized ISP like AT&T has every justification for deciding to allocate 24 bits worth of subnet ID for their "largest POP," say, one that happens to terminate layer-3 services for all customers in an entire state. They then have policy support for allocating the same sized subnet for every other POP, no matter how small. After all, the RIR policy permits them to obtain additional allocations as soon as one POP subnet has become full. So now you have a huge ISP with a few huge POPs, and a lot of small ones, justified in assigning the same size aggregate prefix, suitable for 2^24 subnets, to all those small POPs as well. How many layer-3 POPs might this huge ISP have? Any number. It could be every central office with some kind of layer-3 customer aggregation router. It could even be every road-side hut for FTTH services. Perhaps they will decide to address ten thousand POPs this way. Now the nibble-aligned language in the policy permits them to round up from 10,000 POPs to 16 bits worth of address space for "POP ID." So AT&T is quite justified in requesting: 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 (POP ID) == a /8 subnet for themselves. Now you can see how this policy, and addressing scheme, is utterly brain-dead. It really does put you (and me, and everyone else) in real danger of exhausting the IPv6 address space. All it takes is a few out-sized ISPs, with one large POP each and a bunch of smaller ones, applying for the maximum amount of address space permitted them under 2011-3. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rcarpen at network1.net Sun Aug 7 19:47:48 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Sun, 07 Aug 2011 20:47:48 -0400 (EDT) Subject: IPv6 end user addressing In-Reply-To: Message-ID: <38727d94-46d1-453a-898a-58c9bfe811c9@zimbra.network1.net> > >> AT&T serves some entire states out of a single POP, as far as > >> layer-3 > >> termination is concerned. > >> > > > > Are any of the states with populations larger than Philadelphia > > among > > them? > > Yes, for example, Indiana. Pretty much every state in the former > Ameritech service territory. > Does AT&T seriously serve the entire state of Indiana from a single POP??? Sounds crazy to me. I have a few customers in Indiana that are small ILECs and they each have multiple (2-3) POPs even though they have no more than about 1,000 customers. -Randy From Valdis.Kletnieks at vt.edu Sun Aug 7 20:45:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 07 Aug 2011 21:45:31 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Sun, 07 Aug 2011 20:47:48 EDT." <38727d94-46d1-453a-898a-58c9bfe811c9@zimbra.network1.net> References: <38727d94-46d1-453a-898a-58c9bfe811c9@zimbra.network1.net> Message-ID: <144191.1312767931@turing-police.cc.vt.edu> On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said: > Does AT&T seriously serve the entire state of Indiana from a single POP??? > Sounds crazy to me. It makes sense if they're managing to bill customers by the cable mile from their location to the POP. Imagine a POP in Terre Haute or Indianapolis and 1,500+ customers in the Gary area and another 1K in the South Bend and Fort Wayne areas... Of course, some other provider would get a clue and and offer the same price per mile "your location to our POP" - after putting a POP in Gary, South Bend, and Fort Wayne. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rbf+nanog at panix.com Sun Aug 7 21:53:25 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 7 Aug 2011 21:53:25 -0500 Subject: IPv6 end user addressing In-Reply-To: <144191.1312767931@turing-police.cc.vt.edu> References: <38727d94-46d1-453a-898a-58c9bfe811c9@zimbra.network1.net> <144191.1312767931@turing-police.cc.vt.edu> Message-ID: <20110808025325.GA15567@panix.com> On Sun, Aug 07, 2011 at 09:45:31PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Sun, 07 Aug 2011 20:47:48 EDT, Randy Carpenter said: > > Does AT&T seriously serve the entire state of Indiana from a single POP??? > > Sounds crazy to me. > > It makes sense if they're managing to bill customers by the cable mile from > their location to the POP. Imagine a POP in Terre Haute or Indianapolis and > 1,500+ customers in the Gary area and another 1K in the South Bend and Fort > Wayne areas... Of course, some other provider would get a clue and and offer > the same price per mile "your location to our POP" - after putting a POP in > Gary, South Bend, and Fort Wayne. :) AT&T doesn't serve the entire state of Indiana from a single POP. The question at hand was how many POPs *with layer 3 service* they had. I don't know the answer to that question and don't claim that it is or is not "one", but the TDM or L2 backhaul from the nearest POP to whatever other POP has the Layer 3 service isn't paid for by the customer. It's also not clear if they were talking about AT&T the LEC (offering services like DSL) or AT&T the IXC (offering things like business Internet service, V4VPN services, etc). If the latter, it's not at all surprising; legacy IXCs often have more POPs than POPs w/ Layer 3 services, and they backhaul L3 services over their legacy TDM and/or Layer 2 (ATM or FR) networks to a POP that has a router. This was a way for them to get IP service everywhere without installing routers everywhere; as the service took off, more POPs could be IP enabled to reduce the about of TDM (etc.) backhaul. But large legacy IXCs have a lot of POPs and, in general, still don't have routers (customer facing routers, anyway) in all of them. -- Brett From bill at herrin.us Mon Aug 8 00:15:29 2011 From: bill at herrin.us (William Herrin) Date: Mon, 8 Aug 2011 01:15:29 -0400 Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> Message-ID: On Sun, Aug 7, 2011 at 6:09 PM, Jonathon Exley wrote: > This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. > All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? > After all, there are only 4 bits of IP version field so the basic packet format won't last forever. Hi Jonathan, IPv6 uses a slightly different mental model when it comes to address allocation. In IPv4 you assigned blocks of 32-bit addresses. In IPv6 this is no longer the case. You do not assign blocks of 128-bit addresses. In IPv6 you assign blocks of 64-bit LANs. Each LAN is 64-bits long as required by technologies like SLAAC. So, a /48 is 65k LANs, _not_ however many bazillion addresses. The question you should be asking is: is it excessive or unwise to go around assigning 65,000 LANs to every customer? Would 256 (/56) or 1 (/64) be a better number? Assigning 1 LAN seems questionable. We're trying to avoid NAT with IPv6 which means a customer may want to spend a LAN on things like the interior network of a virtual machine server. It's hard to do this if you only have one LAN. On the other hand, a whole lot of folks have through this through before you and concluded that a /56 (256 LANs per customer) is a smarter starting point than a /48. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mohacsi at niif.hu Mon Aug 8 03:15:17 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 8 Aug 2011 10:15:17 +0200 (CEST) Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: On Fri, 5 Aug 2011, Brian Mengel wrote: > In reviewing IPv6 end user allocation policies, I can find little > agreement on what prefix length is appropriate for residential end > users. /64 and /56 seem to be the favorite candidates, with /56 being > slightly preferred. > > I am most curious as to why a /60 prefix is not considered when trying > to address this problem. It provides 16 /64 subnetworks, which seems > like an adequate amount for an end user. > > Does anyone have opinions on the BCP for end user addressing in IPv6? For business customers I would give /48 and home users who might have 1-2 subnet I would give /56 or /60. Reasons: - Business customers night grow where you have to provide bigger amount of subnet - allow space for future extension - - Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service.... Just my 2 cents.... Best Regards, Janos Mohacsi From artis at infosec.lv Mon Aug 8 04:55:51 2011 From: artis at infosec.lv (Artis Schlossberg) Date: Mon, 8 Aug 2011 11:55:51 +0200 Subject: NANOG Digest, Vol 43, Issue 24 In-Reply-To: References: Message-ID: unsubscribe On Mon, Aug 8, 2011 at 00:55, wrote: > Send NANOG mailing list submissions to > ? ? ? ?nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > ? ? ? ?nanog-request at nanog.org > > You can reach the person managing the list at > ? ? ? ?nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > ? 1. Re: IPv6 end user addressing (Joel Jaeggli) > ? 2. Re: AT&T -> Qwest ... Localpref issue? (Valdis.Kletnieks at vt.edu) > ? 3. Re: AT&T -> Qwest ... Localpref issue? (Joel Jaeggli) > ? 4. Re: US internet providers hijacking users' search queries > ? ? ?(Joe Provo) > ? 5. Re: IPv6 end user addressing (Jeff Wheeler) > ? 6. RE: IPv6 end user addressing (Jonathon Exley) > ? 7. Re: IPv6 end user addressing (Joel Jaeggli) > ? 8. Re: IPv6 end user addressing (David Conrad) > ? 9. Re: STRIKE: VZN (Matthew S. Crocker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 7 Aug 2011 08:26:09 -0700 > From: Joel Jaeggli > To: Brian Mengel > Cc: nanog at nanog.org > Subject: Re: IPv6 end user addressing > Message-ID: <404AD93A-F84C-4ABD-8954-216109F22C60 at bogus.com> > Content-Type: text/plain; charset=us-ascii > > > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote: > >> In reviewing IPv6 end user allocation policies, I can find little >> agreement on what prefix length is appropriate for residential end >> users. ?/64 and /56 seem to be the favorite candidates, with /56 being >> slightly preferred. >> >> I am most curious as to why a /60 prefix is not considered when trying >> to address this problem. ?It provides 16 /64 subnetworks, which seems >> like an adequate amount for an end user. >> >> Does anyone have opinions on the BCP for end user addressing in IPv6? > > When you have a device that delegates, e.g. a cpe taking it's assigned prefix, and delegating a fraction of it to a downstream device, you need enough bits that you can make them out, possibly more than once. if you want that to happen automatically you want enough bits that user-intervention is never (for small values of never) required in to subnet when connecting devices together... > > the homenet wg is exploring how devices in the home might address the issue of topology discovery in conjunction with delegation, which realistically home networks are going to have to do... > > https://www.ietf.org/mailman/listinfo/homenet > > > > > ------------------------------ > > Message: 2 > Date: Sun, 07 Aug 2011 11:39:31 -0400 > From: Valdis.Kletnieks at vt.edu > To: Graham Wooden > Cc: nanog at nanog.org > Subject: Re: AT&T -> Qwest ... Localpref issue? > Message-ID: <121127.1312731571 at turing-police.cc.vt.edu> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: >> I should also note that Centurylink has been less than cooperative on even >> thinking about changing my routes to a pref of 70 on our behalf (they don't >> accept communities). I think time to get the account rep involved ... > > "they don't accept communities"??!? Just... wow. ;) > > (That's if they flat out don't support it - there's a separate ring of Hell > reserved for the ones who do support it but forget to document the part > about singing the Zimbabwe national anthem backwards while standing on > your head...) > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 227 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 3 > Date: Sun, 7 Aug 2011 08:48:14 -0700 > From: Joel Jaeggli > To: Valdis.Kletnieks at vt.edu > Cc: " list" > Subject: Re: AT&T -> Qwest ... Localpref issue? > Message-ID: <96A9BBE9-A50A-4D4A-9309-A344C5656E90 at bogus.com> > Content-Type: text/plain; charset=us-ascii > > This is one of the reasons that I thought a useful output from the opsec or idr working group would be a documented set of community functions. Not mapped to values mind you. but I really like to say to providers "do you support rfc blah communities" or "what's your rfc blah community mapping" rather than "what communities do you support". > > > > On Aug 7, 2011, at 8:39 AM, Valdis.Kletnieks at vt.edu wrote: > >> On Sun, 07 Aug 2011 08:53:05 CDT, Graham Wooden said: >>> I should also note that Centurylink has been less than cooperative on even >>> thinking about changing my routes to a pref of 70 on our behalf (they don't >>> accept communities). I think time to get the account rep involved ... >> >> "they don't accept communities"??!? Just... wow. ;) >> >> (That's if they flat out don't support it - there's a separate ring of Hell >> reserved for the ones who do support it but forget to document the part >> about singing the Zimbabwe national anthem backwards while standing on >> your head...) > > > > > ------------------------------ > > Message: 4 > Date: Sun, 7 Aug 2011 12:10:30 -0400 > From: Joe Provo > To: nanog at nanog.org > Subject: Re: US internet providers hijacking users' search queries > Message-ID: <20110807161029.GA50031 at gweep.net> > Content-Type: text/plain; charset=us-ascii > > On Sat, Aug 06, 2011 at 01:25:18PM -0500, Jimmy Hess wrote: >> On Sat, Aug 6, 2011 at 12:08 PM, Joe Provo wrote: >> >> > On Sat, Aug 06, 2011 at 10:41:10AM -0400, Scott Helms wrote: >> > > Correct, I don't believe that any of the providers noted are actually >> > [snip] >> > ? Disappointing that nanog readers can't read >> > http://www.paxfire.com/faqs.php and get >> >> a clue, instead all the mouth-flapping about MItM and https. ? ? a clue, >> > instead all the mouth-flapping about MItM and https. While >> >> >> Maybe ?instead of jumping to the conclusion NANOG readuers should "get a >> clue", >> you should actually do a little more research than reading a glossyware/ >> vacant FAQ ?that doesn't actually explain everything Paxfire is reported to >> do, how it works, ?and what the criticism is? > > I'm not jumping to conclusions, merely speaking to evidence. My > personal experience involves leaving a job at a network that > insisted on implementing some of this dreck. There is a well-known, > long-standing "monetization" by breaking NXDOMAIN. DSLreports > and plenty of other end-user fora have been full of information > regarding this since Earthlink starded doing it in ... 2006? > >> Changing NXDOMAIN queries to an ISP's ?_own_ recursive servers is old hat, >> and not the issue. > > That sentence makes no sense. Hijacking NXDOMAIN doesn't have anything > to do with pointing to a recursive resolver, but returning a partner/ > affiliate web site, search "helper" site or proxy instead of the > NXDOMAIN. > >> What the FAQ doesn't tell you is that the Paxfire ?appliances can tamper >> with DNS >> traffic ?received from authoritative DNS servers not operated by the ISP. >> A paxfire box can alter NXDOMAIN queries, and ?queries that respond with >> known search engines' IPs. >> to send your HTTP traffic to their HTTP proxies instead. >> >> Ty, ?http://netalyzr.icsi.berkeley.edu/blog/ > > This is finally something new, and I retract my assertion that the new > scientist got it wrong. Drilling through to actual evidence and details, > rather than descriptions which match previous behavior, we have both > http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little > indirect with 'example.com', etc) and > http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual > domains) provide detail on the matter. > > Cheers! > > Joe > > -- > ? ? ? ? RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG > > > > ------------------------------ > > Message: 5 > Date: Sun, 7 Aug 2011 15:00:39 -0400 > From: Jeff Wheeler > To: nanog at nanog.org > Subject: Re: IPv6 end user addressing > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong wrote: >>> Well, you aren't actually doing this on your network today. ?If you >>> practiced what you are preaching, you would not be carrying aggregate >>> routes to your tunnel broker gateways across your whole backbone. >> >> Yes we would. > > No, if you actually had a hierarchical addressing scheme, you would > issue tunnel broker customer /64s from the same aggregate prefix that > is used for their /48s. ?You'd then summarize at your ABRs so the > entire POP need only inject one route for customer addressing into the > backbone. ?Of course, this is not what you do today, and not because > of limited RIR allocation policies -- but because you simply did not > design your network with such route aggregation in mind. > >> Those are artifacts of a small allocation (/32) from a prior RIR policy. >> The fact that those things haven't worked out so well for us was one of >> the motivations behind developing policy 2011-3. > > There was nothing stopping you from using one /48 out of the /37s you > use to issue customer /48 networks for issuing the default /64 blocks > your tunnel broker hands out. > >> We give a minimum /48 per customer with the small exception that >> customers who only want one subnet get a /64. > > You assign a /64 by default. ?Yes, customers can click a button and > get themselves a /48 instantly, but let's tell the truth when talking > about your current defaults -- customers are assigned a /64, not a > /48. > >> We do have a hierarchical addressing plan. I said nothing about routing, >> but, we certainly could implement hierarchical routing if we arrived at a >> point where it was advantageous because we have designed for it. > > How have you designed for it? ?You already missed easy opportunities > to inject fewer routes into your backbone, simply by using different > aggregate prefixes for customer /64s vs /48s. > >>>> However, requesting more than a /32 is perfectly reasonable. In >>>> the ARIN region, policy 2011-3. >>> >>> My read of that policy, and please correct me if I misunderstand, is >>> that it recognizes only a two-level hierarchy. ?This would mean that >>> an ISP could use some bits to represent a geographic region, a POP, or >>> an aggregation router / address pool, but it does not grant them >>> justification to reserve bits for all these purposes. >>> >> >> While that's theoretically true, the combination of 25% minfree , >> nibble boundaries, and equal sized allocations for all POPs based >> on your largest one allows for that in practical terms in most >> circumstances. > > I don't think it does allow for that. ?I think it requires you to have > at least one "POP prefix" 75% full before you can get any additional > space from the RIR, where 75% full means routed to customers, not > reserved for aggregation router pools. ?This is not a hierarchy, it is > simply a scheme to permit ISPs to bank on having at least one level of > summarization in their addressing and routing scheme. > > 2011-3 does not provide for an additional level to summarize on the > aggregation routers themselves. ?It should, but my read is that the > authors have a very different opinion about what "hierarchical" > addressing means than I do. ?It should provide for route aggregation > on both the ABR and the aggregation router itself. > >>> AT&T serves some entire states out of a single POP, as far as layer-3 >>> termination is concerned. >>> >> >> Are any of the states with populations larger than Philadelphia among >> them? > > Yes, for example, Indiana. ?Pretty much every state in the former > Ameritech service territory. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > > > ------------------------------ > > Message: 6 > Date: Mon, 8 Aug 2011 10:09:11 +1200 > From: Jonathon Exley > To: "nanog at nanog.org" > Subject: RE: IPv6 end user addressing > Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475 at winexmp02> > Content-Type: text/plain; charset="us-ascii" > > This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. > All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? > After all, there are only 4 bits of IP version field so the basic packet format won't last forever. > > Jonathon > > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > > > > > > ------------------------------ > > Message: 7 > Date: Sun, 7 Aug 2011 15:41:23 -0700 > From: Joel Jaeggli > To: Jonathon Exley > Cc: "nanog at nanog.org" > Subject: Re: IPv6 end user addressing > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote: > >> This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. >> All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? > > 2000::/3 is 1/8th of the address range. There are other things worth conserving ?not just /48s like the ability aggregate your whole assignment. 3.5 * 10^13 is a lot of /48s, but it's likely not enough so we'll get to crack the seal on 4000::/3 eventually and so on. > >> After all, there are only 4 bits of IP version field so the basic packet format won't last forever. >> >> Jonathon >> >> This email and attachments: are confidential; may be protected by >> privilege and copyright; if received in error may not be used,copied, >> or kept; are not guaranteed to be virus-free; may not express the >> views of Kordia(R); do not designate an information system; and do not >> give rise to any liability for Kordia(R). >> >> >> >> > > > > > ------------------------------ > > Message: 8 > Date: Sun, 7 Aug 2011 12:44:00 -1000 > From: David Conrad > To: Jonathon Exley > Cc: "nanog at nanog.org" > Subject: Re: IPv6 end user addressing > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Jonathon, > > On Aug 7, 2011, at 12:09 PM, Jonathon Exley wrote: >> This has probably been said before, > > Once or twice :-) > >> but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. > > This isn't where the worry should be. ?Do the math. ?Right now, we're allocating something like 300,000,000 IPv4 addresses per year with a reasonable (handwave) percentage being used as NAT endpoints. ?If you cross your eyes sufficiently, that can look a bit like 300,000,000 networks being added per year. ?Translate that to IPv6 and /48s: > > There are 35,184,372,088,832 /48s in the format specifier currently defined for "global unicast". ?For the sake of argument, let's increase the the 'network addition' rate by 3 orders of magnitude to 300,000,000,000 per year. ?At that rate, which is equivalent to allocating 42 /48s per person on the planet per year, the current format specifier will last about 100 years. And there are 7 more format specifiers. > >> but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? > > The area to be more conservative is, perhaps unsurprisingly, in the network bureaucratic layer. ?I believe current allocation policy states an ISP gets a minimum of a /32 (allowing them to assign 65536 /48s), but "if justified" an ISP can get more. ?There have been allocations of all sorts of shorter prefixes, e.g., /19s, /18s, and even (much) shorter. ?An ISP that has received a /19 has the ability to allocate half a billion /48s. And of course, there are the same number of /19s, /18s, and even (much) shorter prefixes in IPv6 as there are in IPv4... > >> After all, there are only 4 bits of IP version field so the basic packet format won't last forever. > > True. ?There is no finite resource poor policy making can't make scarce. > > Regards, > -drc > > > > > ------------------------------ > > Message: 9 > Date: Sun, 07 Aug 2011 18:55:31 -0400 (EDT) > From: "Matthew S. Crocker" > To: Zaid Ali > Cc: NANOG > Subject: Re: STRIKE: VZN > Message-ID: <37b62a8d-5dc0-4e95-98da-3ef84bfd5496 at zimbra1.crocker.com> > Content-Type: text/plain; charset=utf-8 > > > Historically the network gets more stable when they are on strike. ?It is amazing how well stuff works when nobody is mucking with the network. ?We received new keys for all of our Verizon colos the other day, ?first time that has happened. > > > ----- Original Message ----- >> From: "Zaid Ali" >> To: "Jay Ashworth" >> Cc: "NANOG" >> Sent: Sunday, August 7, 2011 1:39:19 AM >> Subject: Re: STRIKE: VZN >> >> I heard a few days ago this might happen through another carrier who >> depends on a local loop from VZ. If you are waiting on circuit >> installs or someone has to swap out an NI card this may impact you. >> >> Thanks for the link. >> >> Zaid >> >> Sent from my iPhone >> >> On Aug 6, 2011, at 10:14 PM, Jay Ashworth wrote: >> >> > As of midnight, 45,000 IBEW and CWA members are striking Verizon, >> > as their >> > contract has expired. >> > >> > http://www.reuters.com/article/2011/08/07/us-verizon-labor-idUSTRE7760C320110807 >> > >> > It's not clear how this might affect what we do, but it might, and >> > I >> > figured the heads up would probably be useful. >> > >> > Cheers, >> > -- jra >> > -- >> > Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink >> > ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com >> > Designer ? ? ? ? ? ? ? ? ? ? The Things I Think >> > ? ? ? ? ? ? ? ? ? ? ? RFC 2100 >> > Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 >> > Land Rover DII >> > St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 >> > 727 647 1274 >> > >> >> >> > > > > End of NANOG Digest, Vol 43, Issue 24 > ************************************* > From raltmann at bbn.com Mon Aug 8 07:07:59 2011 From: raltmann at bbn.com (Rick Altmann) Date: Mon, 8 Aug 2011 08:07:59 -0400 Subject: Errant Advertisement - 128.1/16 In-Reply-To: References: Message-ID: <75C5AC31-3F4F-437B-A199-1D6BA6FA5D6E@bbn.com> This issue has been cleared up. Thanks to everyone for their help. -Rick On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote: > Is there anyone from AT&T on the list that could help with a likely misconfiguration? I have not received any response yet to my complaint (see below) submitted to the abuse address on July 26. We have since started advertising this space and would like to resolve the MOAS condition we have created. > > //////////////// > > The 128.1.0.0/16 address block is registered to BBN Technologies (AS11488) but is currently unused on any BBN networks. BBN would like to begin using this address space however AS7018 is currently originating public BGP routes for this address block. We believe this to be a configuration error. Please help us resolve this. > > A traceroute to 128.1.0.1 shows the following routers as the last 4 responding hops: > > cr1.n54ny.ip.att.net (12.122.81.106) > cr81.nw2nj.ip.att.net (12.122.105.30) > gar18.n54ny.ip.att.net (12.122.105.101) > 12.89.231.190 > > //////////////// > > Thanks, > Rick From Valdis.Kletnieks at vt.edu Mon Aug 8 07:43:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Aug 2011 08:43:32 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Mon, 08 Aug 2011 10:15:17 +0200." References: Message-ID: <174561.1312807412@turing-police.cc.vt.edu> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: > - Home users - they usually don't know what is subnet. Setting up > different subnets in their SOHO router can be difficult. Usually the > simple 1 subnet for every device is enough for them. Separating some > devices into a separate subnets is usually enough for the most > sophisticated home users. If not then he can opt for business service.... You don't want to make the assumption that just because Joe Sixpack doesn't know what a subnet is, that Joe Sixpack's CPE doesn't know either. And remember that if it's 3 hops from one end of Joe Sixpack's internal net to the other, you're gonna burn a few bits to support heirarchical routing so you don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a /56 by the provider, and it hands each device it sees a /60 in case it's a device that routes too, it can only support 14 devices. And if one of the things that got handed a /60 is a wireless access point or something, it's only going to be able to support 15 or so subnets. So a simple topology of only a half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you can conserve bits by being more clever, but then you probably need an IGP of some sort.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mohacsi at niif.hu Mon Aug 8 09:12:00 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 8 Aug 2011 16:12:00 +0200 (CEST) Subject: IPv6 end user addressing In-Reply-To: <174561.1312807412@turing-police.cc.vt.edu> References: <174561.1312807412@turing-police.cc.vt.edu> Message-ID: On Mon, 8 Aug 2011, Valdis.Kletnieks at vt.edu wrote: > On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: > >> - Home users - they usually don't know what is subnet. Setting up >> different subnets in their SOHO router can be difficult. Usually the >> simple 1 subnet for every device is enough for them. Separating some >> devices into a separate subnets is usually enough for the most >> sophisticated home users. If not then he can opt for business service.... > > You don't want to make the assumption that just because Joe Sixpack doesn't > know what a subnet is, that Joe Sixpack's CPE doesn't know either. > > And remember that if it's 3 hops from one end of Joe Sixpack's internal net to > the other, you're gonna burn a few bits to support heirarchical routing so you > don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a > /56 by the provider, and it hands each device it sees a /60 in case it's a > device that routes too, it can only support 14 devices. And if one of the more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices.... I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary? Best Regards, Janos Mohacsi From marka at isc.org Mon Aug 8 09:18:57 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 09 Aug 2011 00:18:57 +1000 Subject: IPv6 end user addressing In-Reply-To: Your message of "Mon, 08 Aug 2011 08:43:32 -0400." <174561.1312807412@turing-police.cc.vt.edu> References: <174561.1312807412@turing-police.cc.vt.edu> Message-ID: <20110808141857.717D7128FF32@drugs.dv.isc.org> In message <174561.1312807412 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1312807411_38980P > Content-Type: text/plain; charset=us-ascii > > On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: > > > - Home users - they usually don't know what is subnet. Setting up > > different subnets in their SOHO router can be difficult. Usually the > > simple 1 subnet for every device is enough for them. Separating some > > devices into a separate subnets is usually enough for the most > > sophisticated home users. If not then he can opt for business service.... > > You don't want to make the assumption that just because Joe Sixpack doesn't > know what a subnet is, that Joe Sixpack's CPE doesn't know either. > > And remember that if it's 3 hops from one end of Joe Sixpack's internal net t > o > the other, you're gonna burn a few bits to support heirarchical routing so yo > u > don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a > /56 by the provider, and it hands each device it sees a /60 in case it's a > device that routes too, it can only support 14 devices. And if one of the > things that got handed a /60 is a wireless access point or something, it's on > ly > going to be able to support 15 or so subnets. So a simple topology of only a > half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, yo > u > can conserve bits by being more clever, but then you probably need an IGP of > some sort.... Which is why CPE devices shouldn't do heirarchical assignment by default. PD supports multiple upstream requests. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From petercs at gmail.com Mon Aug 8 10:29:19 2011 From: petercs at gmail.com (Peter Stockli) Date: Mon, 8 Aug 2011 17:29:19 +0200 Subject: Errant Advertisement - 128.1/16 In-Reply-To: <75C5AC31-3F4F-437B-A199-1D6BA6FA5D6E@bbn.com> References: <75C5AC31-3F4F-437B-A199-1D6BA6FA5D6E@bbn.com> Message-ID: Wow, BBN, the reason we use the @ sign, second .com Domain, former AS1. Lots of history ;) On Mon, Aug 8, 2011 at 2:07 PM, Rick Altmann wrote: > This issue has been cleared up. Thanks to everyone for their help. > > -Rick > > On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote: > > > Is there anyone from AT&T on the list that could help with a likely > misconfiguration? I have not received any response yet to my complaint (see > below) submitted to the abuse address on July 26. We have since started > advertising this space and would like to resolve the MOAS condition we have > created. > > > > //////////////// > > > > The 128.1.0.0/16 address block is registered to BBN Technologies > (AS11488) but is currently unused on any BBN networks. BBN would like to > begin using this address space however AS7018 is currently originating > public BGP routes for this address block. We believe this to be a > configuration error. Please help us resolve this. > > > > A traceroute to 128.1.0.1 shows the following routers as the last 4 > responding hops: > > > > cr1.n54ny.ip.att.net (12.122.81.106) > > cr81.nw2nj.ip.att.net (12.122.105.30) > > gar18.n54ny.ip.att.net (12.122.105.101) > > 12.89.231.190 > > > > //////////////// > > > > Thanks, > > Rick > > > From Valdis.Kletnieks at vt.edu Mon Aug 8 10:35:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Aug 2011 11:35:31 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Mon, 08 Aug 2011 16:12:00 +0200." References: <174561.1312807412@turing-police.cc.vt.edu> Message-ID: <7042.1312817731@turing-police.cc.vt.edu> On Mon, 08 Aug 2011 16:12:00 +0200, Mohacsi Janos said: > You don't have to count the all 0 and all > 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... > depending of capabilities your devices.... As I said further down the note - you can conserve bits but then it gets more complicated. You don't want to go to a static "subdivide whatever you got 16 ways if you can", you have to get more clever. Sure, that one device may only need a /61 right now because there's only 3 devices behind it. So the upstream bridge allocates the first /61 to that device, and allocates the next /63 to the next device that comes online. Then somebody adds a 4th device to that first router and now it needs a /60, but you can't just expand the allocation to a /60 because somebody is in the way. Somebody's gonna have to renumber. Or you can just say "I can support 16 devices so I need 4 bits of space". Or you can bite the bullet and do something more clever. > I think daisy chaining of CPE routers is bad idea - as probably done in > several IPv4 home networks. Why would you build several hierarchy into you > network if it is unnecessary? Because we're talking Joe Sixpack here - and he can't *spell* hierarchy. All he knows is that he's got one box that his cable company sent him, then he plugged his wireless access point into the cable company box, then he plugged all the stuff in the media center into a box and connected that box to the cable company box (He couldn't plug it all into the cable company box because that only had 4 RJ45's, and one got used for the wireless, and he's got 9(*) things in the media center that have RJ45s). You're at 2 levels of heirarchy already. Now if he decides to get lazy and not run a cable to the upstairs bedroom he wants to use as a home office, and gets another box that's really similar to the on in his media center except it will do wirelesss, he just added a third level of heirarchy. And I don't think that's an at all unreasonable scenario. Feel free to redesign that network to get rid of one level, let me know what you ended up doing. Oh, and explain it in terms Joe Sixpack can understand. ;) (*) Yes, 9 isn't at all unreasonable - I know plenty of people that have a Wii, a PS/2, a PS/3, an XBox, a TV that will talk to the Internet, a DVR that wants to talk to the Internet, and a PC. That's 7 already. On Tue, 09 Aug 2011 00:18:57 +1000, Mark Andrews said: > In message <174561.1312807412 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu > > half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you > > can conserve bits by being more clever, but then you probably need an IGP of > > some sort.... > > Which is why CPE devices shouldn't do heirarchical assignment by default. > PD supports multiple upstream requests. As I said - you can conserve bits using PD or similar, but then you need a routing solution - you can use PD to hand out prefixes, but then you still need routing. Consider the case above - the wireless box asks for a prefix delegation, then the media center box asks for one. Then the home office asks for one - and now you need to make sure there's a way for the stuff behind the media center box to know that to get to the printer that''s hanging off the home office box, it has to route to the wireless box. Anybody got gear that can do that and is ready for Joe Sixpack? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alan at gtekcommunications.com Mon Aug 8 11:01:32 2011 From: alan at gtekcommunications.com (Alan Bryant) Date: Mon, 8 Aug 2011 11:01:32 -0500 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: References: Message-ID: Graham, We have the same issue as you, although it has been that way since the beginning. Our primary is Level 3, and backup CenturyLink. We have been forced to only announce certain prefixes out each in order to get a balance. CenturyLink has told me that they do not support communities. Unfortunately I have much longer on my contract than you. We are even having problems routing to AOL & Yahoo on CenturyLink. I've had to refuse those routes from CenturyLink since Yahoo prepends out Level 3. On Sun, Aug 7, 2011 at 8:53 AM, Graham Wooden wrote: > I should also note that Centurylink has been less than cooperative on even > thinking about changing my routes to a pref of 70 on our behalf (they don't > accept communities). I think time to get the account rep involved ... > > > On 8/7/11 8:30 AM, "Graham Wooden" wrote: > >> Thanks Paul. >> >> Localpref with Qwest on my AT&T prefixes was 100 until last week ... So my >> prepends to balance between the two was working just fine for the past 2 >> years or so. >> My announcements to CenturyLink to Qwest are coming out as 100. >> >> I am not a direct customer of Qwest, so sending the community of 209:70 >> won?t work (already tried that). ?I am a direct customer of CenturyLink and >> unfortunately the two networks haven?t really come together as one just yet. >> I sent a note to AT&T ? maybe the can help do something, as I reviewed the >> communities with them and I am already doing what I need to do. >> >> The main problem here is that our CenturyLink connection is pure crap ... >> Even originating routes from their network, I had them take our AT&T (the >> other transit at this particular POP) - faster and less hops (go figure). >> At our other pops with more than 1 transits, we like to utilize both as much >> as possible. >> >> Contract is up in December ... can?t wait until it?s gone. >> >> >> On 8/6/11 11:57 PM, "PC" wrote: >> >>> Qwest uses 80 for peers; 100 for customers.? As I'm sure Qwest had AT&T as a >>> peer prior to today (and you tagged as a customer), it probably should have >>> been 80 since the beginning.? What was the local pref to AT&T before?? Maybe >>> they found a misconfiguration on a router. >>> >>> If your only objective is to make your Qwest peering "backup", send community >>> 209:70 to Qwest and it'll drop your local pref on their network to 70.? This >>> will cause their 80 local pref peering with AT&T to be preferred. >>> >>> I also suggest you read: >>> http://www.onesc.net/communities/as209/ >>> and >>> http://www.onesc.net/communities/as7018/ >>> >>> However, depending on if your network topology and situational circumstances >>> permit it, it may not be a bad idea to take on-net customer routes for >>> performance reasons. >>> >>> On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden wrote: >>>> Hi folks, >>>> >>>> Anyone else noticed a localpref change on Qwest network in regards to AT&T >>>> prefixes? ?I noticed my AT&T assigned prefixes dropping to 80, causing my >>>> backup transit peering with Centurylink to take preference with Qwest >>>> originators ... ?All was working fine with my prepends .. But not anymore... >>>> >>>> Any insight would be great. I haven?t reached out to AT&T or Qwest yet. >>>> Curious if this is a bigger change than just me. >>>> >>>> Thanks, >>>> >>>> -graham >>> >>> >> > > > > -- Alan Bryant Gtek Computers & Wireless L.L.C. Office: 361-777-1400 | Fax: 361-777-1405 alan at gtekcommunications.com | www.gtek.biz CONFIDENTIALITY NOTICE: This communication (including any attachments) may contain privileged or confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this communication and/or shred the materials and any attachments and are hereby notified that any disclosure, copying, or distribution of this communication, or the taking of any action based on it, is strictly prohibited. Thank you. From paul4004 at gmail.com Mon Aug 8 11:17:07 2011 From: paul4004 at gmail.com (PC) Date: Mon, 8 Aug 2011 10:17:07 -0600 Subject: AT&T -> Qwest ... Localpref issue? In-Reply-To: References: Message-ID: I don't like it as it's a slower to converge solution, but look into BGP conditional advertising. Or better yet, tell AM you want to move to the "Qwest" internet product. You want to peer with AS 209. On Sun, Aug 7, 2011 at 7:30 AM, Graham Wooden wrote: > Thanks Paul. > > Localpref with Qwest on my AT&T prefixes was 100 until last week ... So my > prepends to balance between the two was working just fine for the past 2 > years or so. > My announcements to CenturyLink to Qwest are coming out as 100. > > I am not a direct customer of Qwest, so sending the community of 209:70 > won?t work (already tried that). I am a direct customer of CenturyLink and > unfortunately the two networks haven?t really come together as one just yet. > I sent a note to AT&T ? maybe the can help do something, as I reviewed > the communities with them and I am already doing what I need to do. > > The main problem here is that our CenturyLink connection is pure crap ... > Even originating routes from their network, I had them take our AT&T (the > other transit at this particular POP) - faster and less hops (go figure). > At our other pops with more than 1 transits, we like to utilize both as > much as possible. > > Contract is up in December ... can?t wait until it?s gone. > > > > On 8/6/11 11:57 PM, "PC" wrote: > > Qwest uses 80 for peers; 100 for customers. As I'm sure Qwest had AT&T as > a peer prior to today (and you tagged as a customer), it probably should > have been 80 since the beginning. What was the local pref to AT&T before? > Maybe they found a misconfiguration on a router. > > If your only objective is to make your Qwest peering "backup", send > community 209:70 to Qwest and it'll drop your local pref on their network to > 70. This will cause their 80 local pref peering with AT&T to be preferred. > > I also suggest you read: > http://www.onesc.net/communities/as209/ > and > http://www.onesc.net/communities/as7018/ > > However, depending on if your network topology and situational > circumstances permit it, it may not be a bad idea to take on-net customer > routes for performance reasons. > > On Sat, Aug 6, 2011 at 8:51 PM, Graham Wooden wrote: > > Hi folks, > > Anyone else noticed a localpref change on Qwest network in regards to AT&T > prefixes? I noticed my AT&T assigned prefixes dropping to 80, causing my > backup transit peering with Centurylink to take preference with Qwest > originators ... All was working fine with my prepends .. But not > anymore... > > Any insight would be great. I haven?t reached out to AT&T or Qwest yet. > Curious if this is a bigger change than just me. > > Thanks, > > -graham > > > > From owen at delong.com Mon Aug 8 12:09:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 10:09:08 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> Message-ID: <906AAE4F-F934-4620-B68C-4182B1B19E50@delong.com> On Aug 7, 2011, at 12:00 PM, Jeff Wheeler wrote: > On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong wrote: >>> Well, you aren't actually doing this on your network today. If you >>> practiced what you are preaching, you would not be carrying aggregate >>> routes to your tunnel broker gateways across your whole backbone. >> >> Yes we would. > > No, if you actually had a hierarchical addressing scheme, you would > issue tunnel broker customer /64s from the same aggregate prefix that > is used for their /48s. You'd then summarize at your ABRs so the > entire POP need only inject one route for customer addressing into the > backbone. Of course, this is not what you do today, and not because > of limited RIR allocation policies -- but because you simply did not > design your network with such route aggregation in mind. > You are, once again, conflating two related, but, not identical terms. A hierarchical addressing scheme is NOT a hierarchical routing structure and vice versa. Yes, a hierarchical routing scheme requires a hierarchical addressing scheme, but, a hierarchical addressing scheme does NOT require a hierarchical routing scheme. We have a hierarchical addressing scheme. The fact that you dont' like our idea of having two parallel hierarchies for two different addressing structures is also getting in the way here. For us, using parallel similar hierarchies for the /64 and /48 prefix blocks works quite well and produces certain scaling advantages in our system. As to the details of how our IGP works. I'm not going to debate that with you because it is an internal matter and not really part of this discussion. If you want to talk in the abstract about good ways to structure routing, I'm happy to do that. However, it's a different (though related as described above) subject from hierarchical addressing. >> Those are artifacts of a small allocation (/32) from a prior RIR policy. >> The fact that those things haven't worked out so well for us was one of >> the motivations behind developing policy 2011-3. > > There was nothing stopping you from using one /48 out of the /37s you > use to issue customer /48 networks for issuing the default /64 blocks > your tunnel broker hands out. > I was talking about the fact we were using /37s. We have actually recognized significant advantages from using different prefix blocks to assign /48s and /64s in the environment and I don't expect us to change that practice even when we do get enough address space to build out the hierarchy the way we want. Those advantages, however, may well be unique to our tunnelbroker structure and may not be applicable to other networks. >> We give a minimum /48 per customer with the small exception that >> customers who only want one subnet get a /64. > > You assign a /64 by default. Yes, customers can click a button and > get themselves a /48 instantly, but let's tell the truth when talking > about your current defaults -- customers are assigned a /64, not a > /48. > We assign a /64 by default only to tunnelbroker customers and to customers without routers in our datacenters. I believe all others default to a /48 per site. I told the truth... We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. If you didn't want only one subnet, presumably you would click the button to get your instant /48. >> We do have a hierarchical addressing plan. I said nothing about routing, >> but, we certainly could implement hierarchical routing if we arrived at a >> point where it was advantageous because we have designed for it. > > How have you designed for it? You already missed easy opportunities > to inject fewer routes into your backbone, simply by using different > aggregate prefixes for customer /64s vs /48s. > You are correct... With present hind-sight, we could have designed things in such a way that we could have cut the number of aggregates to be injected into the backbone from 50 to 25. Assuming that our network doubles in size every year for the next 4 years, that would take us to a total of 800 routes that could be 400. OTOH, since we get some other advantages from this relatively small increment in prefixes, I think we'll probably stick with the architecture we have for the advantages it offers in other areas. Reducing prefix count is not the only consideration in running a network. >>>> However, requesting more than a /32 is perfectly reasonable. In >>>> the ARIN region, policy 2011-3. >>> >>> My read of that policy, and please correct me if I misunderstand, is >>> that it recognizes only a two-level hierarchy. This would mean that >>> an ISP could use some bits to represent a geographic region, a POP, or >>> an aggregation router / address pool, but it does not grant them >>> justification to reserve bits for all these purposes. >>> >> >> While that's theoretically true, the combination of 25% minfree , >> nibble boundaries, and equal sized allocations for all POPs based >> on your largest one allows for that in practical terms in most >> circumstances. > > I don't think it does allow for that. I think it requires you to have > at least one "POP prefix" 75% full before you can get any additional > space from the RIR, where 75% full means routed to customers, not > reserved for aggregation router pools. This is not a hierarchy, it is > simply a scheme to permit ISPs to bank on having at least one level of > summarization in their addressing and routing scheme. > No, it requires you to have 75% full over all or have at least one POP that is 90% full. However, in this case, you can use POP to mean your most distal aggregation point rather than something more proximal to your core. The term in the policy is "serving site" and is defined with sufficient flexibility to allow virtually any aggregation point to be considered a "serving site". Since you're allowed for a 5 year projection on your number of serving sites, unless you have rather radical diversity in the sizes of your upstream aggregations (this superpop serves 1000 pops, the other one serves 3), I think you'll find that the math does, in fact, work out OK. > 2011-3 does not provide for an additional level to summarize on the > aggregation routers themselves. It should, but my read is that the > authors have a very different opinion about what "hierarchical" > addressing means than I do. It should provide for route aggregation > on both the ABR and the aggregation router itself. > Can you present an example of a network where this wouldn't work out within policy? It can be fictitious and/or anonymous, but, show me a setup where you think it doesn't work out well and I bet I can show you how to work it. If not, I'll be the first to write an amendment. As one of the authors, I have to say, I don't think our opinions of what a "hierarchical" addressing plan means are all that different. I think mine is perhaps a bit more flexible than yours, but, I wouldn't say "radically different". >>> AT&T serves some entire states out of a single POP, as far as layer-3 >>> termination is concerned. >>> >> >> Are any of the states with populations larger than Philadelphia among >> them? > > Yes, for example, Indiana. Pretty much every state in the former > Ameritech service territory. Philadelphia 1,526,006 (2010 census) Indiana 6,4383,802 (2010 census) OK.. just barely 4x, but, I would bet if you look at the definition of the term serving site, Indiana would have smaller units than the layer 3 termination physical address that would apply in Indiana. Owen From jcurran at arin.net Mon Aug 8 13:29:02 2011 From: jcurran at arin.net (John Curran) Date: Mon, 8 Aug 2011 18:29:02 +0000 Subject: Corporation for Sale with IPv4 Assets In-Reply-To: References: Message-ID: <3D521E27-8E31-4F30-95FE-D819058268F5@arin.net> IPv4 Brokers - As you may be aware, ARIN is the Regional Internet Registry (RIR) responsible for Internet number resource management for Canada, United States, and parts of the Caribbean. In keeping with the policies developed by the community in this region, there are two possible ways to transfer IPv4 number resources to another party (via merger & acquisition transfer or via specified transfer), and these are detailed in section 8 of the Number Resource Policy Manual on the ARIN website at It is important to note that transfer of number resources via either method must be to another party that can demonstrate corresponding need. ARIN's registration services department can assist with this determination in advance or at the time of transfer. ARIN reiterates the importance of veracity in transfer requests and supporting documentation as fraudulent information can result in resource revocation. Thank you, /John John Curran President and CEO ARIN On Aug 6, 2011, at 6:31 PM, IPv4 Brokers wrote: > From: IPv4 Brokers > Subject: Corporation for Sale with IPv4 Assets > Date: August 6, 2011 6:31:04 PM EDT > To: nanog at nanog.org > > North American Corporation (domiciled in Nevada) is for sale. > > All non-IPv4 assets and debts (and other liabilities) have been transferred > to another related corporation. > > IPv4 Assets include: > 1 - ASN; and > 3 - /20 networks (12,288 IP Addresses) direct allocations (non-legacy). > > Multiple options available for sale/purchase. Motivated sellers. > > Please e-mail: ipv4brokers at gmail.com or call/text: (404) 532-9535. > > Available on Saturday and Sunday for discussion. From owen at delong.com Mon Aug 8 15:25:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 13:25:41 -0700 Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> Message-ID: On Aug 7, 2011, at 3:09 PM, Jonathon Exley wrote: > This has probably been said before, but it makes me uncomfortable to think of everybody in the world being given /48 subnets by default. > All of a sudden that wide expanse of 2^128 IP addresses shrinks to 2^48 sites. Sure that's still 65535 times more than 2^32 IPv4 addresses, but wouldn't it be wise to apply some conservatism now to allow the IPv6 address space to last for many more years? > After all, there are only 4 bits of IP version field so the basic packet format won't last forever. > Let's look at this realistically. In 30+ years of internet development, giving IP addresses to lots of things besides just single sites, we still haven't completely used up the 32 bit space. This includes reserving 1/16th of it for unknown purposes that are never to be. 65,536 times enough space for all the sites we deployed in 30+ years will more than likely outlast the lifetime of the protocol, so, yeah, I'm OK with giving every end-site in the world (note an end-site is not a person, it's a building, structure, or tenant in a multi-tenant building or structure). Owen P.S. Jonathon: If anything in your email was confidential, too bad. You posted it to a public list. Silly notice at the bottom to that effect removed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dlr at bungi.com Mon Aug 8 15:36:50 2011 From: dlr at bungi.com (Dave Rand) Date: Mon, 8 Aug 2011 13:36:50 -0700 Subject: AT&T/SBC Global to AS13285 routing issue Message-ID: If someone from AT&T or SBC global could contact me off list, please? 2.96.0.0/13 is pretty much unreachable from portions of the Bay Area from the sbcglobal network. I've opened a couple of tickets on this, but no joy yet. Thank you -- From owen at delong.com Mon Aug 8 15:37:25 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 13:37:25 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> Message-ID: <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: > On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews wrote: >> So you want HE to force all their clients to renumber. > > No. I am simply pointing out that Owen exaggerated when he stated > that he implements the following three practices together on his own > networks: > * hierarchical addressing > * nibble-aligned addressing > * /48 per access customer > > You can simply read the last few messages in this thread to learn that > his recommendations on this list are not even practical for his > network today, because as Owen himself says, they are not yet able to > obtain additional RIR allocations. HE certainly operates a useful, > high-profile tunnel-broker service which is IMO a very great asset to > the Internet at-large; but if you spend a few minutes looking at the > publicly available statistics on this service, they average only > around 10,000 active tunnels across all their tunnel termination boxes > combined. They have not implemented the policies recommended by Owen > because, as he states, a /32 is not enough. > > Do I think the position he advocates will cause the eventual > exhaustion of IPv6? Well, let's do an exercise: > > There has been some rather simplistic arithmetic posted today, 300m > new subnets per year, etc. with zero consideration of address/subnet > utilization efficiency within ISP networks and individual aggregation > router pools. That is foolish. We can all pull out a calculator and > figure that 2000::/3 has space for 35 trillion /48 networks. That > isn't how they will be assigned or routed. > > The effect of 2011-3 is that an out-sized ISP like AT&T has every > justification for deciding to allocate 24 bits worth of subnet ID for > their "largest POP," say, one that happens to terminate layer-3 > services for all customers in an entire state. They then have policy > support for allocating the same sized subnet for every other POP, no > matter how small. After all, the RIR policy permits them to obtain > additional allocations as soon as one POP subnet has become full. > > So now you have a huge ISP with a few huge POPs, and a lot of small > ones, justified in assigning the same size aggregate prefix, suitable > for 2^24 subnets, to all those small POPs as well. How many layer-3 > POPs might this huge ISP have? Any number. It could be every central > office with some kind of layer-3 customer aggregation router. It > could even be every road-side hut for FTTH services. Perhaps they > will decide to address ten thousand POPs this way. > > Now the nibble-aligned language in the policy permits them to round up > from 10,000 POPs to 16 bits worth of address space for "POP ID." So > AT&T is quite justified in requesting: > 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 > (POP ID) == a /8 subnet for themselves. > Right up until you read: 6.5.3 (d): If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. As you can see, there is a safety valve in the policy at /12 for just this reason. > Now you can see how this policy, and addressing scheme, is utterly > brain-dead. It really does put you (and me, and everyone else) in > real danger of exhausting the IPv6 address space. All it takes is a > few out-sized ISPs, with one large POP each and a bunch of smaller > ones, applying for the maximum amount of address space permitted them > under 2011-3. > Even by your calculations, it would take 256 such outsized ISPs without a safety valve. With the safety valve that is built into the policy at /12, it would take 4,096 such ISPs. I do not believe that there are more than about 20 such ISPs world wide at this time and would put the foreseeable likely maximum at less than 100 due to the need for customers to support such outsized ISPs and the limited base that would have to be divided among them. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Mon Aug 8 15:51:32 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 13:51:32 -0700 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <43B27FC4-CFDB-475A-B11F-89062C15471B@delong.com> On Aug 8, 2011, at 1:15 AM, Mohacsi Janos wrote: > > > On Fri, 5 Aug 2011, Brian Mengel wrote: > >> In reviewing IPv6 end user allocation policies, I can find little >> agreement on what prefix length is appropriate for residential end >> users. /64 and /56 seem to be the favorite candidates, with /56 being >> slightly preferred. >> >> I am most curious as to why a /60 prefix is not considered when trying >> to address this problem. It provides 16 /64 subnetworks, which seems >> like an adequate amount for an end user. >> >> Does anyone have opinions on the BCP for end user addressing in IPv6? > > For business customers I would give /48 and home users who might have 1-2 subnet I would give /56 or /60. > Reasons: > - Business customers night grow where you have to provide bigger amount of subnet - allow space for future extension - > > - Home users - they usually don't know what is subnet. Setting up different subnets in their SOHO router can be difficult. Usually the simple 1 subnet for every device is enough for them. Separating some devices into a separate subnets is usually enough for the most sophisticated home users. If not then he can opt for business service?. > This utterly ignores the reality of DHCPv6, DHCP-PD, and technologies currently being developed for rational automatic hierarchies of topology. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Mon Aug 8 15:56:00 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 13:56:00 -0700 Subject: IPv6 end user addressing In-Reply-To: <174561.1312807412@turing-police.cc.vt.edu> References: <174561.1312807412@turing-police.cc.vt.edu> Message-ID: On Aug 8, 2011, at 5:43 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: > >> - Home users - they usually don't know what is subnet. Setting up >> different subnets in their SOHO router can be difficult. Usually the >> simple 1 subnet for every device is enough for them. Separating some >> devices into a separate subnets is usually enough for the most >> sophisticated home users. If not then he can opt for business service.... > > You don't want to make the assumption that just because Joe Sixpack doesn't > know what a subnet is, that Joe Sixpack's CPE doesn't know either. > > And remember that if it's 3 hops from one end of Joe Sixpack's internal net to > the other, you're gonna burn a few bits to support heirarchical routing so you > don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a > /56 by the provider, and it hands each device it sees a /60 in case it's a > device that routes too, it can only support 14 devices. And if one of the > things that got handed a /60 is a wireless access point or something, it's only > going to be able to support 15 or so subnets. So a simple topology of only a > half dozen devices can burn up 8 bits of subnet addressing real fast. Yes, you > can conserve bits by being more clever, but then you probably need an IGP of > some sort.... > > YOu lost a /60 somewhere in there? I understand 1 /60 for the primary device. You accounted for 14 /60s to other subordinate devices. Presumably the /64(s) that connect the other subordinate devices to the primary router are from within that first /60, so, where did the 16th /60 go? Finally, for things that are building automatic hierarchical topologies, it seems only sane to me that they would implement some form of OSPF to facilitate the routing. There's no reason that can't be equally automated. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Mon Aug 8 16:00:52 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 14:00:52 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <174561.1312807412@turing-police.cc.vt.edu> Message-ID: On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote: > > > On Mon, 8 Aug 2011, Valdis.Kletnieks at vt.edu wrote: > >> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: >> >>> - Home users - they usually don't know what is subnet. Setting up >>> different subnets in their SOHO router can be difficult. Usually the >>> simple 1 subnet for every device is enough for them. Separating some >>> devices into a separate subnets is usually enough for the most >>> sophisticated home users. If not then he can opt for business service.... >> >> You don't want to make the assumption that just because Joe Sixpack doesn't >> know what a subnet is, that Joe Sixpack's CPE doesn't know either. >> >> And remember that if it's 3 hops from one end of Joe Sixpack's internal net to >> the other, you're gonna burn a few bits to support heirarchical routing so you >> don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a >> /56 by the provider, and it hands each device it sees a /60 in case it's a >> device that routes too, it can only support 14 devices. And if one of the > > more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices.... > > I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary? > > I can see things like wanting to have an entertainment systems network that is fronted by a router with additional networks for each entertainment system fronted by their own router, segmentation of various appliance networks with possibly an appliance front-end router, etc. There are lots of possibilities we haven't thought of here yet. Limiting end-users to /56 or worse will only stifle the innovation that will help us identify the possibilities. For this, if no other reason, (and I cite the limitations under which we have begun to frame our assumptions about how the internet works as a result of NAT as an example), I think we should avoid preserving this cultural conditioning in IPv6. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From sven at cb3rob.net Mon Aug 8 17:52:03 2011 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Mon, 8 Aug 2011 22:52:03 +0000 (UTC) Subject: IPv6 end user addressing In-Reply-To: <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> Message-ID: we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big"). - nobody wants to use dynamic ips on -servers- or -router links- anyway i -really- can't see why people don't just use subnets with just the required number of addresses. take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size) etc. no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;) we don't use /24's for -everything- on ipv4 now do we :P (oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Mon, 8 Aug 2011, Owen DeLong wrote: > > On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: > >> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews wrote: >>> So you want HE to force all their clients to renumber. >> >> No. I am simply pointing out that Owen exaggerated when he stated >> that he implements the following three practices together on his own >> networks: >> * hierarchical addressing >> * nibble-aligned addressing >> * /48 per access customer >> >> You can simply read the last few messages in this thread to learn that >> his recommendations on this list are not even practical for his >> network today, because as Owen himself says, they are not yet able to >> obtain additional RIR allocations. HE certainly operates a useful, >> high-profile tunnel-broker service which is IMO a very great asset to >> the Internet at-large; but if you spend a few minutes looking at the >> publicly available statistics on this service, they average only >> around 10,000 active tunnels across all their tunnel termination boxes >> combined. They have not implemented the policies recommended by Owen >> because, as he states, a /32 is not enough. >> >> Do I think the position he advocates will cause the eventual >> exhaustion of IPv6? Well, let's do an exercise: >> >> There has been some rather simplistic arithmetic posted today, 300m >> new subnets per year, etc. with zero consideration of address/subnet >> utilization efficiency within ISP networks and individual aggregation >> router pools. That is foolish. We can all pull out a calculator and >> figure that 2000::/3 has space for 35 trillion /48 networks. That >> isn't how they will be assigned or routed. >> >> The effect of 2011-3 is that an out-sized ISP like AT&T has every >> justification for deciding to allocate 24 bits worth of subnet ID for >> their "largest POP," say, one that happens to terminate layer-3 >> services for all customers in an entire state. They then have policy >> support for allocating the same sized subnet for every other POP, no >> matter how small. After all, the RIR policy permits them to obtain >> additional allocations as soon as one POP subnet has become full. >> >> So now you have a huge ISP with a few huge POPs, and a lot of small >> ones, justified in assigning the same size aggregate prefix, suitable >> for 2^24 subnets, to all those small POPs as well. How many layer-3 >> POPs might this huge ISP have? Any number. It could be every central >> office with some kind of layer-3 customer aggregation router. It >> could even be every road-side hut for FTTH services. Perhaps they >> will decide to address ten thousand POPs this way. >> >> Now the nibble-aligned language in the policy permits them to round up >> from 10,000 POPs to 16 bits worth of address space for "POP ID." So >> AT&T is quite justified in requesting: >> 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 >> (POP ID) == a /8 subnet for themselves. >> > Right up until you read: > > 6.5.3 (d): > If an LIR has already reached a /12 or more, ARIN will > allocate a single additional /12 rather than continue > expanding nibble boundaries. > As you can see, there is a safety valve in the policy at /12 for just > this reason. > > >> Now you can see how this policy, and addressing scheme, is utterly >> brain-dead. It really does put you (and me, and everyone else) in >> real danger of exhausting the IPv6 address space. All it takes is a >> few out-sized ISPs, with one large POP each and a bunch of smaller >> ones, applying for the maximum amount of address space permitted them >> under 2011-3. >> > > Even by your calculations, it would take 256 such outsized ISPs without > a safety valve. With the safety valve that is built into the policy at /12, > it would take 4,096 such ISPs. I do not believe that there are more than > about 20 such ISPs world wide at this time and would put the foreseeable > likely maximum at less than 100 due to the need for customers to support > such outsized ISPs and the limited base that would have to be divided > among them. > > Owen > > From Jonathon.Exley at kordia.co.nz Mon Aug 8 18:24:03 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Tue, 9 Aug 2011 11:24:03 +1200 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> Message-ID: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam. Jonathon. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, 9 August 2011 8:26 a.m. To: Jonathon Exley Cc: nanog at nanog.org Subject: Re: IPv6 end user addressing [snip] P.S. Jonathon: If anything in your email was confidential, too bad. You posted it to a public list. Silly notice at the bottom to that effect removed. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From morrowc.lists at gmail.com Mon Aug 8 18:24:35 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 8 Aug 2011 19:24:35 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <4E3DF274.6050709@ispalliance.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms wrote: > Not trying to be obtuse, but none of the technical docs you cite appear to > talk about HTTP proxies nor does the newswire report have any technical > details. ?I have tested several of the networks listed in the report and in > none of the cases I saw was there HTTP proxy activity. ?Picking up on > WCCP/TCS isn't that hard (I used to install those myself) so unless there is > some functionality in IOS and/or JUNOS that allows I don't see it happening. > ?Paxfire can operate all of the proxies they want but the network > infrastructure has to be able to pass the traffic over to those proxies and > I don't see it (on at least 3 of the networks cited). barefruit/paxfire/nominum/etc all do essentially the same thing: 1) install a dns-appliance in-line (some form of in-line, there are lots of options, it's not really important in the end which is used) between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire appliance literally in-line between it's customer facing port and the world) 2) chose a set/subset of queries to falsify answers for (nxdomain only? autosearch.msn.com? *.google.com? *?) 3) run a farm of servers somewhere else (in the case of paxfire they are the jomax.net servers: ;; QUESTION SECTION: ;asdkjad912jd.123adsad.com. IN A ;; ANSWER SECTION: asdkjad912jd.123adsad.com. 60 IN A 64.158.56.49 asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49 ;; AUTHORITY SECTION: asdkjad912jd.123adsad.com. 65535 IN NS WSC2.JOMAX.NET. asdkjad912jd.123adsad.com. 65535 IN NS WSC1.JOMAX.NET. In the case of barefruit it's another complex and in the case of nominum it's a third complex ... 4) accept http/https/etc on the complex of servers, funnel you an answer which is essentially 'hostname == search-query'. For non-http most of these complexes are SUPPOSED to not permit a connect to happen... for jomax at least they don't accept tcp/443, they do accept 25 though :( 5) profit if users click on these results. It's not black magic, it's annoying and wrong for some versions (depending upon your ethics I guess?) of wrong :( I wish ISP's would stop doing this, and it seems that some folk have luck twisting arms at ISP's to make this stop. -chris From bill at herrin.us Mon Aug 8 18:27:20 2011 From: bill at herrin.us (William Herrin) Date: Mon, 8 Aug 2011 19:27:20 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> Message-ID: On Mon, Aug 8, 2011 at 6:52 PM, Sven Olaf Kamphuis wrote: > we assign /112 per "end user vlan (or server)" at this moment... works > perfectly fine (and thats even "a bit too big"). > > - nobody wants to use dynamic ips on -servers- or -router links- anyway > > i -really- can't see why people don't just use subnets with just the > required number of addresses. Hi Sven, Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP address is static but tied to the ethernet card) does not work unless the subnet mask is exactly /64. Even on a server lan you'll occasionally want to plug in a PC for diagnostics without having to poke in an IP address by hand. There are some great reasons to use a /112s or even smaller blocks for some applications. Use them that way, sure. But IMHO it's short-sighted to _assign_ address blocks at that size -- it means the person downstream has to come back to you and waste your time when they want to do anything else. And your choice delays them and wastes their time as well -- a fine "customer service" indeed. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rcarpen at network1.net Mon Aug 8 18:34:50 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 08 Aug 2011 19:34:50 -0400 (EDT) Subject: IPv6 end user addressing In-Reply-To: Message-ID: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net> I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? If true, it would make /64s even more attractive. -Randy ----- Original Message ----- > we assign /112 per "end user vlan (or server)" at this moment... > works > perfectly fine (and thats even "a bit too big"). > > - nobody wants to use dynamic ips on -servers- or -router links- > anyway > > i -really- can't see why people don't just use subnets with just the > required number of addresses. > > take one /64 (for /64's sake ;), split it up into subnets which each > have > the required number of addresses (lets say you have 2-4 addresses for > each > bgp/router link, so you simply split it up into subnets that size) > > etc. > > no need to use /64 for -everything- at all, just because it fits > (ethernet) mac addresses (as if ethernet will be around longer than > ipv6 > ha-ha, someone will come up with something faster tomorrow and then > its > bye bye ethernet, the 10ge variant is getting slow, and the 100ge > variant > is not even standardized yet, and trunking is a bottleneck ;) > > we don't use /24's for -everything- on ipv4 now do we :P > > (oh wait, there once was a time where we did.. due to another > retarded > semi-automatic configuration thingy, called RIP , which also only > seemed > to understand /24 or bigger ;) > > -- > Greetings, > > Sven Olaf Kamphuis, > CB3ROB Ltd. & Co. KG > ========================================================================= > Address: Koloniestrasse 34 VAT Tax ID: DE267268209 > D-13359 Registration: HRA 42834 B > BERLIN Phone: > +31/(0)87-8747479 > Germany GSM: > +49/(0)152-26410799 > RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net > ========================================================================= > C3P0, der elektrische Westerwelle > http://www.facebook.com/cb3rob > ========================================================================= > > Confidential: Please be advised that the information contained in > this > email message, including all attached documents or files, is > privileged > and confidential and is intended only for the use of the individual > or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > > > On Mon, 8 Aug 2011, Owen DeLong wrote: > > > > > On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: > > > >> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews > >> wrote: > >>> So you want HE to force all their clients to renumber. > >> > >> No. I am simply pointing out that Owen exaggerated when he stated > >> that he implements the following three practices together on his > >> own > >> networks: > >> * hierarchical addressing > >> * nibble-aligned addressing > >> * /48 per access customer > >> > >> You can simply read the last few messages in this thread to learn > >> that > >> his recommendations on this list are not even practical for his > >> network today, because as Owen himself says, they are not yet able > >> to > >> obtain additional RIR allocations. HE certainly operates a > >> useful, > >> high-profile tunnel-broker service which is IMO a very great asset > >> to > >> the Internet at-large; but if you spend a few minutes looking at > >> the > >> publicly available statistics on this service, they average only > >> around 10,000 active tunnels across all their tunnel termination > >> boxes > >> combined. They have not implemented the policies recommended by > >> Owen > >> because, as he states, a /32 is not enough. > >> > >> Do I think the position he advocates will cause the eventual > >> exhaustion of IPv6? Well, let's do an exercise: > >> > >> There has been some rather simplistic arithmetic posted today, > >> 300m > >> new subnets per year, etc. with zero consideration of > >> address/subnet > >> utilization efficiency within ISP networks and individual > >> aggregation > >> router pools. That is foolish. We can all pull out a calculator > >> and > >> figure that 2000::/3 has space for 35 trillion /48 networks. That > >> isn't how they will be assigned or routed. > >> > >> The effect of 2011-3 is that an out-sized ISP like AT&T has every > >> justification for deciding to allocate 24 bits worth of subnet ID > >> for > >> their "largest POP," say, one that happens to terminate layer-3 > >> services for all customers in an entire state. They then have > >> policy > >> support for allocating the same sized subnet for every other POP, > >> no > >> matter how small. After all, the RIR policy permits them to > >> obtain > >> additional allocations as soon as one POP subnet has become full. > >> > >> So now you have a huge ISP with a few huge POPs, and a lot of > >> small > >> ones, justified in assigning the same size aggregate prefix, > >> suitable > >> for 2^24 subnets, to all those small POPs as well. How many > >> layer-3 > >> POPs might this huge ISP have? Any number. It could be every > >> central > >> office with some kind of layer-3 customer aggregation router. It > >> could even be every road-side hut for FTTH services. Perhaps they > >> will decide to address ten thousand POPs this way. > >> > >> Now the nibble-aligned language in the policy permits them to > >> round up > >> from 10,000 POPs to 16 bits worth of address space for "POP ID." > >> So > >> AT&T is quite justified in requesting: > >> 48 (customer subnet length) - 24 (largest POP subnet ID size) - > >> 16 > >> (POP ID) == a /8 subnet for themselves. > >> > > Right up until you read: > > > > 6.5.3 (d): > > If an LIR has already reached a /12 or more, ARIN will > > allocate a single additional /12 rather than continue > > expanding nibble boundaries. > > As you can see, there is a safety valve in the policy at /12 for > > just > > this reason. > > > > > >> Now you can see how this policy, and addressing scheme, is utterly > >> brain-dead. It really does put you (and me, and everyone else) in > >> real danger of exhausting the IPv6 address space. All it takes is > >> a > >> few out-sized ISPs, with one large POP each and a bunch of smaller > >> ones, applying for the maximum amount of address space permitted > >> them > >> under 2011-3. > >> > > > > Even by your calculations, it would take 256 such outsized ISPs > > without > > a safety valve. With the safety valve that is built into the policy > > at /12, > > it would take 4,096 such ISPs. I do not believe that there are more > > than > > about 20 such ISPs world wide at this time and would put the > > foreseeable > > likely maximum at less than 100 due to the need for customers to > > support > > such outsized ISPs and the limited base that would have to be > > divided > > among them. > > > > Owen > > > > > > > From cb.list6 at gmail.com Mon Aug 8 18:47:23 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 8 Aug 2011 16:47:23 -0700 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: On Aug 8, 2011 4:24 PM, "Christopher Morrow" wrote: > > On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms wrote: > > Not trying to be obtuse, but none of the technical docs you cite appear to > > talk about HTTP proxies nor does the newswire report have any technical > > details. I have tested several of the networks listed in the report and in > > none of the cases I saw was there HTTP proxy activity. Picking up on > > WCCP/TCS isn't that hard (I used to install those myself) so unless there is > > some functionality in IOS and/or JUNOS that allows I don't see it happening. > > Paxfire can operate all of the proxies they want but the network > > infrastructure has to be able to pass the traffic over to those proxies and > > I don't see it (on at least 3 of the networks cited). > > barefruit/paxfire/nominum/etc all do essentially the same thing: > 1) install a dns-appliance in-line (some form of in-line, there are > lots of options, it's not really important in the end which is used) > between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire > appliance literally in-line between it's customer facing port and the > world) > > 2) chose a set/subset of queries to falsify answers for (nxdomain > only? autosearch.msn.com? *.google.com? *?) > > 3) run a farm of servers somewhere else (in the case of paxfire they > are the jomax.net servers: > ;; QUESTION SECTION: > ;asdkjad912jd.123adsad.com. IN A > ;; ANSWER SECTION: > asdkjad912jd.123adsad.com. 60 IN A 64.158.56.49 > asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49 > ;; AUTHORITY SECTION: > asdkjad912jd.123adsad.com. 65535 IN NS WSC2.JOMAX.NET. > asdkjad912jd.123adsad.com. 65535 IN NS WSC1.JOMAX.NET. > > In the case of barefruit it's another complex and in the case of > nominum it's a third complex ... > > 4) accept http/https/etc on the complex of servers, funnel you an > answer which is essentially 'hostname == search-query'. For non-http > most of these complexes are SUPPOSED to not permit a connect to > happen... for jomax at least they don't accept tcp/443, they do accept > 25 though :( > > 5) profit if users click on these results. > > It's not black magic, it's annoying and wrong for some versions > (depending upon your ethics I guess?) of wrong :( I wish ISP's would > stop doing this, and it seems that some folk have luck twisting arms > at ISP's to make this stop. > > -chris > Some people believe the search results are a better user experience than the error page they would otherwise receive. The "awesome bar" is a similar feature....imho Cb From lists at pinetree.net Mon Aug 8 18:57:05 2011 From: lists at pinetree.net (Oren Levin) Date: Mon, 08 Aug 2011 19:57:05 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <20110807161029.GA50031@gweep.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <20110807161029.GA50031@gweep.net> Message-ID: <4E4077D1.9060803@pinetree.net> On 8/7/11 12:10 PM, Joe Provo wrote: > This is finally something new, and I retract my assertion that the new > scientist got it wrong. Drilling through to actual evidence and > details, rather than descriptions which match previous behavior, we > have both > http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a > little indirect with 'example.com', etc) and > http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual > domains) provide detail on the matter. Cheers! Joe I noticed that the payne.org link calls out the insertion of an Amazon affiliate code. Section 7 of the Amazon affiliate agreement (https://affiliate-program.amazon.com/gp/associates/agreement) appears to explicitly prohibit payment for this type of traffic. Oren From owen at delong.com Mon Aug 8 19:07:46 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 17:07:46 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> Message-ID: <07F47B3A-8F10-44AB-A92F-D4AB93C73C8D@delong.com> On Aug 8, 2011, at 3:52 PM, Sven Olaf Kamphuis wrote: > we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too big"). > Sigh? Too big for what? > - nobody wants to use dynamic ips on -servers- or -router links- anyway > True? Guess what? Static addresses work in /64s as well. Better yet, your /64 will support adding troubleshooting equipment rapidly without having to hunt for an available address. > i -really- can't see why people don't just use subnets with just the required number of addresses. > Because we see real advantages to sparse addressing? Because it would make our lives unnecessarily more complicated? Because it will lead to additional human factors issues in most environments with more than a single administrator and likely even in cases where it is a single administrator? Because it reduces the potential for better automation? I'm sure there are more reasons, but, these are just a few that come to mind off the top of my head. > take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size) > The point of this being? What do you gain by doing this? I've shown you at least a few things you lose. > etc. > > no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;) > The /64 was chosen because it fits EUI-64 addresses. Ethernet MAC addresses are EUI-48. Examples of network technologies that use EUI-64 include Firewire, Zigbee, 6lowpan, etc. So this argument is rather specious and orthogonal to your supposed point. > we don't use /24's for -everything- on ipv4 now do we :P > Right.. We ran out of IPv4 and stopped doing that in order to artificially extend its life. > (oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;) > The issuance of /24s was _NOT_ driven by RIP. Rather, the architecture of RIP was driven by glassful addressing assumptions. There were many other reasons for classful addressing and it still retains some of those advantages. Owen > > Confidential: Please be advised that the information contained in this > email message, including all attached documents or files, is privileged > and confidential and is intended only for the use of the individual or > individuals addressed. Any other use, dissemination, distribution or > copying of this communication is strictly prohibited. > Guess you shouldn't have published it to a public list then. > > On Mon, 8 Aug 2011, Owen DeLong wrote: > >> >> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: >> >>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews wrote: >>>> So you want HE to force all their clients to renumber. >>> >>> No. I am simply pointing out that Owen exaggerated when he stated >>> that he implements the following three practices together on his own >>> networks: >>> * hierarchical addressing >>> * nibble-aligned addressing >>> * /48 per access customer >>> >>> You can simply read the last few messages in this thread to learn that >>> his recommendations on this list are not even practical for his >>> network today, because as Owen himself says, they are not yet able to >>> obtain additional RIR allocations. HE certainly operates a useful, >>> high-profile tunnel-broker service which is IMO a very great asset to >>> the Internet at-large; but if you spend a few minutes looking at the >>> publicly available statistics on this service, they average only >>> around 10,000 active tunnels across all their tunnel termination boxes >>> combined. They have not implemented the policies recommended by Owen >>> because, as he states, a /32 is not enough. >>> >>> Do I think the position he advocates will cause the eventual >>> exhaustion of IPv6? Well, let's do an exercise: >>> >>> There has been some rather simplistic arithmetic posted today, 300m >>> new subnets per year, etc. with zero consideration of address/subnet >>> utilization efficiency within ISP networks and individual aggregation >>> router pools. That is foolish. We can all pull out a calculator and >>> figure that 2000::/3 has space for 35 trillion /48 networks. That >>> isn't how they will be assigned or routed. >>> >>> The effect of 2011-3 is that an out-sized ISP like AT&T has every >>> justification for deciding to allocate 24 bits worth of subnet ID for >>> their "largest POP," say, one that happens to terminate layer-3 >>> services for all customers in an entire state. They then have policy >>> support for allocating the same sized subnet for every other POP, no >>> matter how small. After all, the RIR policy permits them to obtain >>> additional allocations as soon as one POP subnet has become full. >>> >>> So now you have a huge ISP with a few huge POPs, and a lot of small >>> ones, justified in assigning the same size aggregate prefix, suitable >>> for 2^24 subnets, to all those small POPs as well. How many layer-3 >>> POPs might this huge ISP have? Any number. It could be every central >>> office with some kind of layer-3 customer aggregation router. It >>> could even be every road-side hut for FTTH services. Perhaps they >>> will decide to address ten thousand POPs this way. >>> >>> Now the nibble-aligned language in the policy permits them to round up >>> from 10,000 POPs to 16 bits worth of address space for "POP ID." So >>> AT&T is quite justified in requesting: >>> 48 (customer subnet length) - 24 (largest POP subnet ID size) - 16 >>> (POP ID) == a /8 subnet for themselves. >>> >> Right up until you read: >> >> 6.5.3 (d): >> If an LIR has already reached a /12 or more, ARIN will >> allocate a single additional /12 rather than continue >> expanding nibble boundaries. >> As you can see, there is a safety valve in the policy at /12 for just >> this reason. >> >> >>> Now you can see how this policy, and addressing scheme, is utterly >>> brain-dead. It really does put you (and me, and everyone else) in >>> real danger of exhausting the IPv6 address space. All it takes is a >>> few out-sized ISPs, with one large POP each and a bunch of smaller >>> ones, applying for the maximum amount of address space permitted them >>> under 2011-3. >>> >> >> Even by your calculations, it would take 256 such outsized ISPs without >> a safety valve. With the safety valve that is built into the policy at /12, >> it would take 4,096 such ISPs. I do not believe that there are more than >> about 20 such ISPs world wide at this time and would put the foreseeable >> likely maximum at less than 100 due to the need for customers to support >> such outsized ISPs and the limited base that would have to be divided >> among them. >> >> Owen >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Mon Aug 8 19:14:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Aug 2011 17:14:35 -0700 Subject: IPv6 end user addressing In-Reply-To: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net> References: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net> Message-ID: <4E8F95EB-4568-49CB-BADB-5365FBAE8D15@delong.com> I'm sure there will be platforms that end up on both sides of this question. YES: We made a less expensive box by cutting the width of the TCAM required in half. NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed. I'm sure the market will chose products from both sides of the line for the same reasons. Owen On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: > > I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? > > If true, it would make /64s even more attractive. > > -Randy > > > ----- Original Message ----- >> we assign /112 per "end user vlan (or server)" at this moment... >> works >> perfectly fine (and thats even "a bit too big"). >> >> - nobody wants to use dynamic ips on -servers- or -router links- >> anyway >> >> i -really- can't see why people don't just use subnets with just the >> required number of addresses. >> >> take one /64 (for /64's sake ;), split it up into subnets which each >> have >> the required number of addresses (lets say you have 2-4 addresses for >> each >> bgp/router link, so you simply split it up into subnets that size) >> >> etc. >> >> no need to use /64 for -everything- at all, just because it fits >> (ethernet) mac addresses (as if ethernet will be around longer than >> ipv6 >> ha-ha, someone will come up with something faster tomorrow and then >> its >> bye bye ethernet, the 10ge variant is getting slow, and the 100ge >> variant >> is not even standardized yet, and trunking is a bottleneck ;) >> >> we don't use /24's for -everything- on ipv4 now do we :P >> >> (oh wait, there once was a time where we did.. due to another >> retarded >> semi-automatic configuration thingy, called RIP , which also only >> seemed >> to understand /24 or bigger ;) >> >> -- >> Greetings, >> >> Sven Olaf Kamphuis, >> CB3ROB Ltd. & Co. KG >> ========================================================================= >> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >> D-13359 Registration: HRA 42834 B >> BERLIN Phone: >> +31/(0)87-8747479 >> Germany GSM: >> +49/(0)152-26410799 >> RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net >> ========================================================================= >> C3P0, der elektrische Westerwelle >> http://www.facebook.com/cb3rob >> ========================================================================= >> >> Confidential: Please be advised that the information contained in >> this >> email message, including all attached documents or files, is >> privileged >> and confidential and is intended only for the use of the individual >> or >> individuals addressed. Any other use, dissemination, distribution or >> copying of this communication is strictly prohibited. >> >> >> On Mon, 8 Aug 2011, Owen DeLong wrote: >> >>> >>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: >>> >>>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews >>>> wrote: >>>>> So you want HE to force all their clients to renumber. >>>> >>>> No. I am simply pointing out that Owen exaggerated when he stated >>>> that he implements the following three practices together on his >>>> own >>>> networks: >>>> * hierarchical addressing >>>> * nibble-aligned addressing >>>> * /48 per access customer >>>> >>>> You can simply read the last few messages in this thread to learn >>>> that >>>> his recommendations on this list are not even practical for his >>>> network today, because as Owen himself says, they are not yet able >>>> to >>>> obtain additional RIR allocations. HE certainly operates a >>>> useful, >>>> high-profile tunnel-broker service which is IMO a very great asset >>>> to >>>> the Internet at-large; but if you spend a few minutes looking at >>>> the >>>> publicly available statistics on this service, they average only >>>> around 10,000 active tunnels across all their tunnel termination >>>> boxes >>>> combined. They have not implemented the policies recommended by >>>> Owen >>>> because, as he states, a /32 is not enough. >>>> >>>> Do I think the position he advocates will cause the eventual >>>> exhaustion of IPv6? Well, let's do an exercise: >>>> >>>> There has been some rather simplistic arithmetic posted today, >>>> 300m >>>> new subnets per year, etc. with zero consideration of >>>> address/subnet >>>> utilization efficiency within ISP networks and individual >>>> aggregation >>>> router pools. That is foolish. We can all pull out a calculator >>>> and >>>> figure that 2000::/3 has space for 35 trillion /48 networks. That >>>> isn't how they will be assigned or routed. >>>> >>>> The effect of 2011-3 is that an out-sized ISP like AT&T has every >>>> justification for deciding to allocate 24 bits worth of subnet ID >>>> for >>>> their "largest POP," say, one that happens to terminate layer-3 >>>> services for all customers in an entire state. They then have >>>> policy >>>> support for allocating the same sized subnet for every other POP, >>>> no >>>> matter how small. After all, the RIR policy permits them to >>>> obtain >>>> additional allocations as soon as one POP subnet has become full. >>>> >>>> So now you have a huge ISP with a few huge POPs, and a lot of >>>> small >>>> ones, justified in assigning the same size aggregate prefix, >>>> suitable >>>> for 2^24 subnets, to all those small POPs as well. How many >>>> layer-3 >>>> POPs might this huge ISP have? Any number. It could be every >>>> central >>>> office with some kind of layer-3 customer aggregation router. It >>>> could even be every road-side hut for FTTH services. Perhaps they >>>> will decide to address ten thousand POPs this way. >>>> >>>> Now the nibble-aligned language in the policy permits them to >>>> round up >>>> from 10,000 POPs to 16 bits worth of address space for "POP ID." >>>> So >>>> AT&T is quite justified in requesting: >>>> 48 (customer subnet length) - 24 (largest POP subnet ID size) - >>>> 16 >>>> (POP ID) == a /8 subnet for themselves. >>>> >>> Right up until you read: >>> >>> 6.5.3 (d): >>> If an LIR has already reached a /12 or more, ARIN will >>> allocate a single additional /12 rather than continue >>> expanding nibble boundaries. >>> As you can see, there is a safety valve in the policy at /12 for >>> just >>> this reason. >>> >>> >>>> Now you can see how this policy, and addressing scheme, is utterly >>>> brain-dead. It really does put you (and me, and everyone else) in >>>> real danger of exhausting the IPv6 address space. All it takes is >>>> a >>>> few out-sized ISPs, with one large POP each and a bunch of smaller >>>> ones, applying for the maximum amount of address space permitted >>>> them >>>> under 2011-3. >>>> >>> >>> Even by your calculations, it would take 256 such outsized ISPs >>> without >>> a safety valve. With the safety valve that is built into the policy >>> at /12, >>> it would take 4,096 such ISPs. I do not believe that there are more >>> than >>> about 20 such ISPs world wide at this time and would put the >>> foreseeable >>> likely maximum at less than 100 due to the need for customers to >>> support >>> such outsized ISPs and the limited base that would have to be >>> divided >>> among them. >>> >>> Owen >>> >>> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From mmc at internode.com.au Mon Aug 8 19:42:12 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Tue, 9 Aug 2011 00:42:12 +0000 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <582549A2-0F6C-47BB-AB41-4079DE554277@internode.com.au> Hi Brian, >From someone who's actually done this. - Our customer base is primarily PPP connected broadband users (variety of technologies, mostly ADSL). - We do a DYNAMIC /64 on the PPP interface so that people who terminate directly on a PC can get IPv6 without DHCPv6 PD. - In addition for the subnet assigned via DHCPv6 Prefix delegation which is STATIC as that's what customers have been asking for: In our trial phase we did /60s to customers - this worked just fine. I don't recall anyone actually saying "I need more". (The /60 was the first nibble boundary and it allowed us to do some dumb things for allocation which didn't compromise the allocation strategy later). In production we've chosen a more conventional /56. At some point it becomes a little arbitrary. Our feeling is that at the point your have 256 /64s in production then ADSL is probably NOT what you need or want as a technology so we can do things differently for ethernet connected customers. We're getting there with support for customers bringing their own PI space. (For an idea of scale - we're tiny globally, but have around 250k customers across mainly Australia. We run our own global dualstack network). MMC On 06/08/2011, at 1:47 AM, Brian Mengel wrote: In reviewing IPv6 end user allocation policies, I can find little agreement on what prefix length is appropriate for residential end users. /64 and /56 seem to be the favorite candidates, with /56 being slightly preferred. I am most curious as to why a /60 prefix is not considered when trying to address this problem. It provides 16 /64 subnetworks, which seems like an adequate amount for an end user. Does anyone have opinions on the BCP for end user addressing in IPv6? -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From malayter at gmail.com Mon Aug 8 19:43:50 2011 From: malayter at gmail.com (Ryan Malayter) Date: Mon, 8 Aug 2011 17:43:50 -0700 (PDT) Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> Message-ID: <4abb5fd5-77a5-4d67-b079-5ebabcb430dc@a10g2000yqn.googlegroups.com> On Aug 8, 6:24?pm, Jonathon Exley wrote: > Silly confidentiality notices are usually enforced by silly > corporate IT departments Oh, no, it's the *legal* department (or maybe HR) that is to blame. I actually had a guardhouse lawyer kick and scream about us not putting disclaimers on our emails. I told him, "You do realize that email disclaimers have no legal standing, have never been successfully used in any litigation, do nothing to prevent loss of corporate assets, and actually increase our liability by outlining a corporate policy that may not be followed 100% internally by all employees, right?" It took a long while and an embarrassing number of meetings with senior management, but we eventually put a stop to the whole thing. From morrowc.lists at gmail.com Mon Aug 8 19:56:32 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 8 Aug 2011 20:56:32 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: On Mon, Aug 8, 2011 at 7:47 PM, Cameron Byrne wrote: > > On Aug 8, 2011 4:24 PM, "Christopher Morrow" > wrote: >> >> On Sat, Aug 6, 2011 at 10:03 PM, Scott Helms >> wrote: >> > Not trying to be obtuse, but none of the technical docs you cite appear >> > to >> > talk about HTTP proxies nor does the newswire report have any technical >> > details. ?I have tested several of the networks listed in the report and >> > in >> > none of the cases I saw was there HTTP proxy activity. ?Picking up on >> > WCCP/TCS isn't that hard (I used to install those myself) so unless >> > there is >> > some functionality in IOS and/or JUNOS that allows I don't see it >> > happening. >> > ?Paxfire can operate all of the proxies they want but the network >> > infrastructure has to be able to pass the traffic over to those proxies >> > and >> > I don't see it (on at least 3 of the networks cited). >> >> barefruit/paxfire/nominum/etc all do essentially the same thing: >> 1) install a dns-appliance in-line (some form of in-line, there are >> lots of options, it's not really important in the end which is used) >> between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire >> appliance literally in-line between it's customer facing port and the >> world) >> >> 2) chose a set/subset of queries to falsify answers for (nxdomain >> only? autosearch.msn.com? *.google.com? *?) >> >> 3) run a farm of servers somewhere else (in the case of paxfire they >> are the jomax.net servers: >> ?;; QUESTION SECTION: >> ;asdkjad912jd.123adsad.com. ? ? IN ? ? ?A >> ;; ANSWER SECTION: >> asdkjad912jd.123adsad.com. 60 ? IN ? ? ?A ? ? ? 64.158.56.49 >> asdkjad912jd.123adsad.com. 60 ? IN ? ? ?A ? ? ? 63.251.179.49 >> ;; AUTHORITY SECTION: >> asdkjad912jd.123adsad.com. 65535 IN ? ? NS ? ? ?WSC2.JOMAX.NET. >> asdkjad912jd.123adsad.com. 65535 IN ? ? NS ? ? ?WSC1.JOMAX.NET. >> >> ?In the case of barefruit it's another complex and in the case of >> nominum it's a third complex ... >> >> 4) accept http/https/etc on the complex of servers, funnel you an >> answer which is essentially 'hostname == search-query'. For non-http >> most of these complexes are SUPPOSED to not permit a connect to >> happen... for jomax at least they don't accept tcp/443, they do accept >> 25 though :( >> >> 5) profit if users click on these results. >> >> It's not black magic, it's annoying and wrong for some versions >> (depending upon your ethics I guess?) of wrong :( I wish ISP's would >> stop doing this, and it seems that some folk have luck twisting arms >> at ISP's to make this stop. >> >> -chris >> > > Some people believe the search results are a better user experience than the > error page they would otherwise receive.? The "awesome bar" is a similar > feature....imho sure, but users requested that 'feature' and it's there for only http/https traffic. it's not being done at the lower layers of the stack, for all applications off the client machine. messing with basic plumbing will have unintended consequences, they will be bad. If the users her WANT to have this experience, there are lots of in-browser/application methods to achieve this, hijacking DNS at the resolver is really just NOT the right answer, ever. -chris From morrowc.lists at gmail.com Mon Aug 8 19:57:10 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 8 Aug 2011 20:57:10 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: <4E4077D1.9060803@pinetree.net> References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <20110807161029.GA50031@gweep.net> <4E4077D1.9060803@pinetree.net> Message-ID: On Mon, Aug 8, 2011 at 7:57 PM, Oren Levin wrote: > On 8/7/11 12:10 PM, Joe Provo wrote: >> >> This is finally something new, and I retract my assertion that the new >> scientist got it wrong. Drilling through to actual evidence and details, >> rather than descriptions which match previous behavior, we have both >> http://www.usenix.org/event/leet11/tech/full_papers/Zhang.pdf (a little >> indirect with 'example.com', etc) and >> http://www.payne.org/index.php/Frontier_Search_Hijacking (with actual >> domains) provide detail on the matter. Cheers! Joe > > I noticed that the payne.org link calls out the insertion of an Amazon > affiliate code. Section 7 of the Amazon affiliate agreement > (https://affiliate-program.amazon.com/gp/associates/agreement) appears to > explicitly prohibit payment for this type of traffic. interesting, one wonders if maybe amazon will 'do the right thing' (much like they did with wikileaks?) and remove the account's access. From arturo.servin at gmail.com Mon Aug 8 21:09:47 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 8 Aug 2011 23:09:47 -0300 Subject: Errant Advertisement - 128.1/16 In-Reply-To: References: <75C5AC31-3F4F-437B-A199-1D6BA6FA5D6E@bbn.com> Message-ID: They also made Interface Message Processors, like the grandpas of routers. .as On 8 Aug 2011, at 12:29, Peter Stockli wrote: > Wow, BBN, the reason we use the @ sign, second .com Domain, former AS1. > > Lots of history ;) > > On Mon, Aug 8, 2011 at 2:07 PM, Rick Altmann wrote: > >> This issue has been cleared up. Thanks to everyone for their help. >> >> -Rick >> >> On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote: >> >>> Is there anyone from AT&T on the list that could help with a likely >> misconfiguration? I have not received any response yet to my complaint (see >> below) submitted to the abuse address on July 26. We have since started >> advertising this space and would like to resolve the MOAS condition we have >> created. >>> >>> //////////////// >>> >>> The 128.1.0.0/16 address block is registered to BBN Technologies >> (AS11488) but is currently unused on any BBN networks. BBN would like to >> begin using this address space however AS7018 is currently originating >> public BGP routes for this address block. We believe this to be a >> configuration error. Please help us resolve this. >>> >>> A traceroute to 128.1.0.1 shows the following routers as the last 4 >> responding hops: >>> >>> cr1.n54ny.ip.att.net (12.122.81.106) >>> cr81.nw2nj.ip.att.net (12.122.105.30) >>> gar18.n54ny.ip.att.net (12.122.105.101) >>> 12.89.231.190 >>> >>> //////////////// >>> >>> Thanks, >>> Rick >> >> >> From richard.barnes at gmail.com Mon Aug 8 21:19:43 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 8 Aug 2011 22:19:43 -0400 Subject: Errant Advertisement - 128.1/16 In-Reply-To: References: <75C5AC31-3F4F-437B-A199-1D6BA6FA5D6E@bbn.com> Message-ID: Plus, technically, since symbolics.com was non-operational for a while, bbn.com is the oldest .com domain in continuous operation. And you'll notice that it has IPv6-reachable web and DNS servers :) On Mon, Aug 8, 2011 at 11:29 AM, Peter Stockli wrote: > Wow, BBN, the reason we use the @ sign, second .com Domain, former AS1. > > Lots of history ;) > > On Mon, Aug 8, 2011 at 2:07 PM, Rick Altmann wrote: > >> This issue has been cleared up. ?Thanks to everyone for their help. >> >> -Rick >> >> On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote: >> >> > Is there anyone from AT&T on the list that could help with a likely >> misconfiguration? ?I have not received any response yet to my complaint (see >> below) submitted to the abuse address on July 26. ?We have since started >> advertising this space and would like to resolve the MOAS condition we have >> created. >> > >> > //////////////// >> > >> > The 128.1.0.0/16 address block is registered to BBN Technologies >> (AS11488) but is currently unused on any BBN networks. ?BBN would like to >> begin using this address space however AS7018 is currently originating >> public BGP routes for this address block. ?We believe this to be a >> configuration error. ?Please help us resolve this. >> > >> > A traceroute to 128.1.0.1 shows the following routers as the last 4 >> responding hops: >> > >> > cr1.n54ny.ip.att.net (12.122.81.106) >> > cr81.nw2nj.ip.att.net (12.122.105.30) >> > gar18.n54ny.ip.att.net (12.122.105.101) >> > 12.89.231.190 >> > >> > //////////////// >> > >> > Thanks, >> > Rick >> >> >> > From zaid at zaidali.com Mon Aug 8 21:34:58 2011 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 8 Aug 2011 19:34:58 -0700 Subject: AS376 Message-ID: <0EAB9389-6EFA-4427-89C1-F3028344504B@zaidali.com> Can someone from AS 376 contact me offline? s'il vous pla?t? I am seeing a routing issue in your AS. Merci, Zaid From cmadams at hiwaay.net Mon Aug 8 22:43:27 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 8 Aug 2011 22:43:27 -0500 Subject: IPv6 end user addressing In-Reply-To: References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> Message-ID: <20110809034327.GB20370@hiwaay.net> Once upon a time, William Herrin said: > Stateless autoconfiguration (which is NOT dynamic IP addresses; the IP > address is static but tied to the ethernet card) does not work unless > the subnet mask is exactly /64. > > Even on a server lan you'll occasionally want to plug in a PC for > diagnostics without having to poke in an IP address by hand. Actually, nobody should be plugging any random device into my server LANs, and I certainly don't want to encourage it by having it work (even if just for IPv6). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From drc at virtualized.org Mon Aug 8 22:52:19 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 8 Aug 2011 17:52:19 -1000 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: Chris, On Aug 8, 2011, at 2:56 PM, Christopher Morrow wrote: > messing with basic plumbing will have unintended consequences, they will be bad. > > If the users her WANT to have this experience, there are lots of > in-browser/application methods to achieve this, hijacking DNS at the > resolver is really just NOT the right answer, ever. See that ship off on the horizon? It appears to have sailed... I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective. Regards, -drc From brian.e.carpenter at gmail.com Mon Aug 8 22:56:29 2011 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 09 Aug 2011 15:56:29 +1200 Subject: [Fwd: [v6ops] RFC 6343 on Advisory Guidelines for 6to4 Deployment] Message-ID: <4E40AFED.1000009@gmail.com> This is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. -------- Original Message -------- Subject: [v6ops] RFC 6343 on Advisory Guidelines for 6to4 Deployment Date: Mon, 8 Aug 2011 20:21:00 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: v6ops at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6343 Title: Advisory Guidelines for 6to4 Deployment Author: B. Carpenter Status: Informational Stream: IETF Date: August 2011 Mailbox: brian.e.carpenter at gmail.com Pages: 20 Characters: 51496 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-6to4-advisory-02.txt URL: http://www.rfc-editor.org/rfc/rfc6343.txt This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops From bill at herrin.us Mon Aug 8 23:30:05 2011 From: bill at herrin.us (William Herrin) Date: Tue, 9 Aug 2011 00:30:05 -0400 Subject: IPv6 end user addressing In-Reply-To: <20110809034327.GB20370@hiwaay.net> References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> <20110809034327.GB20370@hiwaay.net> Message-ID: On Mon, Aug 8, 2011 at 11:43 PM, Chris Adams wrote: > Once upon a time, William Herrin said: >> Even on a server lan you'll occasionally want to plug in a PC for >> diagnostics without having to poke in an IP address by hand. > > Actually, nobody should be plugging any random device into my server > LANs, and I certainly don't want to encourage it by having it work (even > if just for IPv6). When I send someone on site to do work for me, I don't want to have to prepare excessive instructions on how to connect their laptop to the local LAN. I want to say, "This switch, this port" and then move on to the actual work I sent them there to do. You're welcome to run your shop your way. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Mon Aug 8 23:37:11 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 8 Aug 2011 23:37:11 -0500 Subject: IPv6 end user addressing In-Reply-To: <20110809034327.GB20370@hiwaay.net> References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> <20110809034327.GB20370@hiwaay.net> Message-ID: On Mon, Aug 8, 2011 at 10:43 PM, Chris Adams wrote: >> Even on a server lan you'll occasionally want to plug in a PC for >> diagnostics without having to poke in an IP address by hand. > Actually, nobody should be plugging any random device into my server > LANs, and I certainly don't want to encourage it by having it work (even > if just for IPv6). If you must not have someone plugging into your server LAN without permission, you turn unused ports off, or preferably, place them in a VLAN island with no topological connection to anything. Because it's going to be easier to turn the port back on, than to give someone a 128-bit IP6 address, IPv6 netmask, IPv6 DNS servers, and IPv6 default gateway address set to manually key into their machine. If someone can get to a live port, assuming it's not protected by 802.1x port security or similar; IPv6 will "just work" for fe80:: network link-local connectivity, whether you deploy stateless auto-config or not, which is enough connectivity to find and mess with servers in the LAN. And probably enough connectivity to say "that's too much connectivity", if the LAN is indeed restricted. Similar to how IPv4 has rfc3927, except IPv6 link local addresses get assigned, even to devices that have global IPv6 IPs, so the link local 'subnet' is active even on fully connected devices. > Chris Adams Regards, -- -JH From lists at nurve.com.au Mon Aug 8 23:58:35 2011 From: lists at nurve.com.au (Cameron) Date: Tue, 9 Aug 2011 14:58:35 +1000 Subject: IPv6 end user addressing In-Reply-To: References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> <20110809034327.GB20370@hiwaay.net> Message-ID: > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Tuesday, 9 August 2011 2:30 PM > To: Chris Adams; nanog at nanog.org > Subject: Re: IPv6 end user addressing > > When I send someone on site to do work for me, I don't want to have to > prepare excessive instructions on how to connect their laptop to the > local LAN. I want to say, "This switch, this port" and then move on to > the actual work I sent them there to do. To be fair, if you're sending someone to site who isn't familiar with putting a static address on their laptop then you're probably doing things wrong to begin with. This line of argument isn't going to get us anywhere as for server networks, the benefits of using a /64 are not necessarily beneficial given the environment. > You're welcome to run your shop your way. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From randy at psg.com Tue Aug 9 00:16:51 2011 From: randy at psg.com (Randy Bush) Date: Tue, 09 Aug 2011 14:16:51 +0900 Subject: IPv6 end user addressing In-Reply-To: References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> <20110809034327.GB20370@hiwaay.net> Message-ID: > When I send someone on site to do work for me, I don't want to have to > prepare excessive instructions on how to connect their laptop to the > local LAN. I want to say, "This switch, this port" and then move on to > the actual work I sent them there to do. when i am allowed, i put up open wireless and dhcp. my job is to deliver packets. randy From tvhawaii at shaka.com Tue Aug 9 00:17:23 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 8 Aug 2011 19:17:23 -1000 Subject: (O.T.) The 10 Most Bizarre and Annoying Causes of Fiber Cuts Message-ID: <3A4E1F5180FA4C519632291EDC7E0296@owner59e1f1502> http://blog.level3.com/2011/08/04/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/ From joelja at bogus.com Tue Aug 9 01:54:50 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 8 Aug 2011 23:54:50 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E8F95EB-4568-49CB-BADB-5365FBAE8D15@delong.com> References: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net> <4E8F95EB-4568-49CB-BADB-5365FBAE8D15@delong.com> Message-ID: On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote: > I'm sure there will be platforms that end up on both sides of this question. I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib... given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake. > YES: We made a less expensive box by cutting the width of the TCAM required in half > NO: We spared no expense and passed the costs (and a nice profit margin) on to you so > that you can do whatever you like in IPv6 at wire speed. > > I'm sure the market will chose products from both sides of the line for the same reasons. > > Owen > > On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: > >> >> I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? >> >> If true, it would make /64s even more attractive. >> >> -Randy >> >> >> ----- Original Message ----- >>> we assign /112 per "end user vlan (or server)" at this moment... >>> works >>> perfectly fine (and thats even "a bit too big"). >>> >>> - nobody wants to use dynamic ips on -servers- or -router links- >>> anyway >>> >>> i -really- can't see why people don't just use subnets with just the >>> required number of addresses. >>> >>> take one /64 (for /64's sake ;), split it up into subnets which each >>> have >>> the required number of addresses (lets say you have 2-4 addresses for >>> each >>> bgp/router link, so you simply split it up into subnets that size) >>> >>> etc. >>> >>> no need to use /64 for -everything- at all, just because it fits >>> (ethernet) mac addresses (as if ethernet will be around longer than >>> ipv6 >>> ha-ha, someone will come up with something faster tomorrow and then >>> its >>> bye bye ethernet, the 10ge variant is getting slow, and the 100ge >>> variant >>> is not even standardized yet, and trunking is a bottleneck ;) >>> >>> we don't use /24's for -everything- on ipv4 now do we :P >>> >>> (oh wait, there once was a time where we did.. due to another >>> retarded >>> semi-automatic configuration thingy, called RIP , which also only >>> seemed >>> to understand /24 or bigger ;) >>> >>> -- >>> Greetings, >>> >>> Sven Olaf Kamphuis, >>> CB3ROB Ltd. & Co. KG >>> ========================================================================= >>> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >>> D-13359 Registration: HRA 42834 B >>> BERLIN Phone: >>> +31/(0)87-8747479 >>> Germany GSM: >>> +49/(0)152-26410799 >>> RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net >>> ========================================================================= >>> C3P0, der elektrische Westerwelle >>> http://www.facebook.com/cb3rob >>> ========================================================================= >>> >>> Confidential: Please be advised that the information contained in >>> this >>> email message, including all attached documents or files, is >>> privileged >>> and confidential and is intended only for the use of the individual >>> or >>> individuals addressed. Any other use, dissemination, distribution or >>> copying of this communication is strictly prohibited. >>> >>> >>> On Mon, 8 Aug 2011, Owen DeLong wrote: >>> >>>> >>>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: >>>> >>>>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews >>>>> wrote: >>>>>> So you want HE to force all their clients to renumber. >>>>> >>>>> No. I am simply pointing out that Owen exaggerated when he stated >>>>> that he implements the following three practices together on his >>>>> own >>>>> networks: >>>>> * hierarchical addressing >>>>> * nibble-aligned addressing >>>>> * /48 per access customer >>>>> >>>>> You can simply read the last few messages in this thread to learn >>>>> that >>>>> his recommendations on this list are not even practical for his >>>>> network today, because as Owen himself says, they are not yet able >>>>> to >>>>> obtain additional RIR allocations. HE certainly operates a >>>>> useful, >>>>> high-profile tunnel-broker service which is IMO a very great asset >>>>> to >>>>> the Internet at-large; but if you spend a few minutes looking at >>>>> the >>>>> publicly available statistics on this service, they average only >>>>> around 10,000 active tunnels across all their tunnel termination >>>>> boxes >>>>> combined. They have not implemented the policies recommended by >>>>> Owen >>>>> because, as he states, a /32 is not enough. >>>>> >>>>> Do I think the position he advocates will cause the eventual >>>>> exhaustion of IPv6? Well, let's do an exercise: >>>>> >>>>> There has been some rather simplistic arithmetic posted today, >>>>> 300m >>>>> new subnets per year, etc. with zero consideration of >>>>> address/subnet >>>>> utilization efficiency within ISP networks and individual >>>>> aggregation >>>>> router pools. That is foolish. We can all pull out a calculator >>>>> and >>>>> figure that 2000::/3 has space for 35 trillion /48 networks. That >>>>> isn't how they will be assigned or routed. >>>>> >>>>> The effect of 2011-3 is that an out-sized ISP like AT&T has every >>>>> justification for deciding to allocate 24 bits worth of subnet ID >>>>> for >>>>> their "largest POP," say, one that happens to terminate layer-3 >>>>> services for all customers in an entire state. They then have >>>>> policy >>>>> support for allocating the same sized subnet for every other POP, >>>>> no >>>>> matter how small. After all, the RIR policy permits them to >>>>> obtain >>>>> additional allocations as soon as one POP subnet has become full. >>>>> >>>>> So now you have a huge ISP with a few huge POPs, and a lot of >>>>> small >>>>> ones, justified in assigning the same size aggregate prefix, >>>>> suitable >>>>> for 2^24 subnets, to all those small POPs as well. How many >>>>> layer-3 >>>>> POPs might this huge ISP have? Any number. It could be every >>>>> central >>>>> office with some kind of layer-3 customer aggregation router. It >>>>> could even be every road-side hut for FTTH services. Perhaps they >>>>> will decide to address ten thousand POPs this way. >>>>> >>>>> Now the nibble-aligned language in the policy permits them to >>>>> round up >>>>> from 10,000 POPs to 16 bits worth of address space for "POP ID." >>>>> So >>>>> AT&T is quite justified in requesting: >>>>> 48 (customer subnet length) - 24 (largest POP subnet ID size) - >>>>> 16 >>>>> (POP ID) == a /8 subnet for themselves. >>>>> >>>> Right up until you read: >>>> >>>> 6.5.3 (d): >>>> If an LIR has already reached a /12 or more, ARIN will >>>> allocate a single additional /12 rather than continue >>>> expanding nibble boundaries. >>>> As you can see, there is a safety valve in the policy at /12 for >>>> just >>>> this reason. >>>> >>>> >>>>> Now you can see how this policy, and addressing scheme, is utterly >>>>> brain-dead. It really does put you (and me, and everyone else) in >>>>> real danger of exhausting the IPv6 address space. All it takes is >>>>> a >>>>> few out-sized ISPs, with one large POP each and a bunch of smaller >>>>> ones, applying for the maximum amount of address space permitted >>>>> them >>>>> under 2011-3. >>>>> >>>> >>>> Even by your calculations, it would take 256 such outsized ISPs >>>> without >>>> a safety valve. With the safety valve that is built into the policy >>>> at /12, >>>> it would take 4,096 such ISPs. I do not believe that there are more >>>> than >>>> about 20 such ISPs world wide at this time and would put the >>>> foreseeable >>>> likely maximum at less than 100 due to the need for customers to >>>> support >>>> such outsized ISPs and the limited base that would have to be >>>> divided >>>> among them. >>>> >>>> Owen >>>> >>>> >>> >>> >>> > From owen at delong.com Tue Aug 9 02:25:52 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 9 Aug 2011 00:25:52 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net> <4E8F95EB-4568-49CB-BADB-5365FBAE8D15@delong.com> Message-ID: <816F6C38-8879-4A18-B8F3-0317848A67C3@delong.com> It's at least true of how some of the Cisco platforms cope with IPv6 access lists. Owen On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote: > > On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote: > >> I'm sure there will be platforms that end up on both sides of this question. > > I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib... > > given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake. > >> YES: We made a less expensive box by cutting the width of the TCAM required in half > >> NO: We spared no expense and passed the costs (and a nice profit margin) on to you so >> that you can do whatever you like in IPv6 at wire speed. >> >> I'm sure the market will chose products from both sides of the line for the same reasons. >> >> Owen >> >> On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: >> >>> >>> I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? >>> >>> If true, it would make /64s even more attractive. >>> >>> -Randy >>> >>> >>> ----- Original Message ----- >>>> we assign /112 per "end user vlan (or server)" at this moment... >>>> works >>>> perfectly fine (and thats even "a bit too big"). >>>> >>>> - nobody wants to use dynamic ips on -servers- or -router links- >>>> anyway >>>> >>>> i -really- can't see why people don't just use subnets with just the >>>> required number of addresses. >>>> >>>> take one /64 (for /64's sake ;), split it up into subnets which each >>>> have >>>> the required number of addresses (lets say you have 2-4 addresses for >>>> each >>>> bgp/router link, so you simply split it up into subnets that size) >>>> >>>> etc. >>>> >>>> no need to use /64 for -everything- at all, just because it fits >>>> (ethernet) mac addresses (as if ethernet will be around longer than >>>> ipv6 >>>> ha-ha, someone will come up with something faster tomorrow and then >>>> its >>>> bye bye ethernet, the 10ge variant is getting slow, and the 100ge >>>> variant >>>> is not even standardized yet, and trunking is a bottleneck ;) >>>> >>>> we don't use /24's for -everything- on ipv4 now do we :P >>>> >>>> (oh wait, there once was a time where we did.. due to another >>>> retarded >>>> semi-automatic configuration thingy, called RIP , which also only >>>> seemed >>>> to understand /24 or bigger ;) >>>> >>>> -- >>>> Greetings, >>>> >>>> Sven Olaf Kamphuis, >>>> CB3ROB Ltd. & Co. KG >>>> ========================================================================= >>>> Address: Koloniestrasse 34 VAT Tax ID: DE267268209 >>>> D-13359 Registration: HRA 42834 B >>>> BERLIN Phone: >>>> +31/(0)87-8747479 >>>> Germany GSM: >>>> +49/(0)152-26410799 >>>> RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net >>>> ========================================================================= >>>> C3P0, der elektrische Westerwelle >>>> http://www.facebook.com/cb3rob >>>> ========================================================================= >>>> >>>> Confidential: Please be advised that the information contained in >>>> this >>>> email message, including all attached documents or files, is >>>> privileged >>>> and confidential and is intended only for the use of the individual >>>> or >>>> individuals addressed. Any other use, dissemination, distribution or >>>> copying of this communication is strictly prohibited. >>>> >>>> >>>> On Mon, 8 Aug 2011, Owen DeLong wrote: >>>> >>>>> >>>>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: >>>>> >>>>>> On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews >>>>>> wrote: >>>>>>> So you want HE to force all their clients to renumber. >>>>>> >>>>>> No. I am simply pointing out that Owen exaggerated when he stated >>>>>> that he implements the following three practices together on his >>>>>> own >>>>>> networks: >>>>>> * hierarchical addressing >>>>>> * nibble-aligned addressing >>>>>> * /48 per access customer >>>>>> >>>>>> You can simply read the last few messages in this thread to learn >>>>>> that >>>>>> his recommendations on this list are not even practical for his >>>>>> network today, because as Owen himself says, they are not yet able >>>>>> to >>>>>> obtain additional RIR allocations. HE certainly operates a >>>>>> useful, >>>>>> high-profile tunnel-broker service which is IMO a very great asset >>>>>> to >>>>>> the Internet at-large; but if you spend a few minutes looking at >>>>>> the >>>>>> publicly available statistics on this service, they average only >>>>>> around 10,000 active tunnels across all their tunnel termination >>>>>> boxes >>>>>> combined. They have not implemented the policies recommended by >>>>>> Owen >>>>>> because, as he states, a /32 is not enough. >>>>>> >>>>>> Do I think the position he advocates will cause the eventual >>>>>> exhaustion of IPv6? Well, let's do an exercise: >>>>>> >>>>>> There has been some rather simplistic arithmetic posted today, >>>>>> 300m >>>>>> new subnets per year, etc. with zero consideration of >>>>>> address/subnet >>>>>> utilization efficiency within ISP networks and individual >>>>>> aggregation >>>>>> router pools. That is foolish. We can all pull out a calculator >>>>>> and >>>>>> figure that 2000::/3 has space for 35 trillion /48 networks. That >>>>>> isn't how they will be assigned or routed. >>>>>> >>>>>> The effect of 2011-3 is that an out-sized ISP like AT&T has every >>>>>> justification for deciding to allocate 24 bits worth of subnet ID >>>>>> for >>>>>> their "largest POP," say, one that happens to terminate layer-3 >>>>>> services for all customers in an entire state. They then have >>>>>> policy >>>>>> support for allocating the same sized subnet for every other POP, >>>>>> no >>>>>> matter how small. After all, the RIR policy permits them to >>>>>> obtain >>>>>> additional allocations as soon as one POP subnet has become full. >>>>>> >>>>>> So now you have a huge ISP with a few huge POPs, and a lot of >>>>>> small >>>>>> ones, justified in assigning the same size aggregate prefix, >>>>>> suitable >>>>>> for 2^24 subnets, to all those small POPs as well. How many >>>>>> layer-3 >>>>>> POPs might this huge ISP have? Any number. It could be every >>>>>> central >>>>>> office with some kind of layer-3 customer aggregation router. It >>>>>> could even be every road-side hut for FTTH services. Perhaps they >>>>>> will decide to address ten thousand POPs this way. >>>>>> >>>>>> Now the nibble-aligned language in the policy permits them to >>>>>> round up >>>>>> from 10,000 POPs to 16 bits worth of address space for "POP ID." >>>>>> So >>>>>> AT&T is quite justified in requesting: >>>>>> 48 (customer subnet length) - 24 (largest POP subnet ID size) - >>>>>> 16 >>>>>> (POP ID) == a /8 subnet for themselves. >>>>>> >>>>> Right up until you read: >>>>> >>>>> 6.5.3 (d): >>>>> If an LIR has already reached a /12 or more, ARIN will >>>>> allocate a single additional /12 rather than continue >>>>> expanding nibble boundaries. >>>>> As you can see, there is a safety valve in the policy at /12 for >>>>> just >>>>> this reason. >>>>> >>>>> >>>>>> Now you can see how this policy, and addressing scheme, is utterly >>>>>> brain-dead. It really does put you (and me, and everyone else) in >>>>>> real danger of exhausting the IPv6 address space. All it takes is >>>>>> a >>>>>> few out-sized ISPs, with one large POP each and a bunch of smaller >>>>>> ones, applying for the maximum amount of address space permitted >>>>>> them >>>>>> under 2011-3. >>>>>> >>>>> >>>>> Even by your calculations, it would take 256 such outsized ISPs >>>>> without >>>>> a safety valve. With the safety valve that is built into the policy >>>>> at /12, >>>>> it would take 4,096 such ISPs. I do not believe that there are more >>>>> than >>>>> about 20 such ISPs world wide at this time and would put the >>>>> foreseeable >>>>> likely maximum at less than 100 due to the need for customers to >>>>> support >>>>> such outsized ISPs and the limited base that would have to be >>>>> divided >>>>> among them. >>>>> >>>>> Owen >>>>> >>>>> >>>> >>>> >>>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From morrowc.lists at gmail.com Tue Aug 9 03:08:27 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Aug 2011 04:08:27 -0400 Subject: US internet providers hijacking users' search queries In-Reply-To: References: <031222CBCF33214AB2EB4ABA279428A3E25B60D2D8@SJCPMAILBOX01.citrite.net> <20110806011359.GA24602@gweep.net> <4E3D5286.7080307@ispalliance.net> <20110806170801.GA21712@gweep.net> <4E3DF274.6050709@ispalliance.net> Message-ID: On Mon, Aug 8, 2011 at 11:52 PM, David Conrad wrote: > Chris, > > On Aug 8, 2011, at 2:56 PM, Christopher Morrow wrote: >> messing with basic plumbing will have unintended consequences, they will be bad. >> >> If the users her WANT to have this experience, there are lots of >> in-browser/application methods to achieve this, hijacking DNS at the >> resolver is really just NOT the right answer, ever. > > See that ship off on the horizon? ?It appears to have sailed... doesn't mean I can't be the cranky old man shaking my fist, right? > > I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. ?As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective. > yea... so that, so I understand, depends a lot on who's telling the tale. From one source at an ISP doing this, the revenues are not anywhere near what was promised by the vendor(s). Anyway, I'm not sure what they are, we probably won't ever know what they really are :( I suppose it'll continue as long as people consider it 'ok' to be subjected to this and don't leave their ISP for an alternative. (where available!) Oh, maybe dns-sec will help us with this problem too? nsec3 to the rescue? From tim at pelican.org Tue Aug 9 06:17:12 2011 From: tim at pelican.org (Tim Franklin) Date: Tue, 09 Aug 2011 12:17:12 +0100 (BST) Subject: IPv6 end user addressing In-Reply-To: <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> Message-ID: > Silly confidentiality notices are usually enforced by silly corporate > IT departments and cannot be removed by mere mortal employees. > They are an unavoidable part of life, like Outlook top posting and > spam. Alternatively, if your corporate email imposes stupid policies and / or a stupid email client (note: it's possible to quote properly and not top-post with Outlook, it's just hard work), don't subscribe to mailing lists from your corporate email. Of all the mailing list communities, I'd expect this one not to struggle very much with arranging an alternative... Regards, Tim. From cmadams at hiwaay.net Tue Aug 9 07:44:05 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 9 Aug 2011 07:44:05 -0500 Subject: IPv6 end user addressing In-Reply-To: References: <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <20110807225851.0D52D128A49D@drugs.dv.isc.org> <8BEA38DD-9A3A-412F-B262-BE537C884320@delong.com> <20110809034327.GB20370@hiwaay.net> Message-ID: <20110809124405.GA8401@hiwaay.net> Once upon a time, Jimmy Hess said: > If you must not have someone plugging into your server LAN without > permission, you > turn unused ports off, or preferably, place them in a VLAN island with > no topological > connection to anything. That's about what I do; unused ports are in a different VLAN. I have a separate LAN for notebooks, etc. that has DHCP (and will have a v6 /64 when I get v6 to that point). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fernando at gont.com.ar Tue Aug 9 08:21:34 2011 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 09 Aug 2011 10:21:34 -0300 Subject: IPv6 Hackers mailing-list Message-ID: <4E41345E.8080702@gont.com.ar> Folks, We have created the "IPv6 Hackers" mailing-list for discussion of IPv6 security issues and low-level issues. The charter of the list is: ---- cut here ---- This list was created for the discussion of IPv6 security issues and low/packet-level issues related to the IPv6 protocols. It is meant to provide forum for IPv6 security researchers and IPv6 networking professionals to discuss low-level IPv6 networking and security issues that could eventually lead to advances and improvements in the area of IPv6 security and IPv6 networking. Discussion of unrelated networking or security topics are considered "off topic". Subscription to the list is open to the community. ---- cut here ---- You can subscribe to the mailing-list here: http://lists.si6networks.com/listinfo/ipv6hackers/ Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Valdis.Kletnieks at vt.edu Tue Aug 9 08:21:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Aug 2011 09:21:30 -0400 Subject: IPv6 end user addressing In-Reply-To: Your message of "Tue, 09 Aug 2011 11:24:03 +1200." <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> References: <09AA33D5-2721-4E33-B7BF-31713D253A1D@delong.com> <005f01cc53c2$e52b4200$af81c600$@iname.com> <3435B504-1C63-4717-8E5C-8CB35A02DF70@baycix.de> <69083EAC-FAF5-478F-A573-5E1255866220@delong.com> <3A98809B-DF49-48E3-9702-72D2A705322D@delong.com> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A733475@winexmp02> <3E3FDD2AC2CEF442A9D2B00CF5F6D0409A7F3CB2@winexmp02> Message-ID: <38279.1312896090@turing-police.cc.vt.edu> On Tue, 09 Aug 2011 11:24:03 +1200, Jonathon Exley said: > Silly confidentiality notices are usually enforced by silly corporate IT > departments and cannot be removed by mere mortal employees. > They are an unavoidable part of life, like Outlook top posting and spam. They may all three be things that we continually receive from clueless netizens. However, it is not at all difficult for anybody clued enough to get subscribed to NANOG to find ways to avoid inflicting all three on the rest of us. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcurran at arin.net Tue Aug 9 08:47:50 2011 From: jcurran at arin.net (John Curran) Date: Tue, 9 Aug 2011 13:47:50 +0000 Subject: ISP support for use of 4-byte ASNs in peering Message-ID: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> Folks - Is there a public list somewhere of service providers that do not support 4-byte autonomous system numbers when peering? (if not, should there be one?) At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. Thoughts? /John John Curran President and CEO ARIN From nick at foobar.org Tue Aug 9 09:24:26 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 09 Aug 2011 15:24:26 +0100 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> Message-ID: <4E41431A.5060607@foobar.org> On 09/08/2011 14:47, John Curran wrote: > At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), > indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. > This is obviously a less than desirable situation, and it appears that it is not trending > towards resolution at this time. At INEX, we see 60% of IXP connections which can handle ASN32 natively. However, INEX is a small IXP and I haven't seen similar figures from other IXPs which could validate this 60/40 split. Having said that, in the IXP world most new service providers connect into route servers, so there is often no perceived requirement for direct ASN32->ASN16 interconnection - the intersection of new service providers and ASN32 holders is quite large. And if you really want a bilateral peering relationship, there's no reason not to use AS23456. > Thoughts? - interior BGP community management is great fun with an ASN32, oh yes. - i don't have much sympathy for people who whine about not being able to support ASN32 peerings. There is no good reason for this these days. - from personal experience, I understand why ASN32 is less popular. However, it's certainly usable. Nick From michael.hare at doit.wisc.edu Tue Aug 9 09:45:08 2011 From: michael.hare at doit.wisc.edu (Michael Hare) Date: Tue, 09 Aug 2011 09:45:08 -0500 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <4E41431A.5060607@foobar.org> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> <4E41431A.5060607@foobar.org> Message-ID: <4E4147F4.7050606@doit.wisc.edu> While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support. -Michael On 8/9/2011 9:24 AM, Nick Hilliard wrote: > On 09/08/2011 14:47, John Curran wrote: >> At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), >> indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. >> This is obviously a less than desirable situation, and it appears that it is not trending >> towards resolution at this time. > > At INEX, we see 60% of IXP connections which can handle ASN32 natively. > However, INEX is a small IXP and I haven't seen similar figures from other > IXPs which could validate this 60/40 split. > > Having said that, in the IXP world most new service providers connect into > route servers, so there is often no perceived requirement for direct > ASN32->ASN16 interconnection - the intersection of new service providers > and ASN32 holders is quite large. And if you really want a bilateral > peering relationship, there's no reason not to use AS23456. > >> Thoughts? > > - interior BGP community management is great fun with an ASN32, oh yes. > > - i don't have much sympathy for people who whine about not being able to > support ASN32 peerings. There is no good reason for this these days. > > - from personal experience, I understand why ASN32 is less popular. > However, it's certainly usable. > > Nick > > From morrowc.lists at gmail.com Tue Aug 9 10:22:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Aug 2011 11:22:34 -0400 Subject: (O.T.) The 10 Most Bizarre and Annoying Causes of Fiber Cuts In-Reply-To: <3A4E1F5180FA4C519632291EDC7E0296@owner59e1f1502> References: <3A4E1F5180FA4C519632291EDC7E0296@owner59e1f1502> Message-ID: and the number 1 threat ... suprisingly no Bears! On Tue, Aug 9, 2011 at 1:17 AM, Michael Painter wrote: > http://blog.level3.com/2011/08/04/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/ > > From nick at foobar.org Tue Aug 9 10:38:15 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 09 Aug 2011 16:38:15 +0100 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <4E4147F4.7050606@doit.wisc.edu> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> <4E41431A.5060607@foobar.org> <4E4147F4.7050606@doit.wisc.edu> Message-ID: <4E415467.3040009@foobar.org> On 09/08/2011 15:45, Michael Hare wrote: > While attempting to focus on ISPs there is still [unbelievably] a vendor > support issue. You may consider this a procurement failure, but the fact > remains that some products [Cisco me3400e] have yet to implement support. the me3400 is a metro core ethernet switch with L3 extensions. It's not intended as a border router. If you use the wrong tool for the job... Nick From ikiris at gmail.com Tue Aug 9 10:43:53 2011 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 9 Aug 2011 10:43:53 -0500 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <4E415467.3040009@foobar.org> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> <4E41431A.5060607@foobar.org> <4E4147F4.7050606@doit.wisc.edu> <4E415467.3040009@foobar.org> Message-ID: Aren't there still community issues with 4 byte ASN space as well that have not been resolved? -Blake From nick at foobar.org Tue Aug 9 10:56:21 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 09 Aug 2011 16:56:21 +0100 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> <4E41431A.5060607@foobar.org> <4E4147F4.7050606@doit.wisc.edu> <4E415467.3040009@foobar.org> Message-ID: <4E4158A5.2090707@foobar.org> On 09/08/2011 16:43, Blake Dunlap wrote: > Aren't there still community issues with 4 byte ASN space as well that have > not been resolved? I think I mentioned that. draft-raszuk-wide-bgp-communities will fix this, but it's unclear when we'll start seeing this rolled out in production code. Nick From michael.hare at doit.wisc.edu Tue Aug 9 11:15:51 2011 From: michael.hare at doit.wisc.edu (Michael Hare) Date: Tue, 09 Aug 2011 11:15:51 -0500 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <4E415467.3040009@foobar.org> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> <4E41431A.5060607@foobar.org> <4E4147F4.7050606@doit.wisc.edu> <4E415467.3040009@foobar.org> Message-ID: <4E415D37.2000409@doit.wisc.edu> Granted I've never worked outside academia but the me3400 is otherwise a cost effective gig-e demarc for very simple bgp multihoming. They have made a strategic decision to not implement a simple software update support RFC4893 [it has been 4 years] and to set an artificial price point on entry. Fine, that is their choice. There are other vendors offering 4 byte ASN in simliar products at or near this price point and we'll probably have to move to them. -Michael On 8/9/2011 10:38 AM, Nick Hilliard wrote: > On 09/08/2011 15:45, Michael Hare wrote: >> While attempting to focus on ISPs there is still [unbelievably] a vendor >> support issue. You may consider this a procurement failure, but the fact >> remains that some products [Cisco me3400e] have yet to implement support. > > the me3400 is a metro core ethernet switch with L3 extensions. It's not > intended as a border router. If you use the wrong tool for the job... > > Nick > > From joey at q7.com Tue Aug 9 13:47:37 2011 From: joey at q7.com (Joe Pruett) Date: Tue, 09 Aug 2011 11:47:37 -0700 Subject: v4/v6 dns thoughts? Message-ID: <4E4180C9.4060607@q7.com> as i'm rolling v6 into my world, i'm not sure which way to go with reverse dns conventions. for forward i'm doing things like: foo.example.com a 1.1.1.1 foo.example.com aaaa 1000::1.1.1.1 foo.v4.example.com a 1.1.1.1 foo.v6.example.com aaaa 1000::1.1.1.1 so i can use a foo.v4/v6 hostname if i need to specify transit behavior. but for reverse i'm not sure if i want to map it like: 1.1.1.1.in-addr.arpa ptr foo.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptr foo.example.com or: 1.1.1.1.in-addr.arpa ptr foo.v4.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptr foo.v6.example.com being able to just use foo.example.com for authentication purposes (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or v6 by just looking at the dns lookup (for tools that do reverse lookup for you) is also nice. what are you doing? which way makes more sense to you? From jeroen at unfix.org Tue Aug 9 15:14:17 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 09 Aug 2011 22:14:17 +0200 Subject: v4/v6 dns thoughts? In-Reply-To: <4E4180C9.4060607@q7.com> References: <4E4180C9.4060607@q7.com> Message-ID: <4E419519.4020903@unfix.org> On 2011-08-09 20:47 , Joe Pruett wrote: > as i'm rolling v6 into my world, i'm not sure which way to go with > reverse dns conventions. for forward i'm doing things like: > > foo.example.com a 1.1.1.1 > foo.example.com aaaa 1000::1.1.1.1 > foo.v4.example.com a 1.1.1.1 > foo.v6.example.com aaaa 1000::1.1.1.1 You do mean: foo.example.com A 192.0.2.1 foo.example.com AAAA 2001:db8::1.1.1.1 foo.v4.example.com A 192.0.2.1 foo.v6.example.com AAAA 2001:db8::1.1.1.1 I hope, seeing that 1.1.1.1 is for the APNIC region and 1000::/8 is outside 2000::/3 and thus not defined yet, that you use the documentation prefixes when showing examples instead of abusing that address space, as that is exactly the reason why 1.1.1.1 will most likely never be allocated to anyone but researchers who are seeing all kind of fun backscatter... > so i can use a foo.v4/v6 hostname if i need to specify transit behavior. People commonly use the 'ipv4' and 'ipv6' variant for this. Most network-specific tools though fortunately have -4/-6, but as indeed quite a few don't it is always handy to have the above. [..] > being able to just use foo.example.com for authentication purposes > (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or > v6 by just looking at the dns lookup (for tools that do reverse lookup > for you) is also nice. Tools that do reverse lookups should always also report the IP address as without the IP a reverse is futile unless said tool does at least a ip->reverse->forward check and then of course the hope is that that hostname does not disappear between that lookup happening and it going away again... > what are you doing? which way makes more sense to you? Map it to the hostname. This as it should not matter if it is IPv4 or IPv6. For routers of course one might want to use a v4/v6 specific one as per the above reason of 'easier for the eyes in traceroute', but on the other side one could just as well use an IPv4+IPv6 per interface and thus name them based on the interface Greets, Jeroen From vixie at isc.org Tue Aug 9 15:14:49 2011 From: vixie at isc.org (Paul Vixie) Date: Tue, 09 Aug 2011 20:14:49 +0000 Subject: not operational -- call for nominations for ARIN council & board Message-ID: <54506.1312920889@nsa.vix.com> gentlefolk, ARIN is the community's self-generated steward for internet numbering resources (ip addresses and autonomous system numbers) and it is governed by volunteers from the community who serve on its advisory council and executive board. every year ARIN holds an election to fill or renew several expiring terms. candidates need not be ARIN members. please see and think about whether who you can nominate or whether you can self- nominate. paul vixie chairman, 2011 arin nomcom From owen at delong.com Tue Aug 9 18:36:30 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 9 Aug 2011 16:36:30 -0700 Subject: v4/v6 dns thoughts? In-Reply-To: <4E4180C9.4060607@q7.com> References: <4E4180C9.4060607@q7.com> Message-ID: On Aug 9, 2011, at 11:47 AM, Joe Pruett wrote: > as i'm rolling v6 into my world, i'm not sure which way to go with > reverse dns conventions. for forward i'm doing things like: > > foo.example.com a 1.1.1.1 > foo.example.com aaaa 1000::1.1.1.1 > foo.v4.example.com a 1.1.1.1 > foo.v6.example.com aaaa 1000::1.1.1.1 > > so i can use a foo.v4/v6 hostname if i need to specify transit behavior. > > but for reverse i'm not sure if i want to map it like: > > 1.1.1.1.in-addr.arpa ptr foo.example.com. > 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa > ptr foo.example.com > > or: > > 1.1.1.1.in-addr.arpa ptr foo.v4.example.com. > 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa > ptr foo.v6.example.com > > being able to just use foo.example.com for authentication purposes > (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or > v6 by just looking at the dns lookup (for tools that do reverse lookup > for you) is also nice. > > what are you doing? which way makes more sense to you? > My PTRs are all to the same host name. In any context where the protocol actually matters, you should have other ways to detect it. I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's really no advantage to do it. Most tools either have separate IPv4/IPv6 variants or have command-line switches for address-family control if you care. Owen From feldman at nanog.org Tue Aug 9 18:59:29 2011 From: feldman at nanog.org (Steven Feldman) Date: Tue, 9 Aug 2011 16:59:29 -0700 Subject: NANOG Board Announcement In-Reply-To: References: Message-ID: I am sad to announce that Robert Seastrom has resigned from the NewNOG Board of Directors, effective yesterday. ?Rob has served on the Steering Committee, transition team, and the board for the past three years, and has provided valuable insight and assistance throughout the transition of NANOG to a standalone organization. ?I thank Rob for his service to the community, and look forward to his continued participation as a member. Since this creates a vacancy on the board with more than two months remaining until the next election, the Bylaws require the remaining board members to appoint a temporary replacement to serve until the election. ?At that time, a permanent replacement will be elected to fill the remainder of Rob's term, which ends in October 2012. Accordingly, the board has selected Michael K. Smith to fill the vacant position between now and the October Election. ?Mike has been serving as Communications Committee chair for a few years, as well as assisting with budgeting, technical planning, and many other behind-the-scenes tasks during the transition. Please join me in thanking Rob for his service, and in welcoming Mike to the board. Thanks, ? ? ?Steve Feldman, chair From lstewart at superb.net Tue Aug 9 19:15:41 2011 From: lstewart at superb.net (Landon Stewart) Date: Tue, 9 Aug 2011 17:15:41 -0700 Subject: v4/v6 dns thoughts? In-Reply-To: References: <4E4180C9.4060607@q7.com> Message-ID: On 9 August 2011 16:36, Owen DeLong wrote: > My PTRs are all to the same host name. In any context where the protocol > actually matters, you should have other ways to detect it. > > I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. > There's > really no advantage to do it. Most tools either have separate IPv4/IPv6 > variants > or have command-line switches for address-family control if you care. > I agree that using the v4 or v6 tag in forward or reverse is pointless. One can tell it is v4 or v6 by the result of the lookup and the hostnames don't change just because they are accessible via IPv6. If a hostname is directly related to the fact that its IPv6 by all means put it in there though. -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From fmartin at linkedin.com Tue Aug 9 19:57:44 2011 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 10 Aug 2011 00:57:44 +0000 Subject: I'm missing 2 bytes (GRE implementation) Message-ID: I'm using a GRE IPv4 tunnel between a cisco and linux machines I did some packet capture, and saw that my MTU was 1418, but the cisco was sending TCP packet with a MSS of 1380. This created a bunch of issues. When I told the cisco box to use a MSS of 1378 everything starting to work fine. So why Cisco is off by 2 Bytes? Does the GRE implementation on Linux uses 2 extra bytes compared to Cisco (or vice versa)? From sfouant at shortestpathfirst.net Tue Aug 9 20:23:52 2011 From: sfouant at shortestpathfirst.net (=?utf-8?B?U3RlZmFuIEZvdWFudA==?=) Date: Tue, 09 Aug 2011 18:23:52 -0700 Subject: =?utf-8?B?UmU6IEknbSBtaXNzaW5nIDIgYnl0ZXMgKEdSRSBpbXBsZW1lbnRhdGlvbik=?= Message-ID: Everything from checksums, keys, and sequence numbers is optional. The only required fields IIRC amount to 2 bytes of overhead. Sounds like they both interpret what should be included in the GRE header slightly differently. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. ----- Reply message ----- From: "Franck Martin" Date: Tue, Aug 9, 2011 5:57 pm Subject: I'm missing 2 bytes (GRE implementation) To: "nanog at nanog.org" I'm using a GRE IPv4 tunnel between a cisco and linux machines I did some packet capture, and saw that my MTU was 1418, but the cisco was sending TCP packet with a MSS of 1380. This created a bunch of issues. When I told the cisco box to use a MSS of 1378 everything starting to work fine. So why Cisco is off by 2 Bytes? Does the GRE implementation on Linux uses 2 extra bytes compared to Cisco (or vice versa)? From blake at pfankuch.me Tue Aug 9 22:03:05 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Wed, 10 Aug 2011 03:03:05 +0000 Subject: v4/v6 dns thoughts? In-Reply-To: References: <4E4180C9.4060607@q7.com> Message-ID: I too agree the v4/v6 stuff is pointless and slightly annoying so I have been using same name with A/AAAA records. -----Original Message----- From: Landon Stewart [mailto:lstewart at superb.net] Sent: Tuesday, August 09, 2011 6:16 PM To: nanog at nanog.org Subject: Re: v4/v6 dns thoughts? On 9 August 2011 16:36, Owen DeLong wrote: > My PTRs are all to the same host name. In any context where the > protocol actually matters, you should have other ways to detect it. > > I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. > There's > really no advantage to do it. Most tools either have separate > IPv4/IPv6 variants or have command-line switches for address-family > control if you care. > I agree that using the v4 or v6 tag in forward or reverse is pointless. One can tell it is v4 or v6 by the result of the lookup and the hostnames don't change just because they are accessible via IPv6. If a hostname is directly related to the fact that its IPv6 by all means put it in there though. -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From kloch at kl.net Tue Aug 9 22:42:18 2011 From: kloch at kl.net (Kevin Loch) Date: Tue, 09 Aug 2011 23:42:18 -0400 Subject: ISP support for use of 4-byte ASNs in peering In-Reply-To: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> References: <02748298-1F7D-42EB-82EC-81D5FA7C22F2@arin.net> Message-ID: <4E41FE1A.2040701@kl.net> John Curran wrote: > Folks - > > Is there a public list somewhere of service providers that do not support 4-byte > autonomous system numbers when peering? (if not, should there be one?) > > At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), > indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. > This is obviously a less than desirable situation, and it appears that it is not trending > towards resolution at this time. Perhaps you meant to send this to c-nsp and re-worded it slightly? - Kevin From a.harrowell at gmail.com Wed Aug 10 05:55:15 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 10 Aug 2011 11:55:15 +0100 Subject: IPv6 end user addressing In-Reply-To: References: Message-ID: <201108101155.35498.a.harrowell@gmail.com> On Monday 08 Aug 2011 22:00:52 Owen DeLong wrote: > > On Aug 8, 2011, at 7:12 AM, Mohacsi Janos wrote: > > > > > > > On Mon, 8 Aug 2011, Valdis.Kletnieks at vt.edu wrote: > > > >> On Mon, 08 Aug 2011 10:15:17 +0200, Mohacsi Janos said: > >> > >>> - Home users - they usually don't know what is subnet. Setting up > >>> different subnets in their SOHO router can be difficult. Usually the > >>> simple 1 subnet for every device is enough for them. Separating some > >>> devices into a separate subnets is usually enough for the most > >>> sophisticated home users. If not then he can opt for business service.... > >> > >> You don't want to make the assumption that just because Joe Sixpack doesn't > >> know what a subnet is, that Joe Sixpack's CPE doesn't know either. > >> > >> And remember that if it's 3 hops from one end of Joe Sixpack's internal net to > >> the other, you're gonna burn a few bits to support heirarchical routing so you > >> don't need a routing protocol. So if Joe's exterior-facing CPU gets handed a > >> /56 by the provider, and it hands each device it sees a /60 in case it's a > >> device that routes too, it can only support 14 devices. And if one of the > > > > more exactly 16 routing devices. You don't have to count the all 0 and all 1 as reserved.... maybe each deeice can see /57 or /58 or /59.... depending of capabilities your devices.... > > > > I think daisy chaining of CPE routers is bad idea - as probably done in several IPv4 home networks. Why would you build several hierarchy into you network if it is unnecessary? > > > > > I can see things like wanting to have an entertainment systems network that is fronted > by a router with additional networks for each entertainment system fronted by their > own router, segmentation of various appliance networks with possibly an appliance > front-end router, etc. > > There are lots of possibilities we haven't thought of here yet. Limiting end-users > to /56 or worse will only stifle the innovation that will help us identify the possibilities. > For this, if no other reason, (and I cite the limitations under which we have begun > to frame our assumptions about how the internet works as a result of NAT as an > example), I think we should avoid preserving this cultural conditioning in IPv6. > > > Owen > > Thinking about the CPE thread, isn't this a case for bridging as a feature in end-user devices? If Joe's media-centre box etc would bridge its downstream ports to the upstream port, the devices on them could just get an address, whether by DHCPv6 from the CPE router's delegation or by SLAAC, and then register in local DNS or more likely do multicast- DNS so they could find each other. And then it really doesn't matter; everything gets its address, nothing is NATted, every address is mapped to a meaningful hostname. Perhaps you'd need more aggregation and routing in the glorious one-IP- per-nanite-and-Facebook-fridges future, but that's for another day once we've got fusion and a rational system of government out of the way:-) Joe's network as described isn't big enough or clever enough to need multiple routers. It's just a small LAN and it's only Joe's weirdness in using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that prevents it from being so. Not all problems should be solved by routing - but a list full of "router people" is inherently likely to try to solve all its problems with more routers and routing. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Wed Aug 10 08:02:19 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 06:02:19 -0700 Subject: IPv6 end user addressing In-Reply-To: <201108101155.35498.a.harrowell@gmail.com> References: <201108101155.35498.a.harrowell@gmail.com> Message-ID: > > Thinking about the CPE thread, isn't this a case for bridging as a > feature in end-user devices? If Joe's media-centre box etc would bridge > its downstream ports to the upstream port, the devices on them could > just get an address, whether by DHCPv6 from the CPE router's delegation > or by SLAAC, and then register in local DNS or more likely do multicast- > DNS so they could find each other. > Why do I want my kid's network seeing all the multicast packets that are streaming the adult video from the player to the TV and the Amp in the master bedroom? Why do I want my appliance network's multicast packets getting tossed around on the guest wireless? Bridging eliminates the multicast isolation that you get from routing. This is not a case for bridging, it's a case for making it possible to do real routing in the home and we now have the space and the technology to actually do it in a meaningful and sufficiently automatic way as to be applicable to Joe 6-Mac. > > And then it really doesn't matter; everything gets its address, nothing > is NATted, every address is mapped to a meaningful hostname. > This assumption that an entire household should be a single broadcast (or multicast) domain is fundamentally broken and needs to change going forward. > > Perhaps you'd need more aggregation and routing in the glorious one-IP- > per-nanite-and-Facebook-fridges future, but that's for another day once > we've got fusion and a rational system of government out of the way:-) > Joe's network as described isn't big enough or clever enough to need > multiple routers. It's just a small LAN and it's only Joe's weirdness in > using a $500 Roku as a $5 hank of cat5e and a $20 4-port switch that > prevents it from being so. > I think that the nanites and fridges that talk to other kitchen storage systems will actually happen well before fusion or rational government. Just because what you describe of today's situation is an accurate picture of today does not mean it is how we should plan IPv6. Remember, we don't want to have to replan IPv6 or switch to yet another numbering system for several years, if not decades. In case you hadn't noticed, doing so at today's scale is hard. Imagine what it will be like next time. > > Not all problems should be solved by routing - but a list full of > "router people" is inherently likely to try to solve all its problems > with more routers and routing. There are reasons to route and reasons to switch. I don't consider myself a router person, but, I do consider myself a network engineer, so, I try to use the right tool for the right job. In the case of LAN isolation which I can see several desirable applications for in a home, I think routing is a better choice than switching. Remember, the multicast scopes in IPv6 are interface, link, and larger. There's no scope in between everything on this interface and everything on this link. (link == layer 3 network). Owen From jeroen at unfix.org Wed Aug 10 08:57:54 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Aug 2011 15:57:54 +0200 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> Message-ID: <4E428E62.40700@unfix.org> On 2011-08-10 15:02 , Owen DeLong wrote: [..] > Why do I want my appliance network's multicast packets getting tossed > around on the guest wireless? Even wikipedia knows the answer to that: http://en.wikipedia.org/wiki/IGMP_snooping which is the first hit for IGMP snooping, which is generally a feature that is present in the better (and thus more expensive) switching gear (and thus probably not present in every home, but those homes probably also don't care about that). Granted, routing is the better and more appropriate way to isolate these kind of packets and definitely more appropriate for broadcast nastyness (mDNS is such a nice one there too...). That said, /56 or /48 to the home should be what is happening. The whole point of settling on a single prefix btw is so that networks can at least keep the same numbering plan when they switch from one PA prefix to another. Greets, Jeroen PS: the more power to your kids if they can sniff the network for your 'adult content', decode it, and then actually watch it (though if they are technically inclined actually not too difficult, but heck, is that not where crypto comes into play, as when they can pull that off on your kiddienetwork they can also just plug something into the kiddie-'adult content'-network and sniff it off there... something with 802.1x comes to mind to solve that step. From a.harrowell at gmail.com Wed Aug 10 10:07:36 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 10 Aug 2011 16:07:36 +0100 Subject: IPv6 end user addressing In-Reply-To: <4E428E62.40700@unfix.org> References: <4E428E62.40700@unfix.org> Message-ID: <201108101608.08365.a.harrowell@gmail.com> On Wednesday 10 Aug 2011 14:57:54 Jeroen Massar wrote: > PS: the more power to your kids if they can sniff the network for your > 'adult content', decode it, and then actually watch it Indeed; I'd be more interested in making sure that, say, you can efficiently multicast the live footy to two different screens in the house, and things work automatically so they get used. I think we're operating on radically different Bayesian priors here and I wonder if a European/American issue is involved. (PS, can you buy a switch that will do production grade IPv6, i.e. with things like RA guard, and not do IGMP-snooping?) -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From khelms at ispalliance.net Wed Aug 10 10:11:32 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 10 Aug 2011 11:11:32 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> Message-ID: <4E429FA4.2070506@ispalliance.net> Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. On 8/10/2011 9:02 AM, Owen DeLong wrote: > > Bridging eliminates the multicast isolation that you get from routing. > > This is not a case for bridging, it's a case for making it possible to do real > routing in the home and we now have the space and the technology to > actually do it in a meaningful and sufficiently automatic way as to be > applicable to Joe 6-Mac. > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From dr at cluenet.de Wed Aug 10 11:36:43 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 10 Aug 2011 18:36:43 +0200 Subject: I'm missing 2 bytes (GRE implementation) In-Reply-To: References: Message-ID: <20110810163643.GA5409@srv03.cluenet.de> On Wed, Aug 10, 2011 at 12:57:44AM +0000, Franck Martin wrote: > I'm using a GRE IPv4 tunnel between a cisco and linux machines Can you mail: IOS: - sh run int TuX - sh int TuX | i MTU - sh ip int TuX | i MTU Linux: - output of "/sbin/ip link show greX" (or whatever your GRE interface is named) > I did some packet capture, and saw that my MTU was 1418 What MTU? Including which overheads? :-) > but the cisco was sending TCP packet with a MSS of 1380. Using which TCP options? How large was the TCP overhead? > This created a bunch of issues. When I told the cisco box to use a MSS of 1378 everything starting to work fine. > > So why Cisco is off by 2 Bytes? The only GRE options using 2 bytes are GRE checksum and offset. Haven't seen any of them being used by default by IOS. IOS default GRE payload MTU traversing an IPv4 MTU 1500 egress interface is 1476 (1500 minus 20 octets IPv4 header, 4 octets GRE header). But e.g. TCP SACK permit option on SYN packets would be 2 octets. > Does the GRE implementation on Linux uses 2 extra bytes compared to > Cisco (or vice versa)? Not by default, in my experience. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From tjc at ecs.soton.ac.uk Wed Aug 10 11:57:13 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 10 Aug 2011 17:57:13 +0100 Subject: IPv6 end user addressing In-Reply-To: <4E429FA4.2070506@ispalliance.net> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> Message-ID: On 10 Aug 2011, at 16:11, Scott Helms wrote: > Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. Well, there is some new effort on this in the homenet WG in IETF. For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. Tim > On 8/10/2011 9:02 AM, Owen DeLong wrote: >> >> Bridging eliminates the multicast isolation that you get from routing. >> >> This is not a case for bridging, it's a case for making it possible to do real >> routing in the home and we now have the space and the technology to >> actually do it in a meaningful and sufficiently automatic way as to be >> applicable to Joe 6-Mac. >> > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > From bill at herrin.us Wed Aug 10 12:26:02 2011 From: bill at herrin.us (William Herrin) Date: Wed, 10 Aug 2011 13:26:02 -0400 Subject: I'm missing 2 bytes (GRE implementation) In-Reply-To: <20110810163643.GA5409@srv03.cluenet.de> References: <20110810163643.GA5409@srv03.cluenet.de> Message-ID: On Wed, Aug 10, 2011 at 12:36 PM, Daniel Roesen wrote: > On Wed, Aug 10, 2011 at 12:57:44AM +0000, Franck Martin wrote: >> I'm using a GRE IPv4 tunnel between a cisco and linux machines >> So why Cisco is off by 2 Bytes? > > The only GRE options using 2 bytes are GRE checksum and offset. Haven't > seen any of them being used by default by IOS. IOS default GRE payload > MTU traversing an IPv4 MTU 1500 egress interface is 1476 (1500 minus 20 > octets IPv4 header, 4 octets GRE header). Handy reference: http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation#Packet_header The GRE header length will be evenly divisible by 4. If the checksum is present then so is the offset, and vice versa. So if you're seeing a 2 byte (not 4 byte) difference that's coming from somewhere else. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Aug 10 13:03:59 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 11:03:59 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E428E62.40700@unfix.org> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: On Aug 10, 2011, at 6:57 AM, Jeroen Massar wrote: > On 2011-08-10 15:02 , Owen DeLong wrote: > [..] >> Why do I want my appliance network's multicast packets getting tossed >> around on the guest wireless? > > Even wikipedia knows the answer to that: > http://en.wikipedia.org/wiki/IGMP_snooping > which is the first hit for IGMP snooping, which is generally a feature > that is present in the better (and thus more expensive) switching gear > (and thus probably not present in every home, but those homes probably > also don't care about that). > That would be the answer to why I DON'T want that happening, but, why would I WANT it to happen when, as you said, the better and more appropriate solution is to route. Unless you have some benefit to offer from NOT Routing, I stand by my statement. > Granted, routing is the better and more appropriate way to isolate these > kind of packets and definitely more appropriate for broadcast nastyness > (mDNS is such a nice one there too...). > > That said, /56 or /48 to the home should be what is happening. > That said, /48 to the home should be what is happening, and /56 is a better compromise than anything smaller. > The whole point of settling on a single prefix btw is so that networks > can at least keep the same numbering plan when they switch from one PA > prefix to another. > That would be nice as well, but, unfortunately, it is obvious at this point that some ISPs will unfortunately refuse to give home users /48s. > Greets, > Jeroen > > PS: the more power to your kids if they can sniff the network for your > 'adult content', decode it, and then actually watch it (though if they > are technically inclined actually not too difficult, but heck, is that > not where crypto comes into play, as when they can pull that off on your > kiddienetwork they can also just plug something into the kiddie-'adult > content'-network and sniff it off there... something with 802.1x comes > to mind to solve that step. The chances of the average amplifier and television supporting that level of encryption in a way that the hypothetical kids in this situation would be unable to decrypt a stream that does work between the source and the television and amplifier are pretty slim IMHO. Heck, I can't even get any one of those devices to speak IPv6 yet, let alone all of them and with cryptography to boot. Owen From jsw at inconcepts.biz Wed Aug 10 13:11:29 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 10 Aug 2011 14:11:29 -0400 Subject: IPv6 end user addressing In-Reply-To: <201108101155.35498.a.harrowell@gmail.com> References: <201108101155.35498.a.harrowell@gmail.com> Message-ID: On Wed, Aug 10, 2011 at 6:55 AM, Alexander Harrowell wrote: > Thinking about the CPE thread, isn't this a case for bridging as a > feature in end-user devices? If Joe's media-centre box etc would bridge > its downstream ports to the upstream port, the devices on them could > just get an address, whether by DHCPv6 from the CPE router's delegation > or by SLAAC, and then register in local DNS or more likely do multicast- > DNS so they could find each other. This would require the ISP gateway to have IPv6 ND entries for all of the end-user's devices. If that is only a few devices, like the typical SOHO LAN today, that's probably fine. It is not fine if I purchase some IPv6-connected nanobots. Given today's routers, it is probably not even fine if the average SOHO goes from 1 state entry to just 20 or 30. I have about 20 devices in my home that use the Internet -- TVs, DVRs, VoIP telephones, printer, mobile phones with Wi-Fi, a couple of video game consoles, etc. I imagine that is not atypical these days. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Wed Aug 10 13:17:54 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 10 Aug 2011 14:17:54 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: > That said, /48 to the home should be what is happening, and /56 is > a better compromise than anything smaller. Is hierarchical routing within the SOHO network the reason you believe /48 is useful? You don't really imagine that end-users will require more than 2^8 subnets, but that they will want several levels of very simple, nibble-aligned routers within their network? This is perhaps a good discussion to have. I, for one, see CPE vendors still shipping products without IPv6 support at all, let alone any mechanism for creating an address or routing hierarchy within the home without the end-user configuring it himself. I am not aware of any automatic means to do this, or even any working group trying to produce that feature. Is it true that there is no existing work on this? If that is the case, why would we not try to steer any such future work in such a way that it can manage to do what the end-user wants without requiring a /48 in their home? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From khelms at ispalliance.net Wed Aug 10 13:43:29 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 10 Aug 2011 14:43:29 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> Message-ID: <4E42D151.6020603@ispalliance.net> Tim, Hence the "might". I worry when people start throwing around terms like routing in the home that they don't understand the complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation & managemenet, and (perhaps most importantly) the economics of mass adoption. This one of the choices that made DSL deployments more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete. http://goo.gl/exwqu On 8/10/2011 12:57 PM, Tim Chown wrote: > On 10 Aug 2011, at 16:11, Scott Helms wrote: > >> Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. > Well, there is some new effort on this in the homenet WG in IETF. > > For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. > > Tim > >> On 8/10/2011 9:02 AM, Owen DeLong wrote: >>> Bridging eliminates the multicast isolation that you get from routing. >>> >>> This is not a case for bridging, it's a case for making it possible to do real >>> routing in the home and we now have the space and the technology to >>> actually do it in a meaningful and sufficiently automatic way as to be >>> applicable to Joe 6-Mac. >>> >> -- >> Scott Helms >> Vice President of Technology >> ISP Alliance, Inc. DBA ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From betty at newnog.org Wed Aug 10 16:23:36 2011 From: betty at newnog.org (Betty Burke) Date: Wed, 10 Aug 2011 17:23:36 -0400 Subject: [NANOG-announce] 2011 NANOG Elections Message-ID: Colleagues: Elections for three of the six elected positions on the NewNOG/NANOG Board of Directors will be held in October 2011, for two-year terms ending in October 2013. The current Board members whose terms are expiring are: ? Steve Feldman ? Sylvie LaPerriere ? Duane Wessels ? Mike Smith (Completing a vacant seat on the Board) Steve is term-limited and cannot be considered for re-election until October 2012. For more information about the role of the Board, or to find out more about what's involved in being a Board member, please consult the NANOG bylaws or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/documents/By-Laws_20110104.pdf http://www.nanog.org/governance/board.html Per the bylaws, Board members must be members of NANOG and attend at least two of three NANOG meetings per year while in office. Also, a reminder, only NANOG members will be eligible to vote in the 2011 Election process. Confirmed candidates will also be asked to complete a questionnaire describing their qualifications, and to submit a statement of candidacy to be presented at the members meeting during NANOG 53." Each candidate must declare any and all affiliation(s) relevant to NewNOG, which will include his or her main employer, as well as any other major relationships (for instance, if a candidate's primary employer is a nonprofit entity which is sponsored by a vendor, the candidate would declare both the nonprofit and the vendor as affiliations). HOW TO NOMINATE SOMEONE If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations at nanog.org. The deadline for nominations is 11:59 PM EDT on Tuesday, September 6, 2011. The candidates are encouraged to make brief comments and/or accept questions from the community at the NANOG 53 Members Meeting. ELECTION TIMELINE As a reminder, the full election timeline is: August 9: Board Nominations begin August 6: Board Candidate information posted/nominations close September 6: Deadline for submitting bylaw amendments September 21: Ballot approved October 9, 2:00 PM EDT: Voting opens October 11, 5:00 PM EDT: Voting closes Results will be announced on September 12 at 9:00 AM EDT. Betty on behalf of the 2011 Elections Subcommittee -- Betty Burke NewNOG/NANOG Executive Director -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From rs at seastrom.com Wed Aug 10 16:34:57 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 10 Aug 2011 17:34:57 -0400 Subject: NANOG Board Announcement In-Reply-To: (Steven Feldman's message of "Tue, 9 Aug 2011 16:59:29 -0700") References: Message-ID: <86d3gdc5mm.fsf@seastrom.com> Steven Feldman writes: > I am sad to announce that Robert Seastrom has resigned from the NewNOG > Board of Directors, effective yesterday. > > Accordingly, the board has selected Michael K. Smith to fill the > vacant position between now and the October Election. Just wanted to follow up on this. It's been an honor to be able to serve the community in this way, but lately my personal commitments (work and family) have made it impossible to live up to the SLA which I feel I owe NANOG, so I felt it was my duty to make room for someone who has the bandwidth to contribute in the way that I wish I could. I'm really excited to see Michael stepping into this new role; his record with the Communications Committee speaks for itself and I think he's absolutely the right guy for the job. Hats off to Michael. See you in San Diego! [*] -r [*] I won't be at the October meeting. My fiancee has made it clear that a NANOG and ARIN honeymoon is not on her top 10 list, and declined a suggestion that we submit our wedding vows to the ARIN AC on a policy template. From deric.kwok2000 at gmail.com Wed Aug 10 16:35:18 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Wed, 10 Aug 2011 17:35:18 -0400 Subject: network issue help Message-ID: Hi There is problem in our network. The connection is disappearing. ls it about lop ing? How can I check it in switch? ls spammingtree disable by default? Thank you so much From tim at interworx.nl Wed Aug 10 16:37:04 2011 From: tim at interworx.nl (Tim Vollebregt) Date: Wed, 10 Aug 2011 23:37:04 +0200 Subject: network issue help In-Reply-To: References: Message-ID: http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 Here you go.. On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: > Hi > > There is problem in our network. The connection is disappearing. > > ls it about lop ing? > > How can I check it in switch? > > ls spammingtree disable by default? > > Thank you so much > From bhmccie at gmail.com Wed Aug 10 16:39:53 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 10 Aug 2011 16:39:53 -0500 Subject: network issue help In-Reply-To: References: Message-ID: <4E42FAA9.8070605@gmail.com> LOL -Hammer- "I was a normal American nerd" -Jack Herer On 08/10/2011 04:37 PM, Tim Vollebregt wrote: > http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 > > Here you go.. > On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: > > >> Hi >> >> There is problem in our network. The connection is disappearing. >> >> ls it about lop ing? >> >> How can I check it in switch? >> >> ls spammingtree disable by default? >> >> Thank you so much >> >> > > From jason at biel-tech.com Wed Aug 10 16:45:33 2011 From: jason at biel-tech.com (Jason Biel) Date: Wed, 10 Aug 2011 16:45:33 -0500 Subject: network issue help In-Reply-To: <4E42FAA9.8070605@gmail.com> References: <4E42FAA9.8070605@gmail.com> Message-ID: Is it to the point where I can just forward the emails from help desk to NANOG so I don't have to answer them? Biel On Wed, Aug 10, 2011 at 4:39 PM, -Hammer- wrote: > LOL > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > > On 08/10/2011 04:37 PM, Tim Vollebregt wrote: > >> http://www.amazon.com/**Networking-Dummies-Doug-Lowe/**dp/0470534052 >> >> Here you go.. >> On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: >> >> >> >>> Hi >>> >>> There is problem in our network. The connection is disappearing. >>> >>> ls it about lop ing? >>> >>> How can I check it in switch? >>> >>> ls spammingtree disable by default? >>> >>> Thank you so much >>> >>> >>> >> >> >> > -- Jason From leigh.porter at ukbroadband.com Wed Aug 10 16:50:27 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 10 Aug 2011 21:50:27 +0000 Subject: network issue help In-Reply-To: References: <4E42FAA9.8070605@gmail.com>, Message-ID: I just wish spammingtree was on by default. -- Leigh Porter On 10 Aug 2011, at 22:47, "Jason Biel" wrote: > Is it to the point where I can just forward the emails from help desk to > NANOG so I don't have to answer them? > > Biel > > On Wed, Aug 10, 2011 at 4:39 PM, -Hammer- wrote: > >> LOL >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> >> On 08/10/2011 04:37 PM, Tim Vollebregt wrote: >> >>> http://www.amazon.com/**Networking-Dummies-Doug-Lowe/**dp/0470534052 >>> >>> Here you go.. >>> On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: >>> >>> >>> >>>> Hi >>>> >>>> There is problem in our network. The connection is disappearing. >>>> >>>> ls it about lop ing? >>>> >>>> How can I check it in switch? >>>> >>>> ls spammingtree disable by default? >>>> >>>> Thank you so much >>>> >>>> >>>> >>> >>> >>> >> > > > -- > Jason > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Valdis.Kletnieks at vt.edu Wed Aug 10 16:54:31 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 Aug 2011 17:54:31 -0400 Subject: network issue help In-Reply-To: Your message of "Wed, 10 Aug 2011 23:37:04 +0200." References: Message-ID: <39602.1313013271@turing-police.cc.vt.edu> On Wed, 10 Aug 2011 23:37:04 +0200, Tim Vollebregt said: > http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 > > Here you go.. Oh, and he wants to read this helpful guide by Eric S. Raymond, too: http://www.catb.org/~esr/faqs/smart-questions.html Deric doesn't know he wants to.. but he *wants* to. *Right Now*. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dwhite at olp.net Wed Aug 10 17:09:17 2011 From: dwhite at olp.net (Dan White) Date: Wed, 10 Aug 2011 17:09:17 -0500 Subject: network issue help In-Reply-To: <39602.1313013271@turing-police.cc.vt.edu> References: <39602.1313013271@turing-police.cc.vt.edu> Message-ID: <20110810220917.GH4565@dan.olp.net> On 10/08/11?17:54?-0400, Valdis.Kletnieks at vt.edu wrote: >On Wed, 10 Aug 2011 23:37:04 +0200, Tim Vollebregt said: >> http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 >> >> Here you go.. > >Oh, and he wants to read this helpful guide by Eric S. Raymond, too: > >http://www.catb.org/~esr/faqs/smart-questions.html > >Deric doesn't know he wants to.. but he *wants* to. *Right Now*. :) And along similar lines - "How to Report Bugs Effectively": http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Dan White From chaim.rieger at gmail.com Wed Aug 10 17:15:41 2011 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 10 Aug 2011 15:15:41 -0700 Subject: network issue help In-Reply-To: References: Message-ID: <4E43030D.3050505@gmail.com> replied inline, with a summary below On 8/10/2011 2:35 PM, Deric Kwok wrote: > Hi > > There is problem in our network. The connection is disappearing. From this i take is that you are using the avaya networking gear with the fcoe protocol enabled, this is a big no-no. you need to disable ipsec, then enable dns, your connection should come right back > > ls it about lop ing? it is not about lops at all, nor is it about looping, its all about the trees dude, there is a hidder feature called, treehugger protocol. and this will help prevent looping in the long term, its hidden behind the power chord, unplug the power cable from your switch, and you will see it between the three prongs. no that you can see this, test for excessive looping > > How can I check it in switch? if the step above failed, i would take the cable that is plugged into port 7 of your switch and plug the other end into port 13, it might help, i would also leave in there for a while, and go grab a cup of coffee > > ls spammingtree disable by default? only if there are branches > > Thank you so much welcome > > From owen at delong.com Wed Aug 10 17:33:20 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 15:33:20 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E429FA4.2070506@ispalliance.net> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> Message-ID: <48838ED8-1C06-493E-8FA5-5BBB96873BD8@delong.com> There is some deployable technology that allows some aspects of this today. Yes, it's in its infancy. Small prefix limitations will guarantee it never sees the light of day just as NAT precluded many useful innovations from getting deployed. Layer 3 isolation is only isolation by agreement if the hosts have some way to get on the same physical or logical LAN layer 2 segment. Otherwise, layer 3 isolation is as effective as any firewall. Layer 2 isolation, OTOH, is both harder to administer and no more effective than layer 3. If you can bypass layer 3 by connecting to the same LAN segment, chances are you can bypass layer 2 by making that LAN segment one which doesn't go through the enforcement switch between the two devices in question. Owen On Aug 10, 2011, at 8:11 AM, Scott Helms wrote: > Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. > > On 8/10/2011 9:02 AM, Owen DeLong wrote: >> >> Bridging eliminates the multicast isolation that you get from routing. >> >> This is not a case for bridging, it's a case for making it possible to do real >> routing in the home and we now have the space and the technology to >> actually do it in a meaningful and sufficiently automatic way as to be >> applicable to Joe 6-Mac. >> > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From jason at biel-tech.com Wed Aug 10 17:51:52 2011 From: jason at biel-tech.com (Jason Biel) Date: Wed, 10 Aug 2011 17:51:52 -0500 Subject: network issue help In-Reply-To: <4E43030D.3050505@gmail.com> References: <4E43030D.3050505@gmail.com> Message-ID: TBH, this thread has made the hour preceding my Juniper upgrades *way* more enjoyable. On Wed, Aug 10, 2011 at 5:15 PM, Chaim Rieger wrote: > replied inline, with a summary below > > > On 8/10/2011 2:35 PM, Deric Kwok wrote: > >> Hi >> >> There is problem in our network. The connection is disappearing. >> > From this i take is that you are using the avaya networking gear with the > fcoe protocol enabled, this is a big no-no. you need to disable ipsec, then > enable dns, your connection should come right back > > >> ls it about lop ing? >> > it is not about lops at all, nor is it about looping, its all about the > trees dude, there is a hidder feature called, treehugger protocol. and this > will help prevent looping in the long term, its hidden behind the power > chord, unplug the power cable from your switch, and you will see it between > the three prongs. no that you can see this, test for excessive looping > > >> How can I check it in switch? >> > if the step above failed, i would take the cable that is plugged into port > 7 of your switch and plug the other end into port 13, it might help, i would > also leave in there for a while, and go grab a cup of coffee > > >> ls spammingtree disable by default? >> > only if there are branches > >> >> Thank you so much >> > welcome > >> >> >> > > -- Jason From brandon.kim at brandontek.com Wed Aug 10 18:10:59 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 10 Aug 2011 19:10:59 -0400 Subject: network issue help In-Reply-To: References: , , <4E42FAA9.8070605@gmail.com>, , , Message-ID: haha! Spammingtree! I love it!!! > From: leigh.porter at ukbroadband.com > To: jason at biel-tech.com > Subject: Re: network issue help > Date: Wed, 10 Aug 2011 21:50:27 +0000 > CC: nanog at nanog.org > > I just wish spammingtree was on by default. > > -- > Leigh Porter > > > On 10 Aug 2011, at 22:47, "Jason Biel" wrote: > > > Is it to the point where I can just forward the emails from help desk to > > NANOG so I don't have to answer them? > > > > Biel > > > > On Wed, Aug 10, 2011 at 4:39 PM, -Hammer- wrote: > > > >> LOL > >> > >> -Hammer- > >> > >> "I was a normal American nerd" > >> -Jack Herer > >> > >> > >> > >> > >> On 08/10/2011 04:37 PM, Tim Vollebregt wrote: > >> > >>> http://www.amazon.com/**Networking-Dummies-Doug-Lowe/**dp/0470534052 > >>> > >>> Here you go.. > >>> On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: > >>> > >>> > >>> > >>>> Hi > >>>> > >>>> There is problem in our network. The connection is disappearing. > >>>> > >>>> ls it about lop ing? > >>>> > >>>> How can I check it in switch? > >>>> > >>>> ls spammingtree disable by default? > >>>> > >>>> Thank you so much > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > -- > > Jason > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From owen at delong.com Wed Aug 10 18:12:31 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 16:12:31 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> On Aug 10, 2011, at 11:17 AM, Jeff Wheeler wrote: > On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: >> That said, /48 to the home should be what is happening, and /56 is >> a better compromise than anything smaller. > > Is hierarchical routing within the SOHO network the reason you believe > /48 is useful? You don't really imagine that end-users will require > more than 2^8 subnets, but that they will want several levels of very > simple, nibble-aligned routers within their network? > Not necessarily nibble aligned, but, multiple bits per level, yes. > This is perhaps a good discussion to have. I, for one, see CPE > vendors still shipping products without IPv6 support at all, let alone > any mechanism for creating an address or routing hierarchy within the > home without the end-user configuring it himself. I am not aware of > any automatic means to do this, or even any working group trying to > produce that feature. > If we are stingy in address allocations, it will stifle such innovations as the vendors tend to develop to the lowest common denominator. If we make the allocations available, innovative ideas will make use of them. > Is it true that there is no existing work on this? If that is the > case, why would we not try to steer any such future work in such a way > that it can manage to do what the end-user wants without requiring a > /48 in their home? > No, it is not true. I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future. Have we learned nothing from the way NAT shaped the (lack of) innovation in the home? Owen From tammy-lists at wiztech.biz Wed Aug 10 18:26:13 2011 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Wed, 10 Aug 2011 17:26:13 -0600 (MDT) Subject: network issue help In-Reply-To: Message-ID: <0fcdc524-3ac8-419f-8e79-821c69ad364e@lordsofacid.wiztech.biz> solution: quit smoking crack. ----- Original Message ----- > From: "Deric Kwok" > To: "nanog list" > Sent: Wednesday, August 10, 2011 3:35:18 PM > Subject: network issue help > > Hi > > There is problem in our network. The connection is disappearing. > > ls it about lop ing? > > How can I check it in switch? > > ls spammingtree disable by default? > > Thank you so much > > From sfouant at shortestpathfirst.net Wed Aug 10 18:33:53 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 10 Aug 2011 19:33:53 -0400 Subject: network issue help In-Reply-To: References: Message-ID: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> Is there an acronym for RTFM when there are a volume of manuals that need to be read? Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 5:35 PM, Deric Kwok wrote: > Hi > > There is problem in our network. The connection is disappearing. > > ls it about lop ing? > > How can I check it in switch? > > ls spammingtree disable by default? > > Thank you so much > From garrett at skjelstad.org Wed Aug 10 18:47:10 2011 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Wed, 10 Aug 2011 16:47:10 -0700 Subject: network issue help In-Reply-To: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> Message-ID: Yea, it's T2SP or Time to Switch Professions... Sent from my iPhone On Aug 10, 2011, at 16:33, Stefan Fouant wrote: > Is there an acronym for RTFM when there are a volume of manuals that need to be read? > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 10, 2011, at 5:35 PM, Deric Kwok wrote: > >> Hi >> >> There is problem in our network. The connection is disappearing. >> >> ls it about lop ing? >> >> How can I check it in switch? >> >> ls spammingtree disable by default? >> >> Thank you so much >> > From jsw at inconcepts.biz Wed Aug 10 18:53:56 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 10 Aug 2011 19:53:56 -0400 Subject: IPv6 end user addressing In-Reply-To: <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong wrote: >> Is it true that there is no existing work on this? ?If that is the >> case, why would we not try to steer any such future work in such a way >> that it can manage to do what the end-user wants without requiring a >> /48 in their home? > > No, it is not true. Can you give any example of a product, or on-going work? I have read two posts from you today saying that something either exists already, or is being worked on. I haven't read this anywhere else. > I suppose that limiting enough households to too small an allocation > will have that effect. I would rather we steer the internet deployment > towards liberal enough allocations to avoid such disability for the > future. > > Have we learned nothing from the way NAT shaped the (lack of) > innovation in the home? I am afraid we may not have learned from exhausting IPv4. If I may use the Hurricane Electric tunnel broker as an example again, supposing that is an independent service with no relation to your hosting, transit, etc. operations, it can justify a /24 allocation immediately under 2011-3, without even relying on growth projections. That's a middle ground figure that we can all live with, but it is based on you serving (at this moment) only 8000 tunnels at your busiest tunnel gateway. If your tunnel gateways could serve 12,288 + 1 users each, then your /24 justification grows to a /20. So you would have a pretty significant chunk of the available IPv6 address space for a fairly small number of end-users -- about 72,543 at present. It isn't hard to do some arithmetic and guess that if every household in the world had IPv6 connectivity from a relatively low-density service like the above example, we would still only burn through about 3% of the IPv6 address space on end-users (nothing said about server farms, etc. here) but what does bother me is that the typical end-user today has one, single IP address; and now we will be issuing them 2^16 subnets; yet it is not too hard to imagine a future where the global IPv6 address pool becomes constrained due to service-provider inefficiency. I would like to have innovations in SOHO devices, too; who knows what these may be. But I fear we may repeat the mistake that caused NAT to be a necessity in IPv4 -- exhausting address space -- by foolishly assuming that every household is going to need twenty-four orders of magnitude more public addresses than it has today. That is what these practices do -- they literally give end-users twenty-four orders of magnitude more addresses, while it is easy to imagine that we will come within one order of magnitude of running completely out of IPv6 addresses for issuing to service providers. I didn't know what the digit "1" followed by twenty-four zeroes was called. I had to look it up. So our end-users will be receiving about one-Septillion addresses to use in their home, but no one seems to be asking what future technology we may be harming by possibly constraining the global address pool. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From ken.henault at hp.com Wed Aug 10 18:57:26 2011 From: ken.henault at hp.com (Henault, Ken) Date: Thu, 11 Aug 2011 00:57:26 +0100 Subject: NANOG Digest, Vol 43, Issue 37 Message-ID: <4900ECFB68765141B437958EF008863875F3F64260@GVW1119EXC.americas.hpqcorp.net> Ken Henault senior infrastructure architect enterprise solutions & architecture e-mail: bladeguy at hp.com phone: 603-421-2852 twitter: @bladeguy ________________________________ On Aug 10, 2011 7:47 PM, nanog-request at nanog.org wrote: Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: network issue help (Valdis.Kletnieks at vt.edu) 2. Re: network issue help (Dan White) 3. Re: network issue help (Chaim Rieger) 4. Re: IPv6 end user addressing (Owen DeLong) 5. Re: network issue help (Jason Biel) 6. RE: network issue help (Brandon Kim) 7. Re: IPv6 end user addressing (Owen DeLong) 8. Re: network issue help (Tammy A. Wisdom) 9. Re: network issue help (Stefan Fouant) 10. Re: network issue help (Garrett Skjelstad) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Aug 2011 17:54:31 -0400 From: Valdis.Kletnieks at vt.edu To: Tim Vollebregt Cc: nanog list Subject: Re: network issue help Message-ID: <39602.1313013271 at turing-police.cc.vt.edu> Content-Type: text/plain; charset="us-ascii" On Wed, 10 Aug 2011 23:37:04 +0200, Tim Vollebregt said: > http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 > > Here you go.. Oh, and he wants to read this helpful guide by Eric S. Raymond, too: http://www.catb.org/~esr/faqs/smart-questions.html Deric doesn't know he wants to.. but he *wants* to. *Right Now*. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: ------------------------------ Message: 2 Date: Wed, 10 Aug 2011 17:09:17 -0500 From: Dan White To: Valdis.Kletnieks at vt.edu Cc: nanog list Subject: Re: network issue help Message-ID: <20110810220917.GH4565 at dan.olp.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed On 10/08/11?17:54?-0400, Valdis.Kletnieks at vt.edu wrote: >On Wed, 10 Aug 2011 23:37:04 +0200, Tim Vollebregt said: >> http://www.amazon.com/Networking-Dummies-Doug-Lowe/dp/0470534052 >> >> Here you go.. > >Oh, and he wants to read this helpful guide by Eric S. Raymond, too: > >http://www.catb.org/~esr/faqs/smart-questions.html > >Deric doesn't know he wants to.. but he *wants* to. *Right Now*. :) And along similar lines - "How to Report Bugs Effectively": http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Dan White ------------------------------ Message: 3 Date: Wed, 10 Aug 2011 15:15:41 -0700 From: Chaim Rieger To: nanog at nanog.org Subject: Re: network issue help Message-ID: <4E43030D.3050505 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed replied inline, with a summary below On 8/10/2011 2:35 PM, Deric Kwok wrote: > Hi > > There is problem in our network. The connection is disappearing. From this i take is that you are using the avaya networking gear with the fcoe protocol enabled, this is a big no-no. you need to disable ipsec, then enable dns, your connection should come right back > > ls it about lop ing? it is not about lops at all, nor is it about looping, its all about the trees dude, there is a hidder feature called, treehugger protocol. and this will help prevent looping in the long term, its hidden behind the power chord, unplug the power cable from your switch, and you will see it between the three prongs. no that you can see this, test for excessive looping > > How can I check it in switch? if the step above failed, i would take the cable that is plugged into port 7 of your switch and plug the other end into port 13, it might help, i would also leave in there for a while, and go grab a cup of coffee > > ls spammingtree disable by default? only if there are branches > > Thank you so much welcome > > ------------------------------ Message: 4 Date: Wed, 10 Aug 2011 15:33:20 -0700 From: Owen DeLong To: Scott Helms Cc: nanog at nanog.org Subject: Re: IPv6 end user addressing Message-ID: <48838ED8-1C06-493E-8FA5-5BBB96873BD8 at delong.com> Content-Type: text/plain; charset=us-ascii There is some deployable technology that allows some aspects of this today. Yes, it's in its infancy. Small prefix limitations will guarantee it never sees the light of day just as NAT precluded many useful innovations from getting deployed. Layer 3 isolation is only isolation by agreement if the hosts have some way to get on the same physical or logical LAN layer 2 segment. Otherwise, layer 3 isolation is as effective as any firewall. Layer 2 isolation, OTOH, is both harder to administer and no more effective than layer 3. If you can bypass layer 3 by connecting to the same LAN segment, chances are you can bypass layer 2 by making that LAN segment one which doesn't go through the enforcement switch between the two devices in question. Owen On Aug 10, 2011, at 8:11 AM, Scott Helms wrote: > Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. > > On 8/10/2011 9:02 AM, Owen DeLong wrote: >> >> Bridging eliminates the multicast isolation that you get from routing. >> >> This is not a case for bridging, it's a case for making it possible to do real >> routing in the home and we now have the space and the technology to >> actually do it in a meaningful and sufficiently automatic way as to be >> applicable to Joe 6-Mac. >> > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > ------------------------------ Message: 5 Date: Wed, 10 Aug 2011 17:51:52 -0500 From: Jason Biel To: Chaim Rieger Cc: nanog at nanog.org Subject: Re: network issue help Message-ID: Content-Type: text/plain; charset=ISO-8859-1 TBH, this thread has made the hour preceding my Juniper upgrades *way* more enjoyable. On Wed, Aug 10, 2011 at 5:15 PM, Chaim Rieger wrote: > replied inline, with a summary below > > > On 8/10/2011 2:35 PM, Deric Kwok wrote: > >> Hi >> >> There is problem in our network. The connection is disappearing. >> > From this i take is that you are using the avaya networking gear with the > fcoe protocol enabled, this is a big no-no. you need to disable ipsec, then > enable dns, your connection should come right back > > >> ls it about lop ing? >> > it is not about lops at all, nor is it about looping, its all about the > trees dude, there is a hidder feature called, treehugger protocol. and this > will help prevent looping in the long term, its hidden behind the power > chord, unplug the power cable from your switch, and you will see it between > the three prongs. no that you can see this, test for excessive looping > > >> How can I check it in switch? >> > if the step above failed, i would take the cable that is plugged into port > 7 of your switch and plug the other end into port 13, it might help, i would > also leave in there for a while, and go grab a cup of coffee > > >> ls spammingtree disable by default? >> > only if there are branches > >> >> Thank you so much >> > welcome > >> >> >> > > -- Jason ------------------------------ Message: 6 Date: Wed, 10 Aug 2011 19:10:59 -0400 From: Brandon Kim To: , Cc: nanog group Subject: RE: network issue help Message-ID: Content-Type: text/plain; charset="iso-8859-1" haha! Spammingtree! I love it!!! > From: leigh.porter at ukbroadband.com > To: jason at biel-tech.com > Subject: Re: network issue help > Date: Wed, 10 Aug 2011 21:50:27 +0000 > CC: nanog at nanog.org > > I just wish spammingtree was on by default. > > -- > Leigh Porter > > > On 10 Aug 2011, at 22:47, "Jason Biel" wrote: > > > Is it to the point where I can just forward the emails from help desk to > > NANOG so I don't have to answer them? > > > > Biel > > > > On Wed, Aug 10, 2011 at 4:39 PM, -Hammer- wrote: > > > >> LOL > >> > >> -Hammer- > >> > >> "I was a normal American nerd" > >> -Jack Herer > >> > >> > >> > >> > >> On 08/10/2011 04:37 PM, Tim Vollebregt wrote: > >> > >>> http://www.amazon.com/**Networking-Dummies-Doug-Lowe/**dp/0470534052 > >>> > >>> Here you go.. > >>> On Aug 10, 2011, at 11:35 PM, Deric Kwok wrote: > >>> > >>> > >>> > >>>> Hi > >>>> > >>>> There is problem in our network. The connection is disappearing. > >>>> > >>>> ls it about lop ing? > >>>> > >>>> How can I check it in switch? > >>>> > >>>> ls spammingtree disable by default? > >>>> > >>>> Thank you so much > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > -- > > Jason > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > ------------------------------ Message: 7 Date: Wed, 10 Aug 2011 16:12:31 -0700 From: Owen DeLong To: Jeff Wheeler Cc: NANOG Subject: Re: IPv6 end user addressing Message-ID: <1F6C0D3C-320E-4D72-BF41-C8796707B932 at delong.com> Content-Type: text/plain; charset=us-ascii On Aug 10, 2011, at 11:17 AM, Jeff Wheeler wrote: > On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: >> That said, /48 to the home should be what is happening, and /56 is >> a better compromise than anything smaller. > > Is hierarchical routing within the SOHO network the reason you believe > /48 is useful? You don't really imagine that end-users will require > more than 2^8 subnets, but that they will want several levels of very > simple, nibble-aligned routers within their network? > Not necessarily nibble aligned, but, multiple bits per level, yes. > This is perhaps a good discussion to have. I, for one, see CPE > vendors still shipping products without IPv6 support at all, let alone > any mechanism for creating an address or routing hierarchy within the > home without the end-user configuring it himself. I am not aware of > any automatic means to do this, or even any working group trying to > produce that feature. > If we are stingy in address allocations, it will stifle such innovations as the vendors tend to develop to the lowest common denominator. If we make the allocations available, innovative ideas will make use of them. > Is it true that there is no existing work on this? If that is the > case, why would we not try to steer any such future work in such a way > that it can manage to do what the end-user wants without requiring a > /48 in their home? > No, it is not true. I suppose that limiting enough households to too small an allocation will have that effect. I would rather we steer the internet deployment towards liberal enough allocations to avoid such disability for the future. Have we learned nothing from the way NAT shaped the (lack of) innovation in the home? Owen ------------------------------ Message: 8 Date: Wed, 10 Aug 2011 17:26:13 -0600 (MDT) From: "Tammy A. Wisdom" To: Deric Kwok Cc: nanog at nanog.org Subject: Re: network issue help Message-ID: <0fcdc524-3ac8-419f-8e79-821c69ad364e at lordsofacid.wiztech.biz> Content-Type: text/plain; charset=utf-8 solution: quit smoking crack. ----- Original Message ----- > From: "Deric Kwok" > To: "nanog list" > Sent: Wednesday, August 10, 2011 3:35:18 PM > Subject: network issue help > > Hi > > There is problem in our network. The connection is disappearing. > > ls it about lop ing? > > How can I check it in switch? > > ls spammingtree disable by default? > > Thank you so much > > ------------------------------ Message: 9 Date: Wed, 10 Aug 2011 19:33:53 -0400 From: Stefan Fouant To: Deric Kwok Cc: nanog list Subject: Re: network issue help Message-ID: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1 at shortestpathfirst.net> Content-Type: text/plain; charset=us-ascii Is there an acronym for RTFM when there are a volume of manuals that need to be read? Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 5:35 PM, Deric Kwok wrote: > Hi > > There is problem in our network. The connection is disappearing. > > ls it about lop ing? > > How can I check it in switch? > > ls spammingtree disable by default? > > Thank you so much > ------------------------------ Message: 10 Date: Wed, 10 Aug 2011 16:47:10 -0700 From: Garrett Skjelstad To: Stefan Fouant Cc: nanog list Subject: Re: network issue help Message-ID: Content-Type: text/plain; charset=us-ascii Yea, it's T2SP or Time to Switch Professions... Sent from my iPhone On Aug 10, 2011, at 16:33, Stefan Fouant wrote: > Is there an acronym for RTFM when there are a volume of manuals that need to be read? > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 10, 2011, at 5:35 PM, Deric Kwok wrote: > >> Hi >> >> There is problem in our network. The connection is disappearing. >> >> ls it about lop ing? >> >> How can I check it in switch? >> >> ls spammingtree disable by default? >> >> Thank you so much >> > End of NANOG Digest, Vol 43, Issue 37 ************************************* From mpalmer at hezmatt.org Wed Aug 10 19:39:59 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 11 Aug 2011 10:39:59 +1000 Subject: network issue help In-Reply-To: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> Message-ID: <20110811003959.GS17327@hezmatt.org> On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: > Is there an acronym for RTFM when there are a volume of manuals that need to be read? FOAD, perhaps? - Matt -- "When you have a Leatherman, everything looks Leathermanipulable." -- Nathan McCoy, in the Monastery From marka at isc.org Wed Aug 10 19:40:52 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 11 Aug 2011 10:40:52 +1000 Subject: IPv6 end user addressing In-Reply-To: Your message of "Wed, 10 Aug 2011 19:53:56 -0400." References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: <20110811004052.3242E12B5DD4@drugs.dv.isc.org> In message , Jeff Wheeler writes: > On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong wrote: > >> Is it true that there is no existing work on this? =A0If that is the > >> case, why would we not try to steer any such future work in such a way > >> that it can manage to do what the end-user wants without requiring a > >> /48 in their home? > > > > No, it is not true. > > Can you give any example of a product, or on-going work? I have read > two posts from you today saying that something either exists already, > or is being worked on. I haven't read this anywhere else. > > > I suppose that limiting enough households to too small an allocation > > will have that effect. I would rather we steer the internet deployment > > towards liberal enough allocations to avoid such disability for the > > future. > > > > Have we learned nothing from the way NAT shaped the (lack of) > > innovation in the home? > > I am afraid we may not have learned from exhausting IPv4. If I may > use the Hurricane Electric tunnel broker as an example again, > supposing that is an independent service with no relation to your > hosting, transit, etc. operations, it can justify a /24 allocation > immediately under 2011-3, without even relying on growth projections. > That's a middle ground figure that we can all live with, but it is > based on you serving (at this moment) only 8000 tunnels at your > busiest tunnel gateway. If your tunnel gateways could serve 12,288 + > 1 users each, then your /24 justification grows to a /20. So you > would have a pretty significant chunk of the available IPv6 address > space for a fairly small number of end-users -- about 72,543 at > present. > > It isn't hard to do some arithmetic and guess that if every household > in the world had IPv6 connectivity from a relatively low-density > service like the above example, we would still only burn through about > 3% of the IPv6 address space on end-users (nothing said about server > farms, etc. here) but what does bother me is that the typical end-user > today has one, single IP address; and now we will be issuing them 2^16 > subnets; yet it is not too hard to imagine a future where the global > IPv6 address pool becomes constrained due to service-provider > inefficiency. No. A typical user has 10 to 20 addresses NAT'd to one public address. My household has * game consoles * laptops * desktops * cell phones * voip phones * printers all connected to the net. It doesn't yet have a media server but otherwise it is pretty typical. Someday, I expect the pantry to have a barcode reader on it connected back a computer setup for the kitchen someday. Most of us already use barcode readers when we shop so its not a big step to home use. Just about anything with fireware in it will eventually connect to the net. The typical household already has 1 or 2 subnets. > I would like to have innovations in SOHO devices, too; who knows what > these may be. But I fear we may repeat the mistake that caused NAT to > be a necessity in IPv4 -- exhausting address space -- by foolishly > assuming that every household is going to need twenty-four orders of > magnitude more public addresses than it has today. > > That is what these practices do -- they literally give end-users > twenty-four orders of magnitude more addresses, while it is easy to > imagine that we will come within one order of magnitude of running > completely out of IPv6 addresses for issuing to service providers. Housholds can get as much internal addressing as they need today and as many nets as they need today with RFC1918. 10/8 broken up into to /24 is equivalent to a /48 broken up into /64s. A /56 is equivalent to 192.168/16 broken up into its class C's. > I didn't know what the digit "1" followed by twenty-four zeroes was > called. I had to look it up. So our end-users will be receiving > about one-Septillion addresses to use in their home, but no one seems > to be asking what future technology we may be harming by possibly > constraining the global address pool. There was a concious decision made a decade and a half ago to got to 128 bits instead of 64 bits and give each subnet 64 bits so we would never have to worry about the size of a subnet again. IPv6 is about managing networks not managing addresses. > --=20 > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hvgeekwtrvl at gmail.com Wed Aug 10 19:45:00 2011 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 10 Aug 2011 17:45:00 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: > It isn't hard to do some arithmetic and guess that if every household > in the world had IPv6 connectivity from a relatively low-density > service like the above example, we would still only burn through about > 3% of the IPv6 address space on end-users (nothing said about server > farms, etc. here) but what does bother me is that the typical end-user > today has one, single IP address; and now we will be issuing them 2^16 > subnets; yet it is not too hard to imagine a future where the global > IPv6 address pool becomes constrained due to service-provider > inefficiency. > what is the life expectancy of IPv6? It won't live forever and we can't reasonably expect it too. I understand we don't want run out of addresses in the next 10-40 years but what about 100? 200? 300? We will run out and our decedents will go through re-numbering again. The question becomes what is the life expectancy of IPv6 and does the allocation plan make a reasonable attempt to run out of addresses around the end of the expected life of IPv6. > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > james From marka at isc.org Wed Aug 10 20:09:48 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 11 Aug 2011 11:09:48 +1000 Subject: IPv6 end user addressing In-Reply-To: Your message of "Wed, 10 Aug 2011 17:45:00 MST." References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: <20110811010948.9FC6512B66F0@drugs.dv.isc.org> In message , james machado writes: > > It isn't hard to do some arithmetic and guess that if every household > > in the world had IPv6 connectivity from a relatively low-density > > service like the above example, we would still only burn through about > > 3% of the IPv6 address space on end-users (nothing said about server > > farms, etc. here) but what does bother me is that the typical end-user > > today has one, single IP address; and now we will be issuing them 2^16 > > subnets; yet it is not too hard to imagine a future where the global > > IPv6 address pool becomes constrained due to service-provider > > inefficiency. > > > > what is the life expectancy of IPv6? It won't live forever and we > can't reasonably expect it too. I understand we don't want run out of > addresses in the next 10-40 years but what about 100? 200? 300? > > We will run out and our decedents will go through re-numbering again. > The question becomes what is the life expectancy of IPv6 and does the > allocation plan make a reasonable attempt to run out of addresses > around the end of the expected life of IPv6. It really depends on whether the RIR's recover and, importantly, reallocate address space that is not being paid for or not. If they do this should last for the forseeable future. It would also be my recommendation that RIR's start doing this immediately, if they are not already doing so, so that there is no expectation that you can use address space forever without paying for it. > > Jeff S Wheeler > > Sr Network Operator=A0 /=A0 Innovative Network Concepts > > > > > > james > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Wed Aug 10 20:22:11 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Aug 2011 21:22:11 -0400 Subject: network issue help In-Reply-To: <20110811003959.GS17327@hezmatt.org> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> Message-ID: On Wed, Aug 10, 2011 at 8:39 PM, Matthew Palmer wrote: > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: >> Is there an acronym for RTFM when there are a volume of manuals that need to be read? > > FOAD, perhaps? folks do get that deric's primary language isn't English right? so asking him to explain is probably 'ok'. (yes, he could have put more details into his mail, yes it would have been more helpful and quicker to an answer for him...) -chris > "When you have a Leatherman, everything looks Leathermanipulable." > ? ? ? ?-- Nathan McCoy, in the Monastery > > > From jsw at inconcepts.biz Wed Aug 10 20:33:46 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 10 Aug 2011 21:33:46 -0400 Subject: IPv6 end user addressing In-Reply-To: <20110811004052.3242E12B5DD4@drugs.dv.isc.org> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: On Wed, Aug 10, 2011 at 8:40 PM, Mark Andrews wrote: > No. ?A typical user has 10 to 20 addresses NAT'd to one public address. I'd say this is fair. Amazingly enough, it all basically works right with one IP address today. It will certainly be nice to have the option to give all these devices public IP addresses, or even have a few public subnets; but it does require more imagination than any of us have demonstrated to figure out how any end-user will need more than 2^8 subnets. That's still assuming that device-makers won't decide they need to be able to operate with subnets of arbitrary size, rather than fixed-size /64 subnets. > There was a concious decision made a decade and a half ago to got to > 128 bits instead of 64 bits and give each subnet 64 bits so we would > never have to worry about the size of a subnet again. ?IPv6 is about > managing networks not managing addresses. Thanks for the explanation of how to subnet IPv4 networks and use RFC1918. I hope most readers are already familiar with these concepts. You should note that IPv6 was not, in fact, originally envisioned with /64 subnets; that figure was to be /80 or /96. In the mid-1990s, it was believed that dramatically increasing the number of bits available for ISP routing flexibility was very beneficial, as well as making access subnets so big that they should never need to grow. Then SLAAC came along. Except SLAAC doesn't do necessary things that DHCPv6 does, and the cost of implementing things like DHCPv6 in very small, inexpensive devices has gone down dramatically. I am amazed that so few imagine we might, in within the lifetime of IPv6, like to have more bits of address space for routing structure within ISP networks; but these people do think that end-users need 1.2e+24 addresses for the devices they'll have in their home. I don't have to use my imagination to think of ways that additional bits on the network address side would have been advantageous -- all I need is my memory. In the 90s, it was suggested that a growing number of dual-homed networks cluttering the DFZ could be handled more efficiently by setting aside certain address space for customers who dual-homed to pairs of the largest ISPs. The customer routes would then not need to be carried by anyone except those two ISPs, who are earning money from the customer. This never happened for a variety of good reasons, but most of the technical reasons would have gone away with the adoption of IPv6, as it was envisioned in the mid-90s. There seems to be a lot of imagination being used for SOHO networks, and none on the ISP side. What a shame that is. Owen, I do agree with the point you made off-list, that if huge mistakes are made now and the IPv6 address space is consumed more rapidly than the community is comfortable with, there should be plenty of opportunity to fix that down the road. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Wed Aug 10 20:32:34 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 18:32:34 -0700 Subject: IPv6 end user addressing In-Reply-To: <20110811004052.3242E12B5DD4@drugs.dv.isc.org> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: > > Someday, I expect the pantry to have a barcode reader on it connected back > a computer setup for the kitchen someday. Most of us already use barcode > readers when we shop so its not a big step to home use. > Nah... That's short-term thinking. The future holds advanced pantries with RFID sensors that know what is in the pantry and when they were manufactured, what their expiration date is, etc. The refrigerator will have not only the necessary RFID sensors, but, multiple pressure transducers capable of recognizing not only that there is a carton of milk in the refrigerator, but, how much milk is remaining. You'll be able to scan a QR code in the grocery store that links to a recipe for something you thought would be good for dinner, pass the ingredient list to the web server in the refrigerator and get back a nearly instant reply containing the relevant inventory list and a list of items you need to buy to complete the recipe. > Just about anything with fireware in it will eventually connect to the net. > I think you meant firmware, and, I'd say that a lot of things (cans, jars, milk cartons, etc.) that don't currently connect to the net will actually form IP adjacencies in the future. > The typical household already has 1 or 2 subnets. > Or even more in some cases (LAN, WLAN, WLAN Guest, DMZ for example). >> I would like to have innovations in SOHO devices, too; who knows what >> these may be. But I fear we may repeat the mistake that caused NAT to >> be a necessity in IPv4 -- exhausting address space -- by foolishly >> assuming that every household is going to need twenty-four orders of >> magnitude more public addresses than it has today. >> >> That is what these practices do -- they literally give end-users >> twenty-four orders of magnitude more addresses, while it is easy to >> imagine that we will come within one order of magnitude of running >> completely out of IPv6 addresses for issuing to service providers. > > Housholds can get as much internal addressing as they need today and as > many nets as they need today with RFC1918. 10/8 broken up into > to /24 is equivalent to a /48 broken up into /64s. > > A /56 is equivalent to 192.168/16 broken up into its class C's. > Good point. >> I didn't know what the digit "1" followed by twenty-four zeroes was >> called. I had to look it up. So our end-users will be receiving >> about one-Septillion addresses to use in their home, but no one seems >> to be asking what future technology we may be harming by possibly >> constraining the global address pool. > > There was a concious decision made a decade and a half ago to got to > 128 bits instead of 64 bits and give each subnet 64 bits so we would > never have to worry about the size of a subnet again. IPv6 is about > managing networks not managing addresses. > Yep. Owen From kamtha at ak-labs.net Wed Aug 10 20:43:37 2011 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Wed, 10 Aug 2011 21:43:37 -0400 Subject: network issue help In-Reply-To: References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> Message-ID: <20110811014337.GD20589@ak-labs.net> On Wed, Aug 10, 2011 at 09:22:11PM -0400, Christopher Morrow wrote: > On Wed, Aug 10, 2011 at 8:39 PM, Matthew Palmer wrote: > > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: > >> Is there an acronym for RTFM when there are a volume of manuals that need to be read? > > > > FOAD, perhaps? > > folks do get that deric's primary language isn't English right? so > asking him to explain is probably 'ok'. > (yes, he could have put more details into his mail, yes it would have > been more helpful and quicker to an answer for him...) > indeed.. From bill at herrin.us Wed Aug 10 20:43:20 2011 From: bill at herrin.us (William Herrin) Date: Wed, 10 Aug 2011 21:43:20 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler wrote: > On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: >> That said, /48 to the home should be what is happening, and /56 is >> a better compromise than anything smaller. > > You don't really imagine that end-users will require > more than 2^8 subnets, but that they will want several levels of very > simple, nibble-aligned routers within their network? Hi Jeff, In Owen's world, the refrigerator, toaster and microwave each request a /64 from the GE Home Appliance Controller, those /64's being necessary to address each appliance's internal button, light and sensor networks. To accommodate all of these appliances, the HAC has acquired a /59 for all the home appliances from the Home Automation System (HAS) which also has its own LAN and supplied a big block to the furnace and a smaller block to the security system. So, the HAS needed a /58 which it got from the Linksys Home Router. The Sony Home Entertainment Network (HEN) Controller also needed a /58 from the Home Router to accommodate the Playstation 5's need for a /62 (one /64 for its internal network, another for the PSN VPN and a third for the peripherals network). The Ultra-NES 512 only needed one /64, but the amplifier insisted on a /60 so it could delegate /64's to the cassette tape deck, cd player, mp3 player, etc. The Ford Home Automotive Network (HAN) also grabbed a block from which to delegate /62's to the three parked cars. Because you know: you need separate networks in each car for the life safety systems, the non-safety systems and the entertainment systems. I mean really, why wouldn't the life safety system in a car dynamically acquire its globally-addressable IPv6 addresses from the customer's cheap home Internet equipment? So they'll each need their /64's which means the car as a whole needs a /62. But the HAN only needed a /60 for for all of it since there were only 3 cars. Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the Home Router, but it needed an additional /64 for its virtual machine network hosting the Windows XP VM needed to run older software. And the wireless LAN only ended up consuming a single /64. But after the two /58's, that meant the Home Router needed a full /56 from the Internet Router. Finally, the Internet Router connects two networks... the customer's web server DMZ (/64) and the home router (/56). So after you figure in the HAC, the HAN, the HAS, the HEN and all the other connections you need at least a /55... which doesn't fit in a /56 but does fit in a /48. Qed. * Now, in Bill's world, the appliances don't expose their internals. When they employ any form of IP networking inside, which they generally don't, they use fe80 link-local addresses inside or maybe a ULA prefix. So even you have a Smart Fridge within the time span that you care about for today's home user IPv6 assignments, it occupies a single public address on your home's flat /64. Ditto the game consoles and tape decks. With maybe two other /64's: one for servers and one for the wireless LAN. And that /62 need easily fits in your /56 assignment. Regards, Bill Herrin * I say this with trepidation. A quarter century ago I used a similar reductio ad absurdum with a friend who suggested making every road a toll road. "Back out of the driveway. Pay the toll. Turn on to main. Pay the toll. Left on 15th. Pay the toll." Wouldn't you know, E-Z Pass came along and brought it to the edge of possible. Then again, possible doesn't necessarily mean advisable. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Aug 10 20:46:08 2011 From: bill at herrin.us (William Herrin) Date: Wed, 10 Aug 2011 21:46:08 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong wrote: >> Someday, I expect the pantry to have a barcode reader on it connected back >> a computer setup for the kitchen someday. ?Most of us already use barcode >> readers when we shop so its not a big step to home use. > > Nah... That's short-term thinking. The future holds advanced pantries with > RFID sensors that know what is in the pantry and when they were manufactured, > what their expiration date is, etc. And since your can of creamed corn is globally addressable, the rest of the world knows what's in your pantry too. ;) Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From brian.e.carpenter at gmail.com Wed Aug 10 20:52:10 2011 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 11 Aug 2011 13:52:10 +1200 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: <4E4335CA.807@gmail.com> On 2011-08-11 12:45, james machado wrote: > what is the life expectancy of IPv6? It won't live forever and we > can't reasonably expect it too. I understand we don't want run out of > addresses in the next 10-40 years but what about 100? 200? 300? > > We will run out and our decedents will go through re-numbering again. > The question becomes what is the life expectancy of IPv6 and does the > allocation plan make a reasonable attempt to run out of addresses > around the end of the expected life of IPv6. Well, we know that the human population will stabilise somewhere below ten billion by around 2050. The current unicast space provides for about 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current level of engineering common sense - i.e. the address space will begin to be really full when there are about 25% of those /48s being routed... that makes 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman and child. (Or about 25 million /64s if you prefer.) At that point, IANA would have to release unicast space other than 2000::/3 and we could start again with a new allocation policy. I am *really* not worried about this. Other stuff, such as BGP4, will break irrevocably long before this. Brian From owen at delong.com Wed Aug 10 20:51:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 18:51:37 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: <72D2A274-353F-4E6F-A46C-E20ED0CB529D@delong.com> > > I don't have to use my imagination to think of ways that additional > bits on the network address side would have been advantageous -- all I > need is my memory. In the 90s, it was suggested that a growing number > of dual-homed networks cluttering the DFZ could be handled more > efficiently by setting aside certain address space for customers who > dual-homed to pairs of the largest ISPs. The customer routes would > then not need to be carried by anyone except those two ISPs, who are > earning money from the customer. This never happened for a variety of > good reasons, but most of the technical reasons would have gone away > with the adoption of IPv6, as it was envisioned in the mid-90s. > I think that can still be very realistically achieved within the existing available address space. > There seems to be a lot of imagination being used for SOHO networks, > and none on the ISP side. What a shame that is. > I disagree. > Owen, I do agree with the point you made off-list, that if huge > mistakes are made now and the IPv6 address space is consumed more > rapidly than the community is comfortable with, there should be plenty > of opportunity to fix that down the road. > Precisely, so, let's risk a small chance of a mistake here now so that we don't cut off innovation so early. Owen From owen at delong.com Wed Aug 10 20:58:25 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 18:58:25 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: On Aug 10, 2011, at 6:46 PM, William Herrin wrote: > On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong wrote: >>> Someday, I expect the pantry to have a barcode reader on it connected back >>> a computer setup for the kitchen someday. Most of us already use barcode >>> readers when we shop so its not a big step to home use. >> >> Nah... That's short-term thinking. The future holds advanced pantries with >> RFID sensors that know what is in the pantry and when they were manufactured, >> what their expiration date is, etc. > > And since your can of creamed corn is globally addressable, the rest > of the world knows what's in your pantry too. ;) > This definitely helps explain your misconceptions about NAT as a security tool. Globally addressable != globally reachable. Things can have global addresses without having global reachability. There are these tools called access control lists and routing policies. Perhaps you've heard of them. They can be quite useful. Owen From owen at delong.com Wed Aug 10 20:56:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 18:56:46 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: <874088AE-2592-4E85-B6B0-96105755EAA1@delong.com> On Aug 10, 2011, at 6:43 PM, William Herrin wrote: > On Wed, Aug 10, 2011 at 2:17 PM, Jeff Wheeler wrote: >> On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: >>> That said, /48 to the home should be what is happening, and /56 is >>> a better compromise than anything smaller. >> >> You don't really imagine that end-users will require >> more than 2^8 subnets, but that they will want several levels of very >> simple, nibble-aligned routers within their network? > > Hi Jeff, > > In Owen's world, the refrigerator, toaster and microwave each request > a /64 from the GE Home Appliance Controller, those /64's being > necessary to address each appliance's internal button, light and > sensor networks. To accommodate all of these appliances, the HAC has > acquired a /59 for all the home appliances from the Home Automation > System (HAS) which also has its own LAN and supplied a big block to > the furnace and a smaller block to the security system. So, the HAS > needed a /58 which it got from the Linksys Home Router. > > The Sony Home Entertainment Network (HEN) Controller also needed a /58 > from the Home Router to accommodate the Playstation 5's need for a /62 > (one /64 for its internal network, another for the PSN VPN and a third > for the peripherals network). The Ultra-NES 512 only needed one /64, > but the amplifier insisted on a /60 so it could delegate /64's to the > cassette tape deck, cd player, mp3 player, etc. > > The Ford Home Automotive Network (HAN) also grabbed a block from which > to delegate /62's to the three parked cars. Because you know: you need > separate networks in each car for the life safety systems, the > non-safety systems and the entertainment systems. I mean really, why > wouldn't the life safety system in a car dynamically acquire its > globally-addressable IPv6 addresses from the customer's cheap home > Internet equipment? So they'll each need their /64's which means the > car as a whole needs a /62. But the HAN only needed a /60 for for all > of it since there were only 3 cars. > > Now, the Windows 9 PC sat on the /64 PC LAN directly connected to the > Home Router, but it needed an additional /64 for its virtual machine > network hosting the Windows XP VM needed to run older software. And > the wireless LAN only ended up consuming a single /64. But after the > two /58's, that meant the Home Router needed a full /56 from the > Internet Router. > > Finally, the Internet Router connects two networks... the customer's > web server DMZ (/64) and the home router (/56). So after you figure in > the HAC, the HAN, the HAS, the HEN and all the other connections you > need at least a /55... which doesn't fit in a /56 but does fit in a > /48. Qed. * > > Thanks... An excellent write up, even if it was intended tongue in cheek. However, you left out the need for addressing for the RFID tags that will end up on most groceries, etc. > > Now, in Bill's world, the appliances don't expose their internals. > When they employ any form of IP networking inside, which they > generally don't, they use fe80 link-local addresses inside or maybe a > ULA prefix. So even you have a Smart Fridge within the time span that > you care about for today's home user IPv6 assignments, it occupies a > single public address on your home's flat /64. Ditto the game consoles > and tape decks. With maybe two other /64's: one for servers and one > for the wireless LAN. And that /62 need easily fits in your /56 > assignment. > I'm glad I live in Owen's world and not Bill's. I think my appliance vendors will make much cooler and more useful products than yours. Owen From morrowc.lists at gmail.com Wed Aug 10 21:05:54 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Aug 2011 22:05:54 -0400 Subject: network issue help In-Reply-To: <20110811014337.GD20589@ak-labs.net> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> <20110811014337.GD20589@ak-labs.net> Message-ID: On Wed, Aug 10, 2011 at 9:43 PM, Carlos Kamtha wrote: > On Wed, Aug 10, 2011 at 09:22:11PM -0400, Christopher Morrow wrote: >> On Wed, Aug 10, 2011 at 8:39 PM, Matthew Palmer wrote: >> > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: >> >> Is there an acronym for RTFM when there are a volume of manuals that need to be read? >> > >> > FOAD, perhaps? >> >> folks do get that deric's primary language isn't English right? so >> asking him to explain is probably 'ok'. >> (yes, he could have put more details into his mail, yes it would have >> been more helpful and quicker to an answer for him...) >> > > indeed.. of course I forgot to do what I asked :( Deric, could you restate your question? From Valdis.Kletnieks at vt.edu Wed Aug 10 21:15:07 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 Aug 2011 22:15:07 -0400 Subject: network issue help In-Reply-To: Your message of "Wed, 10 Aug 2011 19:33:53 EDT." <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> Message-ID: <4859.1313028907@turing-police.cc.vt.edu> On Wed, 10 Aug 2011 19:33:53 EDT, Stefan Fouant said: > Is there an acronym for RTFM when there are a volume of manuals that need to > be read? Sure there is. LMGTFY :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Aug 10 21:17:50 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 Aug 2011 22:17:50 -0400 Subject: network issue help In-Reply-To: Your message of "Wed, 10 Aug 2011 21:22:11 EDT." References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> Message-ID: <4958.1313029070@turing-police.cc.vt.edu> On Wed, 10 Aug 2011 21:22:11 EDT, Christopher Morrow said: > folks do get that deric's primary language isn't English right? so > asking him to explain is probably 'ok'. > (yes, he could have put more details into his mail, yes it would have > been more helpful and quicker to an answer for him...) Whatever else you might think of Eric S Raymond, the URL I cited is still the best summary I've seen, and probably the most help we can give Deric in under 64 bytes. Because let's face it, no matter *what* Deric's native language is, he's not going to get anything useful from NANOG or any other mailing list till he either reads Eric's FAQ, or otherwise learns the info in there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tagno25 at gmail.com Wed Aug 10 21:34:33 2011 From: tagno25 at gmail.com (Philip Dorr) Date: Wed, 10 Aug 2011 21:34:33 -0500 Subject: IPv6 end user addressing In-Reply-To: <874088AE-2592-4E85-B6B0-96105755EAA1@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <874088AE-2592-4E85-B6B0-96105755EAA1@delong.com> Message-ID: On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong wrote: > > I'm glad I live in Owen's world and not Bill's. I think my appliance vendors > will make much cooler and more useful products than yours. In Owen's world the fridge and pantry would know what they have, the amounts, and possibly location. The recipe book would be able to check what is in the fridge and pantry and tell if you need to buy more. It could then set the oven to the correct temperature when you reach the correct step in the recipe. Yes, all that could be done with servers on the pantry and fridge, but then there would be different implementations of each protocol and incompatibilities between the fridge, pantry, recipe book, and oven. From newton at internode.com.au Wed Aug 10 21:45:34 2011 From: newton at internode.com.au (Mark Newton) Date: Thu, 11 Aug 2011 02:45:34 +0000 Subject: IPv6 end user addressing In-Reply-To: <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: On 11/08/2011, at 8:42 AM, Owen DeLong wrote: > > I suppose that limiting enough households to too small an allocation > will have that effect. I would rather we steer the internet deployment > towards liberal enough allocations to avoid such disability for the > future. I see the lack of agreement on whether /48 or /56 or /60 is good for a home network to be a positive thing. As long as there's no firm consensus, router vendors will have to implement features which don't make silly hard-coded assumptions. Innovation will still happen, features will still be implemented, we'll still climb out of the NAT morass. But we'll do it with CPE that allows for a richer spectrum of variation than we would if we just said, "Dammit, /48 for everyone." It's all good. At this stage of the game, any amount of "moving forward" is better than staying where we are. (which reminds me: http://www.internode.on.net/news/2011/08/238.php It ain't that hard) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Wed Aug 10 21:54:06 2011 From: newton at internode.com.au (Mark Newton) Date: Thu, 11 Aug 2011 02:54:06 +0000 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <874088AE-2592-4E85-B6B0-96105755EAA1@delong.com> Message-ID: <97862066-EE89-4AF0-9469-D37858F7AB68@internode.com.au> On 11/08/2011, at 12:04 PM, Philip Dorr wrote: > On Wed, Aug 10, 2011 at 8:56 PM, Owen DeLong wrote: >> >> I'm glad I live in Owen's world and not Bill's. I think my appliance vendors >> will make much cooler and more useful products than yours. > > In Owen's world the fridge and pantry would know what they have, the > amounts, and possibly location. The recipe book would be able to check > what is in the fridge and pantry and tell if you need to buy more. It > could then set the oven to the correct temperature when you reach the > correct step in the recipe. The wine cellar will know how much you drank last night, and communicate with the life-critical systems in the car to prevent engine start while you're over the limit. When the home BMS network notices that the flow sensor on the shower hasn't started at the usual time the next morning, it'll play an IVR out of your home PBX network to tell the boss you're too hungover to come to work. Owen's world has built in automated protection to help you through the fact that IPv6 subnetting will turn you to drink :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From cb.list6 at gmail.com Wed Aug 10 22:00:05 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 10 Aug 2011 20:00:05 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: On Aug 10, 2011 7:45 PM, "Mark Newton" wrote: > > > On 11/08/2011, at 8:42 AM, Owen DeLong wrote: > > > > I suppose that limiting enough households to too small an allocation > > will have that effect. I would rather we steer the internet deployment > > towards liberal enough allocations to avoid such disability for the > > future. > > > I see the lack of agreement on whether /48 or /56 or /60 is good for a > home network to be a positive thing. > > As long as there's no firm consensus, router vendors will have to implement > features which don't make silly hard-coded assumptions. > > Innovation will still happen, features will still be implemented, we'll > still climb out of the NAT morass. But we'll do it with CPE that allows for > a richer spectrum of variation than we would if we just said, "Dammit, /48 for > everyone." > > It's all good. At this stage of the game, any amount of "moving forward" is > better than staying where we are. > > (which reminds me: http://www.internode.on.net/news/2011/08/238.php It ain't > that hard) > Finally a useful post in this thread. Good work on the deployment of real ipv6! Cb > - mark > > -- > Mark Newton Email: newton at internode.com.au(W) > Network Engineer Email: newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > > From newton at internode.com.au Wed Aug 10 22:11:45 2011 From: newton at internode.com.au (Mark Newton) Date: Thu, 11 Aug 2011 03:11:45 +0000 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: <15678434-006F-419C-B5CE-C82ED877ECE4@internode.com.au> On 11/08/2011, at 12:30 PM, Cameron Byrne wrote: > Finally a useful post in this thread. Good work on the deployment of real ipv6! > Thanks. And thanks to Vendor-C for helping us through it. The IPv6 Broadband featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement on its predecessors. Biggest hassle with IPv6 in production right now: DNS support is woefully undercooked. I don't think anyone has put anywhere near as much effort into making it fluid, user-friendly, and automated. Simple questions like, "How are reverse mappings supposed to work when you can't predict an end-user's address?" have no good answer. If any systems folks want a nice meaty problem domain to focus their efforts on, DNS would be da shiznit. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Wed Aug 10 22:12:32 2011 From: newton at internode.com.au (Mark Newton) Date: Thu, 11 Aug 2011 03:12:32 +0000 Subject: IPv6 end user addressing In-Reply-To: <15678434-006F-419C-B5CE-C82ED877ECE4@internode.com.au> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <15678434-006F-419C-B5CE-C82ED877ECE4@internode.com.au> Message-ID: <23303D67-B36E-4C3E-A356-39B72078E113@internode.com.au> On 11/08/2011, at 12:41 PM, Mark Newton wrote: > > On 11/08/2011, at 12:30 PM, Cameron Byrne wrote: >> Finally a useful post in this thread. Good work on the deployment of real ipv6! >> > > Thanks. And thanks to Vendor-C for helping us through it. The IPv6 Broadband > featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement > on its predecessors. Oops. s/XR/XE/ - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From michael.hare at doit.wisc.edu Wed Aug 10 22:16:07 2011 From: michael.hare at doit.wisc.edu (Michael Hare) Date: Wed, 10 Aug 2011 22:16:07 -0500 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: <4E434977.1020800@doit.wisc.edu> On 8/10/2011 8:46 PM, William Herrin wrote: > On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong wrote: >>> Someday, I expect the pantry to have a barcode reader on it connected back >>> a computer setup for the kitchen someday. Most of us already use barcode >>> readers when we shop so its not a big step to home use. >> >> Nah... That's short-term thinking. The future holds advanced pantries with >> RFID sensors that know what is in the pantry and when they were manufactured, >> what their expiration date is, etc. > > And since your can of creamed corn is globally addressable, the rest > of the world knows what's in your pantry too. ;) I can't believe no one has made a joke yet about a kernel. Sorry for the bad joke, -Michael > > Regards, > Bill Herrin > > From andrew at parnell.ca Wed Aug 10 23:01:15 2011 From: andrew at parnell.ca (Andrew Parnell) Date: Thu, 11 Aug 2011 00:01:15 -0400 Subject: v4/v6 dns thoughts? In-Reply-To: References: <4E4180C9.4060607@q7.com> Message-ID: On Tue, Aug 9, 2011 at 7:36 PM, Owen DeLong wrote: > > I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's > really no advantage to do it. Most tools either have separate IPv4/IPv6 variants > or have command-line switches for address-family control if you care. For most tools that I ordinarily use, I would certainly agree with this. The only exception might be from a web browser; while there are ways that they can be reconfigured to only use certain IP versions in certain cases, it is probably more straightforward to use www.ipvN.domain.tld or a similar name. For reverse DNS, I completely agree that there is no reason to use a different name. From owen at delong.com Wed Aug 10 23:03:56 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Aug 2011 21:03:56 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> Message-ID: <76C3FDEC-17A6-4E95-A5A4-C4DA5EA7DC5F@delong.com> On Aug 10, 2011, at 7:45 PM, Mark Newton wrote: > > On 11/08/2011, at 8:42 AM, Owen DeLong wrote: >> >> I suppose that limiting enough households to too small an allocation >> will have that effect. I would rather we steer the internet deployment >> towards liberal enough allocations to avoid such disability for the >> future. > > > I see the lack of agreement on whether /48 or /56 or /60 is good for a > home network to be a positive thing. > > As long as there's no firm consensus, router vendors will have to implement > features which don't make silly hard-coded assumptions. > Yes and no. In terms of potential innovations, if enough of the market chooses /60, they will hard code the assumption that they cannot count on more than a /60 being available into their development process regardless of what gets into the router. Sure, they won't be able to assume you can't get a /48, but, they also won't necessarily implement features that would take advantage of a /48. > Innovation will still happen, features will still be implemented, we'll > still climb out of the NAT morass. But we'll do it with CPE that allows for > a richer spectrum of variation than we would if we just said, "Dammit, /48 for > everyone." > We'll climb out of the NAT morass, yes. That's not innovation, that's recovery. Innovation of products that are capable of building significant automatic partitioning and hierarchy will not happen if ISPs choose not to supply enough addresses to facilitate use by a critical mass of customers. No router vendor is going to spend development resources building features that their customers will want but be unable to use because their ISP says no. > It's all good. At this stage of the game, any amount of "moving forward" is > better than staying where we are. > True, but, there are degrees of better. Moving forward on a slightly wrong path is better than moving forward on a radically wrong path. Both are better than standing still or moving backward. If you try to get to a point that is 010? from your current position and 60 miles in front of you, it's better to travel 015? than 350?. Both are way better than 060? and 060? is way better than 090? which is still better than 180?. However, 015? will be slightly off until you basically pass your destination. However, 350? will have you fairly far off by the time you pass your destination. Obviously, 060? will never bring you very close to the destination, even if you will start out getting slightly closer to it. Even 090? will bring you closer to your destination for a little while before you start getting farther away again. It ends up looking like this: -------------- next part -------------- A non-text attachment was scrubbed... Name: Closest Point.png Type: image/png Size: 52755 bytes Desc: not available URL: -------------- next part -------------- The thin lines are construction lines to show the computation of the closest point (the point where a line perpendicular to the course chosen intersects the destination waypoint). The black dots represent the actual closest points. Obviously, the closest point is closer the less off-course you are. However, more interestingly, the more off course you are, the sooner you reach a point where you are no longer heading towards, but, away from your destination. Obviously for lines 90? to 270? off of the desired course, you begin heading away immediately. (note that the 90? line above is only 80? off course). Perhaps far more than most of you wanted to know about navigation, but, at least worth considering when we think that all forward movement is good forward movement. Owen From jra at baylink.com Wed Aug 10 23:14:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Aug 2011 00:14:52 -0400 (EDT) Subject: network issue help In-Reply-To: Message-ID: <23726041.862.1313036092515.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Wed, Aug 10, 2011 at 8:39 PM, Matthew Palmer > wrote: > > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: > >> Is there an acronym for RTFM when there are a volume of manuals > >> that need to be read? > > > > FOAD, perhaps? > > folks do get that deric's primary language isn't English right? so > asking him to explain is probably 'ok'. > (yes, he could have put more details into his mail, yes it would have > been more helpful and quicker to an answer for him...) Well, shouldn't he be asking on the SWEINTPLNOG[1] mailing list then? Cheers, -- jra [1]Someplace Where English Is Not The Primary Langauge Network Operators' Group -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Wed Aug 10 23:16:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 11 Aug 2011 00:16:58 -0400 (EDT) Subject: network issue help In-Reply-To: <4958.1313029070@turing-police.cc.vt.edu> Message-ID: <28631327.866.1313036218533.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Wed, 10 Aug 2011 21:22:11 EDT, Christopher Morrow said: > > folks do get that deric's primary language isn't English right? so > > asking him to explain is probably 'ok'. > > (yes, he could have put more details into his mail, yes it would > > have > > been more helpful and quicker to an answer for him...) > > Whatever else you might think of Eric S Raymond, the URL I cited is still > the best summary I've seen, and probably the most help we can give Deric > in under 64 bytes. Because let's face it, no matter *what* Deric's native > language is, he's not going to get anything useful from NANOG or any other > mailing list till he either reads Eric's FAQ, or otherwise learns the > info in there. Credit where due: "Smart Questions" was co-authored by Rick Moen, who apparently *couldn't* escape. (Pat yourself on the back if you got the reference, esoteric as it was.) And yes, that and Tatham are my two go-to references for people. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From newton at internode.com.au Wed Aug 10 23:20:08 2011 From: newton at internode.com.au (Mark Newton) Date: Thu, 11 Aug 2011 04:20:08 +0000 Subject: IPv6 end user addressing In-Reply-To: <76C3FDEC-17A6-4E95-A5A4-C4DA5EA7DC5F@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <76C3FDEC-17A6-4E95-A5A4-C4DA5EA7DC5F@delong.com> Message-ID: <0C948CDD-5AA3-4FDD-92BB-C725CA9B11FE@internode.com.au> On 11/08/2011, at 1:33 PM, Owen DeLong wrote: > Yes and no. In terms of potential innovations, if enough of the market chooses > /60, they will hard code the assumption that they cannot count on more than > a /60 being available into their development process regardless of what > gets into the router. Sure, they won't be able to assume you can't get a /48, > but, they also won't necessarily implement features that would take advantage > of a /48. They will on their "premium" high price point CPE and/or service provider offerings. It'll be a product differentiator. If enough customers are attracted to it, it'll win. If they aren't, it'll lose. The process of invention and innovation will happen anyway. We're not really talking about that here, we're talking about post-innovation marketing. Maybe ISP#2 in Australia will launch onto the market with /48's for everyone, and we'll respond competitively. Dunno. Whatever, it's all kinda arbitrary really. Not worth arguing about, and certainly not worth delaying implementation until you finish debating the "right" answer. > Perhaps far more than most of you wanted to know about navigation, but, at least worth > considering when we think that all forward movement is good forward movement. The 1-in-60 rule I learned during my pilots license training is a lot easier to explain, without diagrams and with no need for trigonometry. Another useful judgement call when you're flying is to understand that as long as you know where you are and where you want to be, any forward progress whatsoever is a positive when there's a growing thunderstorm behind you :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From joelja at bogus.com Wed Aug 10 22:29:35 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 10 Aug 2011 20:29:35 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E4335CA.807@gmail.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <4E4335CA.807@gmail.com> Message-ID: On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote: > On 2011-08-11 12:45, james machado wrote: > >> what is the life expectancy of IPv6? It won't live forever and we >> can't reasonably expect it too. I understand we don't want run out of >> addresses in the next 10-40 years but what about 100? 200? 300? >> >> We will run out and our decedents will go through re-numbering again. >> The question becomes what is the life expectancy of IPv6 and does the >> allocation plan make a reasonable attempt to run out of addresses >> around the end of the expected life of IPv6. > > Well, we know that the human population will stabilise somewhere below > ten billion by around 2050. The current unicast space provides for about > 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current > level of engineering common sense - i.e. the address space will begin to be > really full when there are about 25% of those /48s being routed... that makes > 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman > and child. (Or about 25 million /64s if you prefer.) It's not the humans that are going to soak up the address space, so it seems a little misguided to count up the humans a reference for the bounding properties on growth. That said I think 2000::/3 will last long enough, that we shouldn't be out rewriting policy anytime soon. > At that point, IANA would have to release unicast space other than 2000::/3 > and we could start again with a new allocation policy. > > I am *really* not worried about this. Other stuff, such as BGP4, will break > irrevocably long before this. We have a few problems to solve along the way. Running the current network is hard enough as it is. > Brian > From joelja at bogus.com Wed Aug 10 22:40:22 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 10 Aug 2011 20:40:22 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> Message-ID: <6E72887C-F1B7-4310-9EA8-F520970D4F59@bogus.com> On Aug 10, 2011, at 6:43 PM, William Herrin wrote: > I mean really, why > wouldn't the life safety system in a car dynamically acquire its > globally-addressable IPv6 addresses from the customer's cheap home > Internet equipment? So they'll each need their /64's which means the > car as a whole needs a /62. But the HAN only needed a /60 for for all > of it since there were only 3 cars. several cars on the road today have cellular radios on more than one network ( the nissan leaf for example) When you account for integration into the driver and passengers personal area networks (pans) as for example ford sync does today, and integration into home automation networks, (garage doors, lighting, media syncronization) and in the case of electric cars, the smart grid) why wouldn't a car, acquire addresses and be discoverable on the users home network? By the time this is fully realized, the car will be on quite a few networks, instead of just the two or three it's presently either supporting or attached to... From sfouant at shortestpathfirst.net Wed Aug 10 23:49:52 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 11 Aug 2011 00:49:52 -0400 Subject: network issue help In-Reply-To: References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> Message-ID: <59BB3894-FAE1-4C32-B2CA-19D2094F301E@shortestpathfirst.net> Sorry, couldnt help it... that was my Asperger's kicking in... Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 9:22 PM, Christopher Morrow wrote: >> > folks do get that deric's primary language isn't English right? so > asking him to explain is probably 'ok'. > (yes, he could have put more details into his mail, yes it would have > been more helpful and quicker to an answer for him...) > > -chris >> >> >> From mansaxel at besserwisser.org Thu Aug 11 00:44:56 2011 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 11 Aug 2011 07:44:56 +0200 Subject: v4/v6 dns thoughts? In-Reply-To: References: <4E4180C9.4060607@q7.com> Message-ID: <20110811054456.GN1182@besserwisser.org> Subject: Re: v4/v6 dns thoughts? Date: Thu, Aug 11, 2011 at 12:01:15AM -0400 Quoting Andrew Parnell (andrew at parnell.ca): > On Tue, Aug 9, 2011 at 7:36 PM, Owen DeLong wrote: > > > > I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's > > really no advantage to do it. Most tools either have separate IPv4/IPv6 variants > > or have command-line switches for address-family control if you care. > > For most tools that I ordinarily use, I would certainly agree with > this. The only exception might be from a web browser; while there are > ways that they can be reconfigured to only use certain IP versions in > certain cases, it is probably more straightforward to use > www.ipvN.domain.tld or a similar name. > > For reverse DNS, I completely agree that there is no reason to use a > different name. While I am no enemy to /56 allocations (cross-thread alert!) I for the most part tend to agree with Owen and would so here too. Possibly with the addition of separate names in a subdomain for trouble-shooting. Selecting protocol is something best done slightly lower in the stack. I did so with $INCLUDE directives[0] at a former employer. For routers, where it matters much more than for end-user stuff like web servers. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 DIDI ... is that a MARTIAN name, or, are we in ISRAEL? [0] Like so: $ORIGIN isp.tld. $INCLUDE "file-with-AAAA-records-without-FQDN" $INCLUDE "file-with-A-records-without-FQDN" $ORIGIN v4.isp.tld. $INCLUDE "file-with-A-records-without-FQDN" $ORIGIN v6.isp.tld. $INCLUDE "file-with-AAAA-records-without-FQDN" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From charles at knownelement.com Thu Aug 11 01:32:26 2011 From: charles at knownelement.com (Charles N Wyble) Date: Thu, 11 Aug 2011 01:32:26 -0500 Subject: 4g hack Message-ID: <4E43777A.9090907@knownelement.com> http://seclists.org/fulldisclosure/2011/Aug/76 Wondering what folks think about this? If this was true then we just entered a whole new era of mass WAN exploitation. Off list replies welcome. Rock and roll folks. From morrowc.lists at gmail.com Thu Aug 11 02:25:38 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Aug 2011 03:25:38 -0400 Subject: 4g hack In-Reply-To: <4E43777A.9090907@knownelement.com> References: <4E43777A.9090907@knownelement.com> Message-ID: On Thu, Aug 11, 2011 at 2:32 AM, Charles N Wyble wrote: > http://seclists.org/fulldisclosure/2011/Aug/76 > > Wondering what folks think about this? If this was true then we just > entered a whole new era of mass WAN exploitation. > This isn't really all that new is it? haven't people been able to buy 3g/pcs/etc antennae and such off ebay for a while and intercept conversations/data/etc for a long time? GSM was 'hacked' (decrypted via some rainbow tables) several years ago as well. If you ship it over the air and there isn't a reasonable encryption scheme in place, don't you expect it to be seen? From joakim at aronius.se Thu Aug 11 03:02:03 2011 From: joakim at aronius.se (Joakim Aronius) Date: Thu, 11 Aug 2011 10:02:03 +0200 Subject: 4g hack In-Reply-To: References: <4E43777A.9090907@knownelement.com> Message-ID: <20110811080203.GC25247@nike.aronius.se> * Christopher Morrow (morrowc.lists at gmail.com) wrote: > On Thu, Aug 11, 2011 at 2:32 AM, Charles N Wyble > wrote: > > http://seclists.org/fulldisclosure/2011/Aug/76 > > > > Wondering what folks think about this? If this was true then we just > > entered a whole new era of mass WAN exploitation. > > > > This isn't really all that new is it? haven't people been able to buy > 3g/pcs/etc antennae and such off ebay for a while and intercept > conversations/data/etc for a long time? GSM was 'hacked' (decrypted > via some rainbow tables) several years ago as well. > > If you ship it over the air and there isn't a reasonable encryption > scheme in place, don't you expect it to be seen? GSM and GPRS are vulnerable to MitM due to lack of two factor authentication etc. WCDMA (3G) and LTE (4G) should be safe as they have much better security. Not sure about 3GPP2 (CDMA) or WiMAX systems, perhaps early version of CDMA has similar problems as GSM. But saying that '4G' is vulnerable is a pretty broad statement as it consists of at least LTE and WiMAX, and some US operators also refer to their WCDMA HSPA as 4G. There is also a difference between 'the standard has security flaws' and 'the operator has deployed an insecure network' as operators might run their network with security features turned off. Anyway, the paranoid should turn of GSM and run WCDMA instead. /Joakim From eugen at leitl.org Thu Aug 11 04:53:48 2011 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 11 Aug 2011 11:53:48 +0200 Subject: IPv6 end user addressing In-Reply-To: <4E4335CA.807@gmail.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <4E4335CA.807@gmail.com> Message-ID: <20110811095348.GI16178@leitl.org> On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote: > Well, we know that the human population will stabilise somewhere below > ten billion by around 2050. The current unicast space provides for about How about the machine population? How about self-replicating systems? How about geography-based address allocation, to go away with global routing tables? How about InterPlaNet, such as LEO routers, solar power satellites, controlling industrial production on the Moon and elsewhere? I don't expect IPv6 will last much longer than IPv4. And that's probably a good thing. > 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current > level of engineering common sense - i.e. the address space will begin to be > really full when there are about 25% of those /48s being routed... that makes > 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman > and child. (Or about 25 million /64s if you prefer.) > > At that point, IANA would have to release unicast space other than 2000::/3 > and we could start again with a new allocation policy. > > I am *really* not worried about this. Other stuff, such as BGP4, will break > irrevocably long before this. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From a.harrowell at gmail.com Thu Aug 11 06:01:35 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 11 Aug 2011 12:01:35 +0100 Subject: Communications networks "will be closed down" Message-ID: <201108111201.49223.a.harrowell@gmail.com> http://blogs.ft.com/westminster/2011/08/uk-riots-david-cameron- announces-his-prescription/ I feel this is operational or at least potentially so. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From owen at delong.com Thu Aug 11 07:25:58 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 05:25:58 -0700 Subject: v4/v6 dns thoughts? In-Reply-To: References: <4E4180C9.4060607@q7.com> Message-ID: <167513B4-797A-4892-8128-CBBBF158B8FD@delong.com> On Aug 10, 2011, at 9:01 PM, Andrew Parnell wrote: > On Tue, Aug 9, 2011 at 7:36 PM, Owen DeLong wrote: >> >> I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's >> really no advantage to do it. Most tools either have separate IPv4/IPv6 variants >> or have command-line switches for address-family control if you care. > > For most tools that I ordinarily use, I would certainly agree with > this. The only exception might be from a web browser; while there are > ways that they can be reconfigured to only use certain IP versions in > certain cases, it is probably more straightforward to use > www.ipvN.domain.tld or a similar name. > In a web browser, I don't care unless I'm troubleshooting. If I'm troubleshooting, my web browser of choice is probably wget rather than one of the kitchen sink GUI based browsers. It turns out that wget supports the flag in question. Owen From owen at delong.com Thu Aug 11 07:25:55 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 05:25:55 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <4E4335CA.807@gmail.com> Message-ID: <0AB6B2DC-3A23-4668-960F-9CC26A8EA05B@delong.com> On Aug 10, 2011, at 8:29 PM, Joel Jaeggli wrote: > > On Aug 10, 2011, at 6:52 PM, Brian E Carpenter wrote: > >> On 2011-08-11 12:45, james machado wrote: >> >>> what is the life expectancy of IPv6? It won't live forever and we >>> can't reasonably expect it too. I understand we don't want run out of >>> addresses in the next 10-40 years but what about 100? 200? 300? >>> >>> We will run out and our decedents will go through re-numbering again. >>> The question becomes what is the life expectancy of IPv6 and does the >>> allocation plan make a reasonable attempt to run out of addresses >>> around the end of the expected life of IPv6. >> >> Well, we know that the human population will stabilise somewhere below >> ten billion by around 2050. The current unicast space provides for about >> 15 trillion /48s. Let's assume that the RIRs and ISPs retain their current >> level of engineering common sense - i.e. the address space will begin to be >> really full when there are about 25% of those /48s being routed... that makes >> 3.75 trillion /48s routed for ten billion people, or 375 /48s per man, woman >> and child. (Or about 25 million /64s if you prefer.) > > It's not the humans that are going to soak up the address space, so it seems a little misguided to count up the humans a reference for the bounding properties on growth. That said I think 2000::/3 will last long enough, that we shouldn't be out rewriting policy anytime soon. > I disagree. I think current policy in several RIRs (APNIC, especially) is far too conservative and that we do need to rewrite it. That's why I submitted prop-090 which has taken the feedback I received into account and become prop-098. Owen From jamie at photon.com Thu Aug 11 07:41:04 2011 From: jamie at photon.com (Jamie Bowden) Date: Thu, 11 Aug 2011 08:41:04 -0400 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> Message-ID: <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> Owen wrote: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, August 10, 2011 9:58 PM > To: William Herrin > Cc: nanog at nanog.org > Subject: Re: IPv6 end user addressing > > > On Aug 10, 2011, at 6:46 PM, William Herrin wrote: > > > On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong wrote: > >>> Someday, I expect the pantry to have a barcode reader on it > connected back > >>> a computer setup for the kitchen someday. Most of us already use > barcode > >>> readers when we shop so its not a big step to home use. > >> > >> Nah... That's short-term thinking. The future holds advanced > pantries with > >> RFID sensors that know what is in the pantry and when they were > manufactured, > >> what their expiration date is, etc. > > > > And since your can of creamed corn is globally addressable, the rest > > of the world knows what's in your pantry too. ;) > > > > This definitely helps explain your misconceptions about NAT as a > security tool. > > > Globally addressable != globally reachable. > > Things can have global addresses without having global reachability. > There are > these tools called access control lists and routing policies. Perhaps > you've heard > of them. They can be quite useful. And your average home user, whose WiFi network is an open network named "linksys" is going to do that how? Jamie From cjinfantino at gmail.com Thu Aug 11 07:57:24 2011 From: cjinfantino at gmail.com (CJ) Date: Thu, 11 Aug 2011 08:57:24 -0400 Subject: OSPF vs IS-IS Message-ID: Hey all, Is there any reason to run IS-IS over OSPF in the SP core? Currently, we are running IS-IS but we are redesigning our core and now would be a good time to switch. I would like to switch to OSPF, mostly because of familiarity with OSPF over IS-IS. What does everyone think? -- CJ http://convergingontheedge.com From sfouant at shortestpathfirst.net Thu Aug 11 08:06:18 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 11 Aug 2011 09:06:18 -0400 Subject: OSPF vs IS-IS In-Reply-To: References: Message-ID: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3. The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 11, 2011, at 8:57 AM, CJ wrote: > Hey all, > Is there any reason to run IS-IS over OSPF in the SP core? Currently, we > are running IS-IS but we are redesigning our core and now would be a good > time to switch. I would like to switch to OSPF, mostly because of > familiarity with OSPF over IS-IS. > What does everyone think? > > -- > CJ > > http://convergingontheedge.com From mikea at mikea.ath.cx Thu Aug 11 08:12:48 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 11 Aug 2011 08:12:48 -0500 Subject: network issue help In-Reply-To: <20110811003959.GS17327@hezmatt.org> References: <8AEC36A4-45BB-49F6-8C86-02404F31D1C1@shortestpathfirst.net> <20110811003959.GS17327@hezmatt.org> Message-ID: <20110811131248.GA53603@mikea.ath.cx> On Thu, Aug 11, 2011 at 10:39:59AM +1000, Matthew Palmer wrote: > On Wed, Aug 10, 2011 at 07:33:53PM -0400, Stefan Fouant wrote: > > Is there an acronym for RTFM when there are a volume of manuals that need to be read? > > FOAD, perhaps? Well, there's ADD: Attention Deficit Disorder. Then there's ADHD: Attendion Deficit Hyperactivity Disorder. And there's ADCD: Absent During Clue Distribution. I think #3 may fit best. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From wcooper02 at gmail.com Thu Aug 11 08:29:02 2011 From: wcooper02 at gmail.com (William Cooper) Date: Thu, 11 Aug 2011 09:29:02 -0400 Subject: OSPF vs IS-IS In-Reply-To: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> References: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> Message-ID: I'm totally in concurrence with Stephan's point. Couple of things to consider: a) deciding to migrate to either ISIS or OSPFv3 from another protocol is still migrating to a new protocol and b) even in the case of migrating to OSPFv3, there are fairly significant changes in behavior from OSPFv2 to be aware of (most notably authentication, but that's fodder for another conversation). -Tony On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant wrote: > Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3. > > The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks. > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 11, 2011, at 8:57 AM, CJ wrote: > >> Hey all, >> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we >> are running IS-IS but we are redesigning our core and now would be a good >> time to switch. I would like to switch to OSPF, mostly because of >> familiarity with OSPF over IS-IS. >> What does everyone think? >> >> -- >> CJ >> >> http://convergingontheedge.com > > From deleskie at gmail.com Thu Aug 11 08:34:49 2011 From: deleskie at gmail.com (jim deleskie) Date: Thu, 11 Aug 2011 10:34:49 -0300 Subject: OSPF vs IS-IS In-Reply-To: References: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> Message-ID: Having run both on some good sized networks, I can tell you to run what your ops folks know best. We can debate all day the technical merits of one v another, but end of day, it always comes down to your most jr ops eng having to make a change at 2 am, you need to design for this case, if your using OSPF today and they know OSPF I'd say stick with it to reduce the chance of things blowing up at 2am when someone tries to 'fix' something else. -jim On Thu, Aug 11, 2011 at 10:29 AM, William Cooper wrote: > I'm totally in concurrence with Stephan's point. > > Couple of things to consider: a) deciding to migrate to either ISIS or > OSPFv3 from another protocol is still migrating to a new protocol > and b) even in the case of migrating to OSPFv3, there are fairly > significant changes in behavior from OSPFv2 to be aware of (most > notably > authentication, but that's fodder for another conversation). > > -Tony > > On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant > wrote: >> Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3. >> >> The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks. >> >> Stefan Fouant >> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI >> Technical Trainer, Juniper Networks >> http://www.shortestpathfirst.net >> http://www.twitter.com/sfouant >> >> Sent from my iPad >> >> On Aug 11, 2011, at 8:57 AM, CJ wrote: >> >>> Hey all, >>> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we >>> are running IS-IS but we are redesigning our core and now would be a good >>> time to switch. I would like to switch to OSPF, mostly because of >>> familiarity with OSPF over IS-IS. >>> What does everyone think? >>> >>> -- >>> CJ >>> >>> http://convergingontheedge.com >> >> > > From bpasdar at batblue.com Thu Aug 11 08:43:56 2011 From: bpasdar at batblue.com (Babak Pasdar) Date: Thu, 11 Aug 2011 09:43:56 -0400 Subject: Experience with Juniper MX-80s Message-ID: <20110811134356.1c673f90@concur.batblue.com> Hello NANOG Group, I am curious if anyone has any experiences positive or negative with Juniper MX-80s. Our recent experience with Juniper has not been great both in terms of new product offerings (SRX) and software bugs in the recent revs of Junos for the MX platform. I want to know if the MX-80 functions as advertised and in specific can properly handle two full IPv4 and IPv6 BGP feeds Thanks in advance, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability . Performance (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games Bat Blue's AS: 25885 | BGP Policy | Peering Policy Receive Bat Blue's Daily Security Intelligence Report Bat Blue's Legal Notice From streiner at cluebyfour.org Thu Aug 11 09:04:09 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 11 Aug 2011 10:04:09 -0400 (EDT) Subject: OSPF vs IS-IS In-Reply-To: References: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> Message-ID: On Thu, 11 Aug 2011, jim deleskie wrote: > Having run both on some good sized networks, I can tell you to run > what your ops folks know best. We can debate all day the technical > merits of one v another, but end of day, it always comes down to your > most jr ops eng having to make a change at 2 am, you need to design > for this case, if your using OSPF today and they know OSPF I'd say > stick with it to reduce the chance of things blowing up at 2am when > someone tries to 'fix' something else. Agreed. I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as part of an IPv6 rollout, and one of the key deciding factors in going with OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2. While there are difference between OSPFv2 and OSPFv3 in how they work, the learning curve is a lot less steep than going from OSPFv2 to IS-IS. jms > On Thu, Aug 11, 2011 at 10:29 AM, William Cooper wrote: >> I'm totally in concurrence with Stephan's point. >> >> Couple of things to consider: a) deciding to migrate to either ISIS or >> OSPFv3 from another protocol is still migrating to a new protocol >> and b) even in the case of migrating to OSPFv3, there are fairly >> significant changes in behavior from OSPFv2 to be aware of (most >> notably >> authentication, but that's fodder for another conversation). >> >> -Tony >> >> On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant >> wrote: >>> Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3. >>> >>> The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks. >>> >>> Stefan Fouant >>> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI >>> Technical Trainer, Juniper Networks >>> http://www.shortestpathfirst.net >>> http://www.twitter.com/sfouant >>> >>> Sent from my iPad >>> >>> On Aug 11, 2011, at 8:57 AM, CJ wrote: >>> >>>> Hey all, >>>> Is there any reason to run IS-IS over OSPF in the SP core? Currently, we >>>> are running IS-IS but we are redesigning our core and now would be a good >>>> time to switch. I would like to switch to OSPF, mostly because of >>>> familiarity with OSPF over IS-IS. >>>> What does everyone think? >>>> >>>> -- >>>> CJ >>>> >>>> http://convergingontheedge.com >>> >>> >> >> > > From cjinfantino at gmail.com Thu Aug 11 09:08:44 2011 From: cjinfantino at gmail.com (CJ) Date: Thu, 11 Aug 2011 10:08:44 -0400 Subject: OSPF vs IS-IS In-Reply-To: References: <19BE2525-CC30-4776-87D9-0E52957784D4@shortestpathfirst.net> Message-ID: Awesome, I was thinking the same thing. Most experience is OSPF so it only makes sense. That is a good tip about OSPFv3 too. I will have to look more deeply into OSPFv3. Thanks, -CJ On Thu, Aug 11, 2011 at 9:34 AM, jim deleskie wrote: > Having run both on some good sized networks, I can tell you to run > what your ops folks know best. We can debate all day the technical > merits of one v another, but end of day, it always comes down to your > most jr ops eng having to make a change at 2 am, you need to design > for this case, if your using OSPF today and they know OSPF I'd say > stick with it to reduce the chance of things blowing up at 2am when > someone tries to 'fix' something else. > > -jim > > On Thu, Aug 11, 2011 at 10:29 AM, William Cooper > wrote: > > I'm totally in concurrence with Stephan's point. > > > > Couple of things to consider: a) deciding to migrate to either ISIS or > > OSPFv3 from another protocol is still migrating to a new protocol > > and b) even in the case of migrating to OSPFv3, there are fairly > > significant changes in behavior from OSPFv2 to be aware of (most > > notably > > authentication, but that's fodder for another conversation). > > > > -Tony > > > > On Thu, Aug 11, 2011 at 9:06 AM, Stefan Fouant > > wrote: > >> Well up until not too long ago, to support IPv6 you would run OSPFv3 and > for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no > longer the case with support for IPv4 NLRI in OSPFv3. > >> > >> The only reason in my opinion to run IS-IS rather than OSPF today is due > to the fact that IS-IS is decoupled from IP making it less vulnerable to > attacks. > >> > >> Stefan Fouant > >> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > >> Technical Trainer, Juniper Networks > >> http://www.shortestpathfirst.net > >> http://www.twitter.com/sfouant > >> > >> Sent from my iPad > >> > >> On Aug 11, 2011, at 8:57 AM, CJ wrote: > >> > >>> Hey all, > >>> Is there any reason to run IS-IS over OSPF in the SP core? Currently, > we > >>> are running IS-IS but we are redesigning our core and now would be a > good > >>> time to switch. I would like to switch to OSPF, mostly because of > >>> familiarity with OSPF over IS-IS. > >>> What does everyone think? > >>> > >>> -- > >>> CJ > >>> > >>> http://convergingontheedge.com > >> > >> > > > > > -- CJ http://convergingontheedge.com From jason.duerstock at gallaudet.edu Thu Aug 11 09:19:17 2011 From: jason.duerstock at gallaudet.edu (Jason Duerstock) Date: Thu, 11 Aug 2011 10:19:17 -0400 Subject: OSPF vs IS-IS In-Reply-To: References: Message-ID: On Thu, Aug 11, 2011 at 8:57 AM, CJ wrote: > Hey all, > Is there any reason to run IS-IS over OSPF in the SP core? Currently, we > are running IS-IS but we are redesigning our core and now would be a good > time to switch. I would like to switch to OSPF, mostly because of > familiarity with OSPF over IS-IS. > What does everyone think? > > -- > CJ > > http://convergingontheedge.com > Granted, we're not a service provider, so we operate on a different scale here, but one interesting trick that can be done with ISIS (at least on Cisco) is this: router a ----------- router isis advertise passive-only interface loopback0 ip address 10.1.1.1 255.255.255.255 interface vlan2 ip unnumbered loopback0 ip router isis isis network point-to-point router b ----------- (copy router isis definition from router a) interface loopback0 ip address 10.1.1.2 255.255.255.255 (copy vlan2 definition from router a) ----------- This removes the associated headaches with /30s or /31s in having to keep track of their allocation, as well as having them clog the your routing table. -waits for replies stating why this is a bad idea- Now, if I could just get isis-per-vrf-instance support on the Catalyst 6500. Jason From frnkblk at iname.com Thu Aug 11 12:31:23 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 11 Aug 2011 12:31:23 -0500 Subject: IPv6 end user addressing Message-ID: <009e01cc584c$906be290$b143a7b0$@iname.com> This same Vendor C wants us to upgrade our 7206VXR's to ASR1K's just so we have the (hopefully working) IPv6 features in IOS-XE that are broken in 12.x. Frank -----Original Message----- From: Mark Newton [mailto:newton at internode.com.au] Sent: Wednesday, August 10, 2011 10:12 PM To: Cameron Byrne Cc: NANOG Subject: Re: IPv6 end user addressing On 11/08/2011, at 12:30 PM, Cameron Byrne wrote: > Finally a useful post in this thread. Good work on the deployment of real ipv6! > Thanks. And thanks to Vendor-C for helping us through it. The IPv6 Broadband featureset on the ASR platform starting from IOS-XR 3.1 is a vast improvement on its predecessors. Biggest hassle with IPv6 in production right now: DNS support is woefully undercooked. I don't think anyone has put anywhere near as much effort into making it fluid, user-friendly, and automated. Simple questions like, "How are reverse mappings supposed to work when you can't predict an end-user's address?" have no good answer. If any systems folks want a nice meaty problem domain to focus their efforts on, DNS would be da shiznit. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From owen at delong.com Thu Aug 11 12:34:40 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 10:34:40 -0700 Subject: IPv6 end user addressing In-Reply-To: <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> Message-ID: <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: > Owen wrote: > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, August 10, 2011 9:58 PM >> To: William Herrin >> Cc: nanog at nanog.org >> Subject: Re: IPv6 end user addressing >> >> >> On Aug 10, 2011, at 6:46 PM, William Herrin wrote: >> >>> On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong > wrote: >>>>> Someday, I expect the pantry to have a barcode reader on it >> connected back >>>>> a computer setup for the kitchen someday. Most of us already use >> barcode >>>>> readers when we shop so its not a big step to home use. >>>> >>>> Nah... That's short-term thinking. The future holds advanced >> pantries with >>>> RFID sensors that know what is in the pantry and when they were >> manufactured, >>>> what their expiration date is, etc. >>> >>> And since your can of creamed corn is globally addressable, the rest >>> of the world knows what's in your pantry too. ;) >>> >> >> This definitely helps explain your misconceptions about NAT as a >> security tool. >> >> >> Globally addressable != globally reachable. >> >> Things can have global addresses without having global reachability. >> There are >> these tools called access control lists and routing policies. Perhaps >> you've heard >> of them. They can be quite useful. > > And your average home user, whose WiFi network is an open network named > "linksys" is going to do that how? > Because the routers that come on pantries and refrigerators will probably be made by people smarter than the folks at Linksys? Owen From sthaug at nethelp.no Thu Aug 11 12:41:21 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 11 Aug 2011 19:41:21 +0200 (CEST) Subject: IPv6 end user addressing In-Reply-To: <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> References: <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> Message-ID: <20110811.194121.78787273.sthaug@nethelp.no> > > And your average home user, whose WiFi network is an open network named > > "linksys" is going to do that how? > > Because the routers that come on pantries and refrigerators will probably be > made by people smarter than the folks at Linksys? One could argue that routing and access control is even less of a core business feature for pantry and refrigerator manufacturers than it is for Linksys. So I wouldn't rule this out - but I'm definitely in the sceptical camp. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From os10rules at gmail.com Thu Aug 11 12:52:42 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Thu, 11 Aug 2011 13:22:42 -0430 Subject: IPv6 end user addressing In-Reply-To: <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> Message-ID: On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote: > > On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: > >> Owen wrote: >> >>> -----Original Message----- >>> From: Owen DeLong [mailto:owen at delong.com] >>> Sent: Wednesday, August 10, 2011 9:58 PM >>> To: William Herrin >>> Cc: nanog at nanog.org >>> Subject: Re: IPv6 end user addressing >>> >>> >>> On Aug 10, 2011, at 6:46 PM, William Herrin wrote: >>> >>>> On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong >> wrote: >>>>>> Someday, I expect the pantry to have a barcode reader on it >>> connected back >>>>>> a computer setup for the kitchen someday. Most of us already use >>> barcode >>>>>> readers when we shop so its not a big step to home use. >>>>> >>>>> Nah... That's short-term thinking. The future holds advanced >>> pantries with >>>>> RFID sensors that know what is in the pantry and when they were >>> manufactured, >>>>> what their expiration date is, etc. >>>> >>>> And since your can of creamed corn is globally addressable, the rest >>>> of the world knows what's in your pantry too. ;) >>>> >>> >>> This definitely helps explain your misconceptions about NAT as a >>> security tool. >>> >>> >>> Globally addressable != globally reachable. >>> >>> Things can have global addresses without having global reachability. >>> There are >>> these tools called access control lists and routing policies. Perhaps >>> you've heard >>> of them. They can be quite useful. >> >> And your average home user, whose WiFi network is an open network named >> "linksys" is going to do that how? >> > > Because the routers that come on pantries and refrigerators will probably be > made by people smarter than the folks at Linksys? > > Owen > > I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet. But I predict the coming of IPv6 to the home in a big way will have unintended consequences. I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. Greg From cmadams at hiwaay.net Thu Aug 11 12:53:25 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 11 Aug 2011 12:53:25 -0500 Subject: IPv6 end user addressing In-Reply-To: <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> References: <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> Message-ID: <20110811175325.GD13985@hiwaay.net> Once upon a time, Owen DeLong said: > Because the routers that come on pantries and refrigerators will probably be > made by people smarter than the folks at Linksys? That's highly doubtful, especially when Linksys is the "best" networking equipment the average person will buy (at Best Buy, Wal-Mart, etc.). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From owen at delong.com Thu Aug 11 13:18:26 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 11:18:26 -0700 Subject: IPv6 end user addressing In-Reply-To: <20110811.194121.78787273.sthaug@nethelp.no> References: <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> <20110811.194121.78787273.sthaug@nethelp.no> Message-ID: On Aug 11, 2011, at 10:41 AM, sthaug at nethelp.no wrote: >>> And your average home user, whose WiFi network is an open network named >>> "linksys" is going to do that how? >> >> Because the routers that come on pantries and refrigerators will probably be >> made by people smarter than the folks at Linksys? > > One could argue that routing and access control is even less of a core > business feature for pantry and refrigerator manufacturers than it is > for Linksys. So I wouldn't rule this out - but I'm definitely in the > sceptical camp. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Let's face it... CPE security needs are going to be radically different and consumer expectations are going to rise quickly in this area with IPv6. I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced to adapt. Owen From jj at diamondtech.ca Thu Aug 11 13:22:23 2011 From: jj at diamondtech.ca (Jeff Johnstone) Date: Thu, 11 Aug 2011 11:22:23 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> Message-ID: On Thu, Aug 11, 2011 at 10:52 AM, Greg Ihnen wrote: > > On Aug 11, 2011, at 1:04 PM, Owen DeLong wrote: > > > > > On Aug 11, 2011, at 5:41 AM, Jamie Bowden wrote: > > > >> Owen wrote: > >> > >>> -----Original Message----- > >>> From: Owen DeLong [mailto:owen at delong.com] > >>> Sent: Wednesday, August 10, 2011 9:58 PM > >>> To: William Herrin > >>> Cc: nanog at nanog.org > >>> Subject: Re: IPv6 end user addressing > >>> > >>> > >>> On Aug 10, 2011, at 6:46 PM, William Herrin wrote: > >>> > >>>> On Wed, Aug 10, 2011 at 9:32 PM, Owen DeLong > >> wrote: > >>>>>> Someday, I expect the pantry to have a barcode reader on it > >>> connected back > >>>>>> a computer setup for the kitchen someday. Most of us already use > >>> barcode > >>>>>> readers when we shop so its not a big step to home use. > >>>>> > >>>>> Nah... That's short-term thinking. The future holds advanced > >>> pantries with > >>>>> RFID sensors that know what is in the pantry and when they were > >>> manufactured, > >>>>> what their expiration date is, etc. > >>>> > >>>> And since your can of creamed corn is globally addressable, the rest > >>>> of the world knows what's in your pantry too. ;) > >>>> > >>> > >>> This definitely helps explain your misconceptions about NAT as a > >>> security tool. > >>> > >>> > >>> Globally addressable != globally reachable. > >>> > >>> Things can have global addresses without having global reachability. > >>> There are > >>> these tools called access control lists and routing policies. Perhaps > >>> you've heard > >>> of them. They can be quite useful. > >> > >> And your average home user, whose WiFi network is an open network named > >> "linksys" is going to do that how? > >> > > > > Because the routers that come on pantries and refrigerators will probably > be > > made by people smarter than the folks at Linksys? > > > > Owen > > > > > > I respectfully disagree. If appliance manufacturers jump on the bandwagon > to make their device *Internet Ready!* we'll see appliance makers who have > way less networking experience than Linksys/Cisco getting into the fray. I > highly doubt the pontifications of these Good Morning America technology > gurus who predict all these changes are coming to the home. Do we really > think appliance manufacturers are going to agree on standards for keeping > track of how much milk is in the fridge, especially as not just > manufacturing but also engineering is moving to countries like China? How > about the predictions that have been around for years about appliances which > will alert the manufacturer about impending failure so they can call you and > you can schedule the repair before there's a breakdown? Remember that one? > We don't even have an "appliance about to break, call repairman" idiot light > on appliances yet. > > But I predict the coming of IPv6 to the home in a big way will have > unintended consequences. > > I think the big shock for home users regarding IPv6 will be suddenly having > their IPv4 NAT firewall being gone and all their devices being exposed naked > to everyone on the internet. Suddenly all their security shortcomings (no > passwords, "password" for the password etc) are going to have catastrophic > consequences. I foresee an exponential leap in the number of hacks of > consumer devices which will have repercussions well beyond their local > network. In my opinion that's going to be the biggest problem with IPv6, not > all the concerns about the inner workings of the protocols. I'm guessing the > manufacturers of consumer grade networkable devices are still thinking about > security as it applies to LANs with rfc 1918 address space behind a firewall > and haven't rethought security as it applies to IPv6. > > Greg > +1 I think this is currently the biggest hole in IPV6 adoption. We need a drop in firewall appliance along the lines of IPCOP for IPV6. This type of closed unless tinkered with protection would encourage people to try it out and not be too scared to move forward. This is a huge opportunity for some Company/Open Source Developers Group to grab a huge chucnk of an emerging market... hint hint :) cheers Jeff From mike at mtcc.com Thu Aug 11 13:26:43 2011 From: mike at mtcc.com (Michael Thomas) Date: Thu, 11 Aug 2011 11:26:43 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> <20110811.194121.78787273.sthaug@nethelp.no> Message-ID: <4E441EE3.9050507@mtcc.com> On 08/11/2011 11:18 AM, Owen DeLong wrote: > On Aug 11, 2011, at 10:41 AM, sthaug at nethelp.no wrote: > > >>>> And your average home user, whose WiFi network is an open network named >>>> "linksys" is going to do that how? >>>> >>> Because the routers that come on pantries and refrigerators will probably be >>> made by people smarter than the folks at Linksys? >>> >> One could argue that routing and access control is even less of a core >> business feature for pantry and refrigerator manufacturers than it is >> for Linksys. So I wouldn't rule this out - but I'm definitely in the >> sceptical camp. >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> > Let's face it... CPE security needs are going to be radically different and consumer > expectations are going to rise quickly in this area with IPv6. > > I suspect both refrigerator/pantry makers _AND_ Linksys et. al. will be forced > to adapt. > Radically? How so? I have little confidence that the urge to do as little as possible about security is going to change just because of IPv6. The goal of router manufacturers is to turn a profit, not save the world. Mike From Mark.Meijerink at vancis.nl Thu Aug 11 15:08:53 2011 From: Mark.Meijerink at vancis.nl (Mark Meijerink) Date: Thu, 11 Aug 2011 20:08:53 +0000 Subject: Experience with Juniper MX-80s In-Reply-To: <20110811134356.1c673f90@concur.batblue.com> References: <20110811134356.1c673f90@concur.batblue.com> Message-ID: Babak, For one of our customers we run two MX-80's. Both with two full routing peers plus a lot of other smaller BGP peerings at a local IX. So far no strange behaviour or poor performance. Peerings are all IPv4 and IPv6. I don't know if you would need specific features but for the basic border router functionality it seems to perform as expected. Regards, Mark -----Original Message----- From: Babak Pasdar [mailto:bpasdar at batblue.com] Sent: Thursday, August 11, 2011 3:44 PM To: nanog at nanog.org Subject: Experience with Juniper MX-80s Hello NANOG Group, I am curious if anyone has any experiences positive or negative with Juniper MX-80s. Our recent experience with Juniper has not been great both in terms of new product offerings (SRX) and software bugs in the recent revs of Junos for the MX platform. I want to know if the MX-80 functions as advertised and in specific can properly handle two full IPv4 and IPv6 BGP feeds Thanks in advance, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability . Performance (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games Bat Blue's AS: 25885 | BGP Policy | Peering Policy Receive Bat Blue's Daily Security Intelligence Report Bat Blue's Legal Notice From khelms at ispalliance.net Thu Aug 11 15:28:07 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 11 Aug 2011 16:28:07 -0400 Subject: IPv6 end user addressing In-Reply-To: <8EBB04E9-8353-4AFF-B30E-E10BB23D2D3D@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> <4E42D151.6020603@ispalliance.net> <8EBB04E9-8353-4AFF-B30E-E10BB23D2D3D@delong.com> Message-ID: <4E443B57.6080501@ispalliance.net> Owen, The fact that you're immediately going to routing means you don't understand the problem. The costs I'm talking about don't have anything to do with routing or any of the core gear and everything to do with the pieces at the customer premise. Routers cost more to purchase than bridges because there is more complexity (silicon & software). Routers also cost more to manage for a service provider in almost all cases for residential customers. There are reasons to deploy routing CPE in some cases (the use cases are increasing with IP video in DOCSIS systems) but they are still very nascent. On 8/10/2011 7:24 PM, Owen DeLong wrote: > I'm pretty sure that I understand those things reasonably well. I'm quite certain that it doesn't > cost an ISP significantly more to deploy /48s than /56s as addresses don't have much of a > cost and there is little or no difficulty in obtaining large allocations for ISPs that have lots of > residential users. The difference between handing a user's CPE a /56 and a /48 will not make > for significant difference in support costs, either, other than the possible additional costs of > the phone calls when users start to discover that /56s were not enough. > > > Owen > > On Aug 10, 2011, at 11:43 AM, Scott Helms wrote: > >> Tim, >> >> Hence the "might". I worry when people start throwing around terms like routing in the home that they don't understand the complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation& managemenet, and (perhaps most importantly) the economics of mass adoption. This one of the choices that made DSL deployments more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete. >> http://goo.gl/exwqu >> >> >> >> On 8/10/2011 12:57 PM, Tim Chown wrote: >>> On 10 Aug 2011, at 16:11, Scott Helms wrote: >>> >>>> Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. >>> Well, there is some new effort on this in the homenet WG in IETF. >>> >>> For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. >>> >>> Tim >>> >>>> On 8/10/2011 9:02 AM, Owen DeLong wrote: >>>>> Bridging eliminates the multicast isolation that you get from routing. >>>>> >>>>> This is not a case for bridging, it's a case for making it possible to do real >>>>> routing in the home and we now have the space and the technology to >>>>> actually do it in a meaningful and sufficiently automatic way as to be >>>>> applicable to Joe 6-Mac. >>>>> >>>> -- >>>> Scott Helms >>>> Vice President of Technology >>>> ISP Alliance, Inc. DBA ZCorum >>>> (678) 507-5000 >>>> -------------------------------- >>>> http://twitter.com/kscotthelms >>>> -------------------------------- >>>> >>>> >> -- >> Scott Helms >> Vice President of Technology >> ISP Alliance, Inc. DBA ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Thu Aug 11 16:28:06 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 14:28:06 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E443B57.6080501@ispalliance.net> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> <4E42D151.6020603@ispalliance.net> <8EBB04E9-8353-4AFF-B30E-E10BB23D2D3D@delong.com> <4E443B57.6080501@ispalliance.net> Message-ID: <8DC8422C-52CD-417D-A08A-3230D163823D@delong.com> You're talking about the front end residential gateway that you manage. I'm talking about the various gateways and things you might not yet expect to provide gateways that residential end users will deploy on their own within their environments. The fact that you are talking about an entirely different problem space than I am shows that it is you who does not understand either the problem I am describing or the solution space that is applicable. Of course, in order for the ISP to properly support these things in the home, the ISP needs to terminate some form of IPv6 on some form of CPE head-end router in the home to which he will (statically or otherwise) route the /48 whether it is statically assigned or configured via DHCPv6-PD. Owen On Aug 11, 2011, at 1:28 PM, Scott Helms wrote: > Owen, > > The fact that you're immediately going to routing means you don't understand the problem. The costs I'm talking about don't have anything to do with routing or any of the core gear and everything to do with the pieces at the customer premise. Routers cost more to purchase than bridges because there is more complexity (silicon & software). Routers also cost more to manage for a service provider in almost all cases for residential customers. There are reasons to deploy routing CPE in some cases (the use cases are increasing with IP video in DOCSIS systems) but they are still very nascent. > > On 8/10/2011 7:24 PM, Owen DeLong wrote: >> I'm pretty sure that I understand those things reasonably well. I'm quite certain that it doesn't >> cost an ISP significantly more to deploy /48s than /56s as addresses don't have much of a >> cost and there is little or no difficulty in obtaining large allocations for ISPs that have lots of >> residential users. The difference between handing a user's CPE a /56 and a /48 will not make >> for significant difference in support costs, either, other than the possible additional costs of >> the phone calls when users start to discover that /56s were not enough. >> >> >> Owen >> >> On Aug 10, 2011, at 11:43 AM, Scott Helms wrote: >> >>> Tim, >>> >>> Hence the "might". I worry when people start throwing around terms like routing in the home that they don't understand the complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation& managemenet, and (perhaps most importantly) the economics of mass adoption. This one of the choices that made DSL deployments more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete. >>> http://goo.gl/exwqu >>> >>> >>> >>> On 8/10/2011 12:57 PM, Tim Chown wrote: >>>> On 10 Aug 2011, at 16:11, Scott Helms wrote: >>>> >>>>> Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. >>>> Well, there is some new effort on this in the homenet WG in IETF. >>>> >>>> For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. >>>> >>>> Tim >>>> >>>>> On 8/10/2011 9:02 AM, Owen DeLong wrote: >>>>>> Bridging eliminates the multicast isolation that you get from routing. >>>>>> >>>>>> This is not a case for bridging, it's a case for making it possible to do real >>>>>> routing in the home and we now have the space and the technology to >>>>>> actually do it in a meaningful and sufficiently automatic way as to be >>>>>> applicable to Joe 6-Mac. >>>>>> >>>>> -- >>>>> Scott Helms >>>>> Vice President of Technology >>>>> ISP Alliance, Inc. DBA ZCorum >>>>> (678) 507-5000 >>>>> -------------------------------- >>>>> http://twitter.com/kscotthelms >>>>> -------------------------------- >>>>> >>>>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ISP Alliance, Inc. DBA ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From owen at delong.com Thu Aug 11 16:35:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 14:35:25 -0700 Subject: IPv6 end user addressing In-Reply-To: References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <20110811004052.3242E12B5DD4@drugs.dv.isc.org> <275FEA2949B48341A3B46F424B613D857CDA@WDC-MX.photon.com> <125E015F-1111-46F4-93C8-72C2ED041BEE@delong.com> Message-ID: <56494910-9FFD-4FED-9C14-A271FF856AF4@delong.com> > > I respectfully disagree. If appliance manufacturers jump on the bandwagon to make their device *Internet Ready!* we'll see appliance makers who have way less networking experience than Linksys/Cisco getting into the fray. I highly doubt the pontifications of these Good Morning America technology gurus who predict all these changes are coming to the home. Do we really think appliance manufacturers are going to agree on standards for keeping track of how much milk is in the fridge, especially as not just manufacturing but also engineering is moving to countries like China? How about the predictions that have been around for years about appliances which will alert the manufacturer about impending failure so they can call you and you can schedule the repair before there's a breakdown? Remember that one? We don't even have an "appliance about to break, call repairman" idiot light on appliances yet. > What standards? The RFID tag on the milk carton will, essentially, replace the bar code once RFID tags become cheap enough. It'll be like an uber-barcode with a bunch more information. For keeping track of how much, cheap sensitive pressure transducers will know by the position of the RFID tag combined with the weight of the thing at that location in the refrigerator. There's no new standard required. The technology to do this exists today. The integration and mainstream acceptance is still years, if not decades off, but, IPv6 should last for decades, so, if we don't plan for at least the things we can see coming today and already know feasible ways to implement, we're doomed for the other unexpected things we don't see coming. > But I predict the coming of IPv6 to the home in a big way will have unintended consequences. > Definitely. > I think the big shock for home users regarding IPv6 will be suddenly having their IPv4 NAT firewall being gone and all their devices being exposed naked to everyone on the internet. Suddenly all their security shortcomings (no passwords, "password" for the password etc) are going to have catastrophic consequences. I foresee an exponential leap in the number of hacks of consumer devices which will have repercussions well beyond their local network. In my opinion that's going to be the biggest problem with IPv6, not all the concerns about the inner workings of the protocols. I'm guessing the manufacturers of consumer grade networkable devices are still thinking about security as it applies to LANs with rfc 1918 address space behind a firewall and haven't rethought security as it applies to IPv6. > Sigh... Continuing to propagate this myth doesn't make it any more true than it was 10 years ago. NAT != Security End-to-End addressing != End-to-End connectivity It will not be long before the average residential IPv6 gateway comes with a default deny all inbound stateful firewall built in. Once you have that, your hosts are not exposed naked to everyone on the internet. In fact, they are no more exposed than with NAT with the key difference being that if you choose to expose one or more hosts, you have the option of deliberately doing so. Actually, I know for certain that most of the CPE manufacturers are participating in the effort to draft better security requirements for residential gateways as a current ID and hopefully an RFC soon. I believe, as a matter of fact, that this is a BIS document being intended as a more comprehensive improvement over the initial version. Owen From khelms at ispalliance.net Thu Aug 11 16:53:20 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 11 Aug 2011 17:53:20 -0400 Subject: IPv6 end user addressing In-Reply-To: <8DC8422C-52CD-417D-A08A-3230D163823D@delong.com> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> <4E42D151.6020603@ispalliance.net> <8EBB04E9-8353-4AFF-B30E-E10BB23D2D3D@delong.com> <4E443B57.6080501@ispalliance.net> <8DC8422C-52CD-417D-A08A-3230D163823D@delong.com> Message-ID: <4E444F50.8070603@ispalliance.net> On 8/11/2011 5:28 PM, Owen DeLong wrote: > You're talking about the front end residential gateway that you manage. I'm talking about > the various gateways and things you might not yet expect to provide gateways that residential > end users will deploy on their own within their environments. The question I asked you is why should I as the service provider deploy routers rather than bridges as CPE gear for residential customers. If you didn't understand the question or didn't want to address that specific questions that's fine, but you certainly didn't answer that question. > Of course, in order for the ISP to properly support these things in the home, the ISP > needs to terminate some form of IPv6 on some form of CPE head-end router in the > home to which he will (statically or otherwise) route the /48 whether it is statically > assigned or configured via DHCPv6-PD. What is a CPE head-end router? That seems like an oxymoron. Where would such an animal live, in the home or the head end/central office? Who is responsible for purchasing it and managing it in your mind? > > Owen > > On Aug 11, 2011, at 1:28 PM, Scott Helms wrote: > >> Owen, >> >> The fact that you're immediately going to routing means you don't understand the problem. The costs I'm talking about don't have anything to do with routing or any of the core gear and everything to do with the pieces at the customer premise. Routers cost more to purchase than bridges because there is more complexity (silicon& software). Routers also cost more to manage for a service provider in almost all cases for residential customers. There are reasons to deploy routing CPE in some cases (the use cases are increasing with IP video in DOCSIS systems) but they are still very nascent. >> >> On 8/10/2011 7:24 PM, Owen DeLong wrote: >>> I'm pretty sure that I understand those things reasonably well. I'm quite certain that it doesn't >>> cost an ISP significantly more to deploy /48s than /56s as addresses don't have much of a >>> cost and there is little or no difficulty in obtaining large allocations for ISPs that have lots of >>> residential users. The difference between handing a user's CPE a /56 and a /48 will not make >>> for significant difference in support costs, either, other than the possible additional costs of >>> the phone calls when users start to discover that /56s were not enough. >>> >>> >>> Owen >>> >>> On Aug 10, 2011, at 11:43 AM, Scott Helms wrote: >>> >>>> Tim, >>>> >>>> Hence the "might". I worry when people start throwing around terms like routing in the home that they don't understand the complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation& managemenet, and (perhaps most importantly) the economics of mass adoption. This one of the choices that made DSL deployments more complex and expensive than DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete. >>>> http://goo.gl/exwqu >>>> >>>> >>>> >>>> On 8/10/2011 12:57 PM, Tim Chown wrote: >>>>> On 10 Aug 2011, at 16:11, Scott Helms wrote: >>>>> >>>>>> Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing setup (though I very seriously doubt it) in the home. Layer 2 isolation is both easier and more reliable than attempting it at layer 3 which is isolation by agreement, i.e. it doesn't really exist. >>>>> Well, there is some new effort on this in the homenet WG in IETF. >>>>> >>>>> For snooping IPv6 multicast it's MLD snooping rather than IGMP. We use it in our enterprise since we have multiple multicast video channels in use. >>>>> >>>>> Tim >>>>> >>>>>> On 8/10/2011 9:02 AM, Owen DeLong wrote: >>>>>>> Bridging eliminates the multicast isolation that you get from routing. >>>>>>> >>>>>>> This is not a case for bridging, it's a case for making it possible to do real >>>>>>> routing in the home and we now have the space and the technology to >>>>>>> actually do it in a meaningful and sufficiently automatic way as to be >>>>>>> applicable to Joe 6-Mac. >>>>>>> >>>>>> -- >>>>>> Scott Helms >>>>>> Vice President of Technology >>>>>> ISP Alliance, Inc. DBA ZCorum >>>>>> (678) 507-5000 >>>>>> -------------------------------- >>>>>> http://twitter.com/kscotthelms >>>>>> -------------------------------- >>>>>> >>>>>> >>>> -- >>>> Scott Helms >>>> Vice President of Technology >>>> ISP Alliance, Inc. DBA ZCorum >>>> (678) 507-5000 >>>> -------------------------------- >>>> http://twitter.com/kscotthelms >>>> -------------------------------- >>>> >> >> -- >> Scott Helms >> Vice President of Technology >> ISP Alliance, Inc. DBA ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From brian.e.carpenter at gmail.com Thu Aug 11 16:54:30 2011 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 12 Aug 2011 09:54:30 +1200 Subject: IPv6 end user addressing In-Reply-To: <20110811095348.GI16178@leitl.org> References: <201108101155.35498.a.harrowell@gmail.com> <4E428E62.40700@unfix.org> <1F6C0D3C-320E-4D72-BF41-C8796707B932@delong.com> <4E4335CA.807@gmail.com> <20110811095348.GI16178@leitl.org> Message-ID: <4E444F96.5060301@gmail.com> Eugen, On 2011-08-11 21:53, Eugen Leitl wrote: > On Thu, Aug 11, 2011 at 01:52:10PM +1200, Brian E Carpenter wrote: > >> Well, we know that the human population will stabilise somewhere below >> ten billion by around 2050. The current unicast space provides for about > > How about the machine population? How about self-replicating systems? I think considering the size of such systems as a function of the size of the human population is quite reasonable, in terms of thinking about natural and economic limits to growth. > How about geography-based address allocation, to go away with global routing > tables? That is a whole discussion in itself, but in any case it surely won't be part of 2000::/3. Additionally, the number of prefixes needed for any reasonable geographic scheme is quite trivial compared to the trillions available. > How about InterPlaNet, such as LEO routers, solar power > satellites, controlling industrial production on the Moon and elsewhere? Probably also trivial numbers compared to 15 trillion /48s, but if not, again, we are not limited to 2000::/3 for ever. EOF for me on this sub-topic. Brian From owen at delong.com Thu Aug 11 17:09:10 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Aug 2011 15:09:10 -0700 Subject: IPv6 end user addressing In-Reply-To: <4E444F50.8070603@ispalliance.net> References: <201108101155.35498.a.harrowell@gmail.com> <4E429FA4.2070506@ispalliance.net> <4E42D151.6020603@ispalliance.net> <8EBB04E9-8353-4AFF-B30E-E10BB23D2D3D@delong.com> <4E443B57.6080501@ispalliance.net> <8DC8422C-52CD-417D-A08A-3230D163823D@delong.com> <4E444F50.8070603@ispalliance.net> Message-ID: <92E449B7-238A-460D-9AAC-8829C9C532B2@delong.com> On Aug 11, 2011, at 2:53 PM, Scott Helms wrote: > On 8/11/2011 5:28 PM, Owen DeLong wrote: >> You're talking about the front end residential gateway that you manage. I'm talking about >> the various gateways and things you might not yet expect to provide gateways that residential >> end users will deploy on their own within their environments. > > The question I asked you is why should I as the service provider deploy routers rather than bridges as CPE gear for residential customers. If you didn't understand the question or didn't want to address that specific questions that's fine, but you certainly didn't answer that question. > I think i did below. However, in my region of the world, most service providers don't provide the CPE and most customers are BYOB. >> Of course, in order for the ISP to properly support these things in the home, the ISP >> needs to terminate some form of IPv6 on some form of CPE head-end router in the >> home to which he will (statically or otherwise) route the /48 whether it is statically >> assigned or configured via DHCPv6-PD. > > What is a CPE head-end router? That seems like an oxymoron. Where would such an animal live, in the home or the head end/central office? Who is responsible for purchasing it and managing it in your mind? > In the home and the consumer is responsible. The fact that you utterly want to avoid the concept of topology in the home shows me that you really aren't understanding where things already are in many homes and where they are going in the future. ISP->CPE Head End Router->