Re: Adding GPS location to IPv6 header
On Sun, Nov 25, 2012 at 02:19:48PM -0800, John Adams wrote: Your proposal doesn't even give people a way to encrypt their location data; By moving geodata to a portion of the protocol which is not covered It's not possible to hide location. Anonymity and efficient transport don't mix. This will become even more so at TBit/s transport rates. That's no problem, as you can use e.g. mix networks to provide strong anonymity for those who need at a higher layer. The sooner everbody realizes this, the sooner we can move on. by commonly used encryption methods (i.e. HTTPS, which is up a few layers in the stack) people can't be protected should this data be monitored by a malicious intermediary. Think: Syria, China, Iran, or any other government which will kill you for your words online. Application protocols sending GPS data under say, HTTPS protect the end user from revealing their location to anyone on their path, forcing an intermediary to look up the IP in a common geo database which will be mostly inaccurate in pinpointing users, and hopefully will save lives. Companies like Twitter, Facebook, and some parts of google are going HTTPS by default for this very reason. This proposal is dead, you don't have the sense to lie down.
AS12715 (Jazz Telecom S.A.) Peering contact
Hello! Could somebody provide me peering contact for AS12715 (Jazz Telecom S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact b...@jazztel.com but there are no replies from this email. Maybe somebody knows private contact? Thanks. -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: r...@alfatelecom.cz phone: +420 226 020 362
Re: AS12715 (Jazz Telecom S.A.) Peering contact
Hi, You could try n...@jazztel.com instead, hopefully they'll reply. Aris Lambrianidis AMS-IX B.V. http://www.ams-ix.net/ On Nov 26, 2012, at 11:01 PM, Network Department r...@alfatelecom.cz wrote: Hello! Could somebody provide me peering contact for AS12715 (Jazz Telecom S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact b...@jazztel.com but there are no replies from this email. Maybe somebody knows private contact? Thanks. -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: r...@alfatelecom.cz phone: +420 226 020 362
Re: AS12715 (Jazz Telecom S.A.) Peering contact
I sent email to this address but this is group contact email and I don't know when I'll be answered. I'm still interesting in direct contact email =) Thanks. On Mon, Nov 26, 2012 at 11:09 AM, Aris Lambrianidis aristidis.lambriani...@ams-ix.net wrote: Hi, You could try n...@jazztel.com instead, hopefully they'll reply. Aris Lambrianidis AMS-IX B.V. http://www.ams-ix.net/ On Nov 26, 2012, at 11:01 PM, Network Department r...@alfatelecom.cz wrote: Hello! Could somebody provide me peering contact for AS12715 (Jazz Telecom S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact b...@jazztel.com but there are no replies from this email. Maybe somebody knows private contact? Thanks. -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: r...@alfatelecom.cz phone: +420 226 020 362 -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: r...@alfatelecom.cz phone: +420 226 020 362
Re: Big day for IPv6 - 1% native penetration
My guess is that a non-trivial fraction of observed IPv6 traffic today is unintentional. almost all ip traffic is unintentional. i want my mtv. money for nothin' and the chicks are free. from a friend in a big broadband provider when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. the brick wall is 'smart' tee vees etc, which do not speak v6, and will have a five+ year lifetime. randy
Re: AS12715 (Jazz Telecom S.A.) Peering contact
Am 26.11.2012 11:01, schrieb Network Department: Could somebody provide me peering contact for AS12715 (Jazz Telecom S.A.)? I see they have OPEN peering policy at AMS-IX and peering contact b...@jazztel.com but there are no replies from this email. The address you mentioned is actually very responsive to me... -- Fredy Künzler Init7 (Switzerland) AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Zürich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/
RE: Adding GPS location to IPv6 header
On Sun, 25 Nov 2012, Ammar Salih wrote: Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any. This is not data that should be sent on every packet. It becomes redundant. 1- It does not have to be in every IPv6 header, only when there is location update. It should not be in any IPv6 packet. It has to be in an upper layer protocol. 2- the host should have the option of not sending location updates. In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information. A good alternative would be to create application layer protocols that could request and send GPS positions. 1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. I prefer application and at most the transport layer protocol extension. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html -- I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? 1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates. --- Thank you everyone for your time and professional feedback, I highly appreciate it! Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented. Thanks, Ammar From: Ammar Salih [mailto:ammar.sa...@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header Dears, I've proposed a new IPv6 extension header, it's now posted on IETF website, your ideas and comments are most welcome! http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t ext=1 Thanks! Ammar Salih
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 5:57 PM, Randy Bush wrote: almost all ip traffic is unintentional. Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct. when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. 'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
What do you mean with deliberate migration? Users do not care and they will never have a deliberate migration. However ISPs do, if the user have IPv6 it is because the ISP deliberate migrate to v6 by enable it in their backbone, networks and user's CPEs. IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. .as On 26/11/2012 09:24, Dobbins, Roland wrote: On Nov 26, 2012, at 5:57 PM, Randy Bush wrote: almost all ip traffic is unintentional. Sure. But my point is the notion that observed IPv6 traffic volumes are due to deliberate migration is not correct. when the average consumer (real) broadband connection becomes v6 capable, about 40% of the traffic is instantly ipv6, thank you netflix, facebook, netflix, google, netflix, and netflix. 'When', or 'if'? The creeping proliferation of CGNs and the like, along with your example of TVs and oblique point about the sparsity of IPv6-enabled content/services/applications, does not necessarily support the conclusion that wholesale migration within the near- or medium-terms is inevitable. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote: Users do not care and they will never have a deliberate migration. I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not. IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Mon, 26 Nov 2012, Dobbins, Roland wrote: I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not. We'll all be better off if we all move to IPv6 and don't go the NAT44(44) road longer than necessary. We can decide we want to wait for everybody else, which means we won't all be better off, ever. I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. Why is that a significant question? If they have IPv6, they will access a significant amount of content via IPv6. If they don't, then it's nothing. I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. There is so little traffic because ISPs do not turn on IPv6. The content is there now. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote: Why is that a significant question? It is significant because it provides some rough measure of the relative *importance* of IPv6 connectivity to the users and to the content/app/services networks. We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs. We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes. Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another. I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for them to do so. If they have IPv6, they will access a significant amount of content via IPv6. The definition of 'have IPv6' is somewhat nebulous, at present - that's part of the problem. I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. I'm not making that argument. There is so little traffic because ISPs do not turn on IPv6. The content is there now. As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play. Again, where're the compelling IPv6-only content/apps/services? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland rdobb...@arbor.net wrote: Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only. Stalemate. Damian
Re: Big day for IPv6 - 1% native penetration
On Mon, Nov 26, 2012 at 06:25:47AM -0800, Damian Menscher wrote: On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland rdobb...@arbor.net wrote: Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only. Recently, due to IPv4 scarcity some large mass hosters (OVH, and soon Hetzner) have started to charge for IP use, with pricing probably moving from current 1 EUR/IPv4 address/month to somewhere 2-5 EUR/IPv4 address/month. This price pressure both allows an efficient use of existing networks (by forcing customers to relinquish unused resources) and also will drive adoption of IPv6-only models, as these addresses remain free, for time being.
Re: Big day for IPv6 - 1% native penetration
Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Adding GPS location to IPv6 header
Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: pésimo. I couldn't find a similar one in English without using foul words :-) In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header. cheers! ~Carlos On 11/26/12 9:20 AM, Mohacsi Janos wrote: On Sun, 25 Nov 2012, Ammar Salih wrote: Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any. This is not data that should be sent on every packet. It becomes redundant. 1- It does not have to be in every IPv6 header, only when there is location update. It should not be in any IPv6 packet. It has to be in an upper layer protocol. 2- the host should have the option of not sending location updates. In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information. A good alternative would be to create application layer protocols that could request and send GPS positions. 1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. I prefer application and at most the transport layer protocol extension. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html -- I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? 1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates. --- Thank you everyone for your time and professional feedback, I highly appreciate it! Please be informed that this is only a draft, and I am requesting comments, I
Re: Big day for IPv6 - 1% native penetration
On Mon, 26 Nov 2012, Dobbins, Roland wrote: Again, where're the compelling IPv6-only content/apps/services? There is none. Why is it needed? We need IPv6 to make the Internet continue working and scale for the future. We don't need IPv6 to solve an individuals need, we need it for the long term common good of the Internet. Nobody is going to have IPv6 only content in the near future. This is no reason to have it. Users and content providers are going to be dual stacked. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Adding GPS location to IPv6 header
On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Another such application could be http://en.wikipedia.org/wiki/European_Data_Relay_Satellite (the realtime precision tracking problem has been solved recently). switch. In Spanish we have a very strong adjective for this kind of ideas: pésimo. I couldn't find a similar one in English without using foul words :-) In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Can you see any good uses for this? Area fencing, for games, maybe. I don't see why you couldn't just bind gpsd to port on a public IP, same as GPS sharing over WLAN tethering is done. So it's basically a solved problem, no need for RFC drafts. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any Some routers *are* already on the roofs. Or on towers. Or in LEO. Visibility is pretty good once you're above few 10 km, and weather is just perfect in orbit. The only storms are of the proton particle variety. real useful role for this extension header.
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On Tue, 20 Nov 2012, Miles Fidelman wrote: Christopher Morrow wrote: apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). Well, they ARE The Phone Company! Makes me want to watch The President's Analyst again ;) jms
Re: Big day for IPv6 - 1% native penetration
Sent from ipv6-only Android On Nov 26, 2012 5:54 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2012, at 8:33 PM, Mikael Abrahamsson wrote: Why is that a significant question? It is significant because it provides some rough measure of the relative *importance* of IPv6 connectivity to the users and to the content/app/services networks. Ipv6 is not important for users, it is important for network operators who want to sustain their business. We are not yet at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet in order to do their jobs. We are not even at the point where ordinary people need end-to-end IPv6 connectivity across the public Internet for recreational purposes. Providing IPv6 capabilities for popular content/apps/services like Google, Netflix, and Facebook is one thing. Creating compelling content/apps/services which are *only* accessible via IPv6 is another. Dont hold your breath. It wont happen, and in the end means nothing. I believe gaming developers are probably in the best position to provide such a stimulus, should they determine that it makes economic sense for them to do so. Nope. Nobody will leave money on the table by alienating users. If they have IPv6, they will access a significant amount of content via IPv6. The definition of 'have IPv6' is somewhat nebulous, at present - that's part of the problem. Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. I don't get why people are arguing that we shouldn't do IPv6 because IPv6 is so little of total traffic. I'm not making that argument. Good. There is so little traffic because ISPs do not turn on IPv6. The content is there now. As Randy noted, some big destination networks have in fact enabled IPv6 connectivity to their properties. A lot haven't, however, and user application capabilities/behaviors also come into play. Again, where're the compelling IPv6-only content/apps/services? Does not matter. And it will not happen. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). CB --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
CALEA options for a small ISP/ITSP
I have a CALEA appliance from BearHill that I 'rent'. It has been in my network for years. I'm looking for other alternative solutions for CALEA compliance with a small ISP. It looks like OpenCalea is a dead project. What is everyone else using? My current solution is $1k/month and I rarely get subpoenas, I've never had a wiretap one. My ISP network is a mix of Cisco and Juniper gear. I have a couple GigE connections to my upstreams and push 300-400mbps through the network. I would think that wireshark pcap files would be enough :( Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com
Re: Big day for IPv6 - 1% native penetration
Hi, Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found. Wow. Nice one! Sander
Re: Big day for IPv6 - 1% native penetration
On 11/26/12 15:53, sth...@nethelp.no wrote: Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling IPv6-only content I've found. http:///thepiratebay/.se./ipv6/.sixxs.org was popular for a while, when major ISP's in the Netherlands where forced to block 'The Piratebay' overhere in the Netherlands, I believe... -- Marco
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
Justin M. Streiner wrote: On Tue, 20 Nov 2012, Miles Fidelman wrote: Christopher Morrow wrote: apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). Well, they ARE The Phone Company! Makes me want to watch The President's Analyst again ;) Finally. Someone got the reference. :-) Cheers, Miles p.s. only $2.99 to rent in online, from Amazon: http://www.amazon.com/The-Presidents-Analyst-James-Coburn/dp/B0035JNSO8/ref=sr_1_1_vod_0_ren?ie=UTF8qid=1353945793sr=8-1 -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: CALEA options for a small ISP/ITSP
On Mon November 26 2012 09:38, Matthew Crocker wrote: I have a CALEA appliance from BearHill that I 'rent'. It has been in my network for years. I'm looking for other alternative solutions for CALEA compliance with a small ISP. It looks like OpenCalea is a dead project. What is everyone else using? My current solution is $1k/month and I rarely get subpoenas, I've never had a wiretap one. My ISP network is a mix of Cisco and Juniper gear. I have a couple GigE connections to my upstreams and push 300-400mbps through the network. I would think that wireshark pcap files would be enough :( Believe Mikrotik boxes support CALEA, you might check www.mikrotik.com -- Larry Smith lesm...@ecsis.net
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks. Does not matter. And it will not happen. Proof by repeated assertion doesn't sway me. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? These are important, yes. Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. I disagree, i simply see an additional fee for IPv4 coming about. Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks. Does not matter. And it will not happen. Proof by repeated assertion doesn't sway me. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? These are important, yes. Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). It's my contention that IPv6 won't be widely deployed unless/until end-customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. In face of your speculation i present to you facts: Google, Yahoo, Facebook, Bing (... other content and app providers) along with many access networks (VZW, Comcast, ATT DSL, KDDI, DT, Free ...) now have quite meaningful IPv6 deployments. ATT DSL and VZW LTE are in the millions of subs with IPv6 at this point. These are not the result of an IPv6-only service (i think there was some v6 p2p service at Free), and they are likely also not motivated by Grandma calling up and asking for IPv6 or she is switching providers. Why did they do this? Because IPv4 is run out and NAT is bad. I am not listing my own deployment since we are not default-on for IPv6 yet, but will be RSN. CB --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/26/2012 8:04 AM, Miles Fidelman wrote: Justin M. Streiner wrote: On Tue, 20 Nov 2012, Miles Fidelman wrote: Christopher Morrow wrote: apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). Well, they ARE The Phone Company! Makes me want to watch The President's Analyst again ;) Finally. Someone got the reference. :-) Cheers, Miles I alway go for WKRP http://www.youtube.com/watch?v=cTPzTG1Lx60
RE: Big day for IPv6 - 1% native penetration
Dobbins, Roland wrote: On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. Operators are all free to choose their own planning horizons. History is littered with the remnants of those with limited vision. Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. If you believe that is true you should do it and prove the point. Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches. Apple and msft os' s now make a clear judgement on that. So, you need to update your perspective. I'm not very interested in their judgement. So, I'm quite happy with my perspective, thanks. The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to making progress. Does not matter. And it will not happen. Proof by repeated assertion doesn't sway me. It will happen, just not anytime soon. As the access networks get deployed, traffic will shift, so eventually the question about the expense of maintaining an ever more complex IPv4 version of the app to deal with multi-layer nat to support a dwindling user base will have to be answered. The better question, for an isp, is what kind of ipv4 secondary market budget do you have? How hot is your cgn running? Like ALGs much ? Security and attribute much ? These are important, yes. Again , users dont care or know about v4 or v6. This is purely a network operator and app issue (cough cough ... skype). It's my contention that IPv6 won't be widely deployed unless/until end- customers call up their ISPs demanding this 'IPv6 or whatever' thing they need to accomplish some goal they have. And it is the contention of app developers that they can't make money on an app that that can't reach 99% of the intended user base. The entire point of tunnels is to break this absurd deadlock where access won't deploy without apps and apps won't deploy without access. Instead of getting on with it, there is an ongoing entrenchment and search for the utopian one-size-fits-all zero-cost transition plan. All this does is show how widespread the denial is, where people are refusing to let go of an entire career's worth of 'expertise' to keep up with the technology changes. Fortunately some have moved on, and are deploying despite the extra effort required in the short term. Once there are a substantial number of IPv6 access networks, the traffic volume will shift rapidly and people will start asking why the core is even aware of IPv4. At that point maintaining IPv4 will become the end user's problem, and they will have to find legacy tunnel providers if they want to keep that going. IPv4 won't die, it will just become an edge problem because the only reason to keep it running will be devices with embedded IPv4-only stacks which won't be replaced for 10 years. Tony
Re: Big day for IPv6 - 1% native penetration
We have numbers to share. We have performed two experiments at two different events LACNIC held this year: - June in Port-Au-Prince (~110 attendees) - October in Montevideo (~400 attendees) The question was: What is the relation between IPv4 and IPv6 traffic in a fully dual-stacked network?. The answers were remarkably consistent. We got ~30% IPv6 in PAP and around 33% in MVD (actually in MVD we got over 40% in total byte counts, but we corrected for the IPv6 video feed that added a constant 1 Mbps/sec) This percentage is calculated as: 100*(bytes sent and received over IPv6) / (total bytes sent and received) In PAP we measured this using iftop and a couple of pcap filters on the Linux server we were using as 'router' (Owen was there and was of great help setting the whole thing up). In MVD we had a dual 7201s as routers and we measured traffic with Netflow. Warm regards, ~Carlos On 11/21/12 12:51 AM, Patrick W. Gilmore wrote: On Nov 20, 2012, at 14:44 , Tony Hain alh-i...@tndh.net wrote: If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? If you assume Kinda says it all right there. But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries.
Re: LACNIC RPKI RTA key rollover
- Original Message - From: Carlos M. Martinez carlosm3...@gmail.com On Thursday, November 29, 2012 LACNIC will be performing a system migration to a new release of the RPKI system. We will take the opportunity to also perform a key rollover of LACNIC's RPKI trust anchor. The new TAL (trust anchor locator) file can be downloaded from [1]. Also a ready-to-use configuration file for RIPE-NCC's Validation Application is available at [2]. Never make two big changes at the same time. If it comes apart on you, you won't know which thing to roll back. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Big day for IPv6 - 1% native penetration
On Mon, Nov 26, 2012 at 12:15 PM, Cameron Byrne cb.li...@gmail.com wrote: On Mon, Nov 26, 2012 at 8:27 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2012, at 10:36 PM, Cameron Byrne wrote: Ipv6 is not important for users, it is important for network operators who want to sustain their business. I agree with the first part; not sure I agree with the second part. Nope. Nobody will leave money on the table by alienating users. I think it may be possible to make money with compelling IPv6-only content/services/applications. I disagree, i simply see an additional fee for IPv4 coming about. +1 And that in itself seems like it would make IPv6-reachable things a lot more compelling.
Re: Adding GPS location to IPv6 header
On Nov 26, 2012, at 06:56 , Carlos M. Martinez carlosm3...@gmail.com wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: pésimo. I couldn't find a similar one in English without using foul words :-) The rough translation of pésimo is terrible. And it certainly applies here. FYI. Owen In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header. cheers! ~Carlos On 11/26/12 9:20 AM, Mohacsi Janos wrote: On Sun, 25 Nov 2012, Ammar Salih wrote: Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any. This is not data that should be sent on every packet. It becomes redundant. 1- It does not have to be in every IPv6 header, only when there is location update. It should not be in any IPv6 packet. It has to be in an upper layer protocol. 2- the host should have the option of not sending location updates. In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol. 3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to. I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information. A good alternative would be to create application layer protocols that could request and send GPS positions. 1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language. 2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible. 3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others .. that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications. I prefer application and at most the transport layer protocol extension. [1] https://datatracker.ietf.org/wg/geopriv/charter/ [2] http://tools.ietf.org/html/rfc6442 [3] http://dev.w3.org/geo/api/spec-source.html -- I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us? 1- The host should have the option of not sending location updates. 2- It's extension header, means it's up to the service provider to use the feature or not. 3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7). Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc. Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine. 4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 04:57 , Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2012, at 7:10 PM, Arturo Servin wrote: Users do not care and they will never have a deliberate migration. I understand this. However, the way that IPv6 migration is discussed in most contexts seems to be predicated upon the notion that there is some industry imperative to light up network with IPv6. My point is that there is not. There is, actually. The fact that more users are constantly connecting more devices creates an industry imperative to light up a larger address space. CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. Any ISP that fails to light up its customers with IPv6 in the next 3 years is at serious risk of having its customers notice that they are no longer connected to the entire internet. Since 2011, IPv4 has been becoming a progressively smaller fraction of the internet. Today, that progression is very slow and it's still north of 99%. However, there is notable acceleration and given the rate of internet growth, within 5 years, I suspect that even if everything that is currently IPv4 remains IPv4 and all new services are still deployed with IPv4 in addition to IPv6, less than 60% of the internet will still be IPv4 at that time. IMHO if the user choose to change or not it is the least important, the real important fact is that IPv6 is taking up no matter if it is or not deliberate used by the users. I disagree somewhat with this view. The significant question is whether the users are actually accessing apps/services/content via IPv6, or if it's essentially white noise. Really, this isn't the important question, either. The important question is what is the rate of growth of the ability of users to access content/apps/services via IPv6? Further, what is the rate of growth in the provision of content/apps/services on dual-stack vs. IPv4-only? Later, the important question will become what fraction of users can still access the IPv4 internet through 2 layers of NAT? As I said, at current growth rates, by q4 2017, that final figure will be less than 60%. If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention. Owen [1] Things causing growth in the rate of internet attachment: IPv6-enabled light bulbs and other small appliances/sensors/etc. Smart-Grid/Smart-Meters Environmental Monitoring Sensor Arrays (things like projects to deploy literally millions of sensors in the oceans) Various 6lowpan based projects The eventual migration of what is currently Zigbee towards 6lowpan (OK, this one might be questionable, but it's certainly better for everyone except the Zigbee licensing folks if it goes that way) Public Safety applications (think telemetry-enabled ambulances) Bio-sensors (think remote patient monitoring, IPv6-enabled pace-makers and automatic-internal-defibrulators, etc.) Home automation Applications we haven't even thought of yet
Fwd: (via Dave Farber's IP list): Mark Crispin
Careful with followups, please, am sending this to multiple lists. ---rsk - Forwarded message - ? From: Barry Leiba barryleiba at computer.org ? To: imap5 at ietf.org, imapext at ietf.org, imap-protocol at u.washington.edu, imap-use at u.washington.edu ? Date: Mon, 19 Nov 2012 19:44:51 -0500 Everyone here knows Mark Crispin -- or at least knows who he is: Mark is the author of the original IMAP specification, and has taken it through its different versions to the present IMAP4rev1. He's written reference implementations of both server and client, and has been a vocal participant on all the mailing lists I'm posting this to. I'm sad to have to report that Mark is now terminally ill, and is in hospice care. For now, at least, I'm told that Mark is at least somewhat aware. If anyone has brief well-wishing messages they'd like to send him, please post them to the imap5 at ietf.org mailing list, and I'll forward them to Mark's long-term companion, Annie. I will also post updates to that list as I get them Barry Leiba - End forwarded message -
Re: Big day for IPv6 - 1% native penetration
Compulsion won't come from IPv6-only content. It will come from IPv6-only users. Any content/apps/service providers who fail to provide for this fact before we reach that point are making a bet-the-business gamble on the theory that NAT44(4...) will somehow scale well beyond what is likely IMHO. When we reach compulsion, it will not happen slowly or gracefully. We will have hit a wall with IPv4 and IPv4 will simply and suddenly stop growing. Likely in a rather graphic and unpleasant way because it will likely be when we hit some form of scaling limit on the NAT infrastructure where it suddenly keels over and IPv4 only users are down for a series of outages while everyone scrambles to remove load from the IPv4 network in order to get it running again. The alternative is to recognize the coming problem, deploy IPv6 proactively to content/apps/services and then wait for ISPs and end-users to catch up and begin using those IPv6 capabilities. Owen On Nov 26, 2012, at 06:25 , Damian Menscher dam...@google.com wrote: On Mon, Nov 26, 2012 at 5:53 AM, Dobbins, Roland rdobb...@arbor.net wrote: Again, where're the compelling IPv6-only content/apps/services? To answer your rhetorical question, http://www.kame.net/ has a dancing kame. To my knowledge, that's the most compelling IPv6-only content. Unsurprisingly, this does not drive user adoption, and major sites won't add IPv6-only content while a significant fraction of users are v4-only. Stalemate. Damian
Re: Big day for IPv6 - 1% native penetration
Owen DeLong wrote: less than 60% of the internet will still be IPv4 at that time. Do you mean IPv4 or IPv4 Only? Because unless the remaining percentage of IPv4 is noticeably less usable, it will still not incur any user demand, and IPv6 is still a cost mitigation strategy, and unless you wish to give up on connecting your users to that 40% you still need CGN, 644, what have you. Joe
Re: Adding GPS location to IPv6 header
On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl eu...@leitl.org wrote: On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed. 3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required. At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Adding GPS location to IPv6 header
This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work. On 26 November 2012 17:36, William Herrin b...@herrin.us wrote: On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl eu...@leitl.org wrote: On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed. 3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required. At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Adding GPS location to IPv6 header
The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. To the extent that you may apply IP ranges to wider geographical areas, and limit the search space to a few % of the total, beyond which devices get a new address pushed as they travel, this is entirely manageable without the new header. Some services dislike the endpoint renumbering like that, and some connections go kerfluey, but most web based activities handle the endpoint getting a new IP just fine; this is what cookies are for. Your SSH connections will remind you that you should be using screen, or not type and drive. But the CHP and road hazards will already do that. Eventually being allowed to use air-to-ground cell data on airliners will be slightly worse, but again, most protocols shrug at this problem. -george On Mon, Nov 26, 2012 at 2:36 PM, William Herrin b...@herrin.us wrote: On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl eu...@leitl.org wrote: On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This behavior is not presently guaranteed. 3. Assumes that the device will originate communication, receiving only replies from the landed end, or will use some intermediary to communicate current geographic information if inbound origination is required. At any rate, I think that discussion of adding a geographic option header to IPv6 should be tied up in the discussion of a routing protocol which critically depends on its presence and can't reasonably be built another way. Otherwise when a needful use case finally comes along, you'll discover that the option's rules of operation don't adequately enable it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- -george william herbert george.herb...@gmail.com
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: If you don't think that the need to sustain the growth in the number of devices attached to the network (never mind the number of things causing that rate to accelerate[1]) makes IPv6 inevitable at this point, you really aren't paying attention. What people ought to do and what they actually do are often quite different things. Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 12:15 AM, Cameron Byrne wrote: NAT is bad. I agree wholeheartedly with this sentiment. I'm unsure whether or not this is the prevalent view amongst those who control the pursestrings within network operators, however. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Adding GPS location to IPv6 header
On Mon, Nov 26, 2012 at 05:46:33PM -0500, Harald Koch wrote: This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work. Serval has about 200 m line of sight range. In general LoS visibility e.g. with pole-mounted directional Ubiquity gear is always as the crow flies.
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs. Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 12:38 AM, Tony Hain wrote: Unfortunately most people that actually deploy and support applications can't make the math come out right when the access providers don't provide a path to 99% of the paying customers, then do just about everything they can to hobble bypass approaches. AFAICT, most people who actually develop, deploy, and support applications don't do the math at all. It isn't an issue of perceived importance within their worldviews. In fact, it isn't an issue of which most of them are even peripherally aware. The overall system includes the perspective of app developers, not just BGP knob twisters, so the point of having a widespread api base is critical to making progress. Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? Maybe they're hiding in plain sight. But I don't think so. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Adding GPS location to IPv6 header
On Mon, Nov 26, 2012 at 5:46 PM, Harald Koch c...@pobox.com wrote: On 26 November 2012 17:36, William Herrin b...@herrin.us wrote: Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work. No. It assumes that the /128 route propagates far enough that every router (read: radio tower) operated by the service provider within the rough geographic locality has that route so that wherever the packet lands in the general area, it can make its way to the origin router currently talking to the device. It makes no assumptions about the particular path or paths between those two routers which could be terrestrial radio, satellite, wired or even a VPN across who knows what Internet path. It does set a requirement on the network architecture that at least one such path must exist: network partitions appear deadly to this architecture. I'm not saying this is a good idea. I'm just saying it's a legitimate topic for research and investigation which, if it shows any promise, would support the addition of a geolocation option header to IPv6's layer 3. By contrast, Ammar's other rationale for why to put it there (common interest at layer 7) aren't legitimate reasons for adding data to layer 3. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Big day for IPv6 - 1% native penetration
On 11/26/2012 03:18 PM, Dobbins, Roland wrote: Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo ready. Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6. I'm all for bagging on those two, but it seems pretty unjustified here. How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. I turned it on and it was pretty much a big ho-hum, cool it works. Mike
Cloudmark
Hi, Could someone from Cloudmark please contact me off list. I've been trying to get someone from sales to call me back for 3 weeks with no response. Thanks John Zettlemoyer
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 14:53, Dobbins, Roland rdobb...@arbor.net wrote: It is significant because Why*) do you believe it is important to waste everybody's time with these kinds of arguments? We have seen your kind of thinking. First, the Internet was never going to replace X.25/Frame Relay/leased lines and baling wire. Then you didn't need a web presence. Then it wasn't necessary to enable Web access out of the corporate networks. Then it wasn't necessary to accommodate user-owned equipment in enterprise networks. And so on, and so on. While these great arguments are going on in the board rooms, we are building out the technology. So it's there when you finally decide to shut up and give us the money. You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing. Grüße, Carsten *) Well, I think I can guess the answer, so this is mostly a rhetorical question. The need for rationalizing one's own bad decisions is one of the most powerful ways to cloud critical thinking.
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote: Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. Where are the *deployments*, though? And lighting up IPv6 within enterprises is not a trivial task. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Fwd: Big day for IPv6 - 1% native penetration
On 11/26/2012 03:18 PM, Dobbins, Roland wrote: Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? How much of a priority? I would say lots for Apple. Have you looked at the current Apple software? It pretty much just works on IPv6. IPv6 is on by default on end systems. Airport Extreme is listed as IPv6 compatible by, among other companies, Comcast. In Terminal, open an New Remote Connection to another Mac, do netstat -f inet6 and see that it is an IPv6 connection. Actually, it is more than a priority. It is pretty much a done deal. As for corporate IT departments, it depends on whether management is measured on monthly cash flow or by long term growth. I must note that many corporate IT departments have evolved from No one gets fired for buying IBM. to One might get fired for not buying Microsoft. This also automatically brings along IPv6 capabilities. DIGRESSION Elsewhere it has been said that end users don't care about IPv6. Well, that is generally true. They also don't care about IPv4, DOCSIS 3, ATM, PPPOE, and lots of other technical acronyms. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. To meet these expectations in a long term cost-effective manner, it behooves us network and content providers to remove all IPv4-forced hacks impeding easy end-system to end-system connections like all those 'wonderful' variants of NAT and artificially high pricing for IPv6. When the marketing folks begins to treat IPv6 as a sales enabler rather than a fanciful cost item, then we may see accelerated deployment of IPv6 alongside IPv4. /DIGRESSION
Re: Big day for IPv6 - 1% native penetration
On 11/26/2012 04:24 PM, Dobbins, Roland wrote: On Nov 27, 2012, at 6:56 AM, Michael Thomas wrote: Er, uh, huh? v6 has been available forever on the usual suspect host operating systems, and most server side apps don't need to do much to support lighting v6 support up that I can think of. Where are the *deployments*, though? Google and Facebook support ipv6. What more do we need? And lighting up IPv6 within enterprises is not a trivial task. Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. Mike
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 7:12 AM, Carsten Bormann wrote: We have seen your kind of thinking. You totally mischaracterize my 'kind of thinking'. My entire career arc has been that of a technological evangelist. Yes, I think there's a lot that's wrong with IPv6, but it appears that it's the only path forward we have, for the foreseeable future. It is very interesting that merely expressing skepticism regarding the rate, breadth, and depth of IPv6 deployment, and floating the proposition that some 'killer app' is needed in order to stimulate IPv6 deployment, is met with such over-the-top rhetoric and vitriol. So it's there when you finally decide to shut up and give us the money. As a consumer, I currently don't have the choice of paying for native IPv6 connectivity because it simply isn't available in the part of the world where I reside. Which is the part of the world that everyone says should benefit the most from IPv6 - i.e., Asia - but is also a part of the world which has practically zero consumer-grade IPv6 connectivity options, and precious few commercial-grade ones. You are much better off using your energy to plan ahead for that and ease the transitions, instead of inventing scales of significance that somehow prove to yourself you can continue doing nothing. Why do you think I am 'doing nothing'? When I was at Cisco, I relentlessly pushed for IPv4/IPv6 feature and performance parity, especially with regards to security and resiliency (much good that it did me, heh). I continue to advocate this stance. I am trying to point out that there are a lot of barriers to the near-universal deployment, or at least availability, of end-to-end IPv6 connectivity. It seems to me that many folks are overly optimistic in this regard, and that there must be some kind of incentive for ordinary users to push for IPv6 connectivity in order for it to achieve critical mass. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote: Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. It's hugely problematic to accomplish internally, never mind for external connectivity. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 7:27 AM, Cutler James R wrote: Have you looked at the current Apple software? It pretty much just works on IPv6. Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4. This also automatically brings along IPv6 capabilities. Capabilities deployment. Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On 11/26/2012 04:38 PM, Dobbins, Roland wrote: On Nov 27, 2012, at 7:35 AM, Michael Thomas wrote: Not on the server side that I can see. It's a network problem first and foremost, and starts by having the excuse that they can't get v6 upstream from their ISP's. It's hugely problematic to accomplish internally, never mind for external connectivity. But not because servers and client devices don't support it; they do. Bag on where the problem actually is: the death spiral of network vendors, ISP's and IT departments not wanting to commit and blaming each other. I primarily fault ISP's because they are, you know, the backbone. If they don't commit, the game of chicken continues. Mike
Re: Adding GPS location to IPv6 header
On Nov 26, 2012, at 14:51 , George Herbert george.herb...@gmail.com wrote: The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. That's true to a limited extent today. It's not likely to remain true. (No, it won't be the driver typing on their smartphone data connection, but it will be the busload or high-speed trainload of people typing, gaming, etc. all the way from SF to LA and/or other non-interactive data usages that are becoming more and more prevalent. Further, the speed of handoffs will have to get faster and the address stability area larger as that starts to include things like airplanes. Owen
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 7:53 AM, Michael Thomas wrote: If they don't commit, the game of chicken continues. Right - so, what new capabilities/economies of scale/essential conveniences are made possible by IPv6 but not IPv4, pour encourager les autres? This is not a rhetorical question. I believe it is a very relevant question that most of those who have the most pecuniary interests in ubiquitous IPv6 deployment are not even considering. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 7:47 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 27, 2012, at 7:27 AM, Cutler James R wrote: Have you looked at the current Apple software? It pretty much just works on IPv6. Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4. This also automatically brings along IPv6 capabilities. Capabilities deployment. Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. Well, at least you and I agree that IPv6 and IPv4 are simply Layer 3 protocols. Regarding there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6, your viewpoint ignores the millions and millions of end users/systems which will join networks around the globe in the near future. Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. Please note that this does not imply instant turndown of existing IPv4.
Re: Adding GPS location to IPv6 header
On Mon, Nov 26, 2012 at 4:53 PM, Owen DeLong o...@delong.com wrote: On Nov 26, 2012, at 14:51 , George Herbert george.herb...@gmail.com wrote: The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. That's true to a limited extent today. It's not likely to remain true. (No, it won't be the driver typing on their smartphone data connection, but it will be the busload or high-speed trainload of people typing, gaming, etc. all the way from SF to LA and/or other non-interactive data usages that are becoming more and more prevalent. Further, the speed of handoffs will have to get faster and the address stability area larger as that starts to include things like airplanes. Owen Right, but GPS location in these scenarios is not helpful. Because the network provider has plenty of evidence you're on the move - your cell location starts hopping at significant speeds, it's kind of obvious. You can either handle this with L3/4 stuff - painfully, but one can establish a regional forwarder net which is a downwards-looking default in each region, to handle L3 traffic for nodes that went off the reservation. Or you can handle this at L5 or above, in which case this is not our problem per se; it's the device and consumer services' website or central services site, or P2P type protocols designers problem to handle IP address flips etc. Which, frankly, already is being handled (most mobile users, anyone who uses WiFi in multiple locations + a phone data connection, etc). It's not totally seamless, but it works, and it's good enough. In either case, knowing the GPS location of the phone or device is not relevant to handling the problem or detecting it, beyond what the cell site data gives you naturally. As you already have to support devices hopping IPs, adding network foo (with evident significant downsides) which does not make that hopping IPs problem go away seems like it's a no-answer. -- -george william herbert george.herb...@gmail.com
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 15:10 , Dobbins, Roland rdobb...@arbor.net wrote: On Nov 27, 2012, at 3:37 AM, Owen DeLong wrote: CGN does not scale and cannot scale. At best, it's a hack that might allow us to cope with a few years of transition while there are still devices in homes that are IPv4-only, but it certainly doesn't reduce or remove the imperative. I agree wholeheartedly, but I'm unsure whether or not this view is held by those who control spending and prioritization within most, or even many, ISPs. Mobility (and everything is inexorably becoming mobile) is an obvious place where IPv6 makes a lot of sense, for example. But native IPv6 on one's own access networks and then gatewaying/proxying to IPv4 for actual 'Internet' connectivity seems to be a significant direction. Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6. If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy. Owen
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 8:15 AM, Owen DeLong wrote: Interesting. All the IPv6 capable carriers I talk to are only gatewaying/proxying to IPv4 for things unreachable via IPv6. Which is pretty much everything on the Internet. If you've got an IPv6 capable cell phone on an IPv6 capable mobile network, I doubt that you get to google through an IPv4 proxy. While I would be very surprised if you didn't, heh. Also, just how widely-deployed is IPv6 now for mobile networks? It would be very edifying to get some data around this . . . --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 8:07 AM, Cutler James R wrote: Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. Our views differ in that it is my belief that said truly horrendous and costly mismanagement of IPv4 address space is the norm now and will continue to be the norm for the foreseeable future, absent some positive economic stimulus to do otherwise. From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. When considering the entire value chain of Internet connectivity, I'm not sure if that's a true statement, or that it will become a true statement in the foreseeable future. Please note that this does not imply instant turndown of existing IPv4. Which is part of the problem. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Adding GPS location to IPv6 header
On 11/26/12, Alex dreamwave...@yahoo.com wrote: This would be great for troubleshooting things...I agree, but other than that it would create a whole new plethora of privacy concerns. Just about every new technology, IP itself included has privacy concerns, related to it; which is really just a fancy new name for security confidentiality concerns, regarding WHO is doing what things on the network. That doesn't mean you blacklist those technologies In fact, in some cases _identification_ of network nodes is a very good thing. I would like very much for spammers to be identifiable, even at the cost of some so-called privacy (not that embedding IP location data helps with that) Heck, HTTPS has privacy concerns, because it requires a certificate, containing personal details of the server to operate.I suppose it would be rather interesting if the certificate contained GPS details as well, if end hosts' IP stacks were required to verify the GPS data is either accurate or not present, and SSL clients were expected to validate that the details in the IP packets matched, and if a list of GPS positions was declared as a critical X509 extension. Then a third-party hosting provider would not be able to be used to spoof a HTTPS site (without the intruder gaining root access, in order to spoof IP packets). The existence of privacy concerns, does not mean you hesitate to implement a protocol in any way, shape or form. Privacy concerns,mean you as a user of that technology, pull out your handy dandy risk calculator, and weight the details carefully consider, what the probability and impact of the various risks actually are -- what bad things can actually happen, if the detail X is exposed, and what (if any) mitigations you choose for your particular scenario. Which will for end users typically involve setting a local policy such as: o Don't turn on the Populate Packet headers with Location data Or: o Don't stamp packets with location data, except to trusted hosts, when stamped packets are sent with headers encrypted over VPN in tunnel mode Or: o Introduce sufficient error, that the GPS data does not significantly compromise location -- -JH
ATT postmaster/mail admin
If there are eyeballs from ATT's postmaster group here, would you please contact me off list regarding a rather major blocking issue. Thanks. Regards, Annette
Re: Big day for IPv6 - 1% native penetration
On Mon, 26 Nov 2012, Dobbins, Roland wrote: Again, all the attention being lavished upon CGNs and 444 and whatnot are quite interesting indicators of perceived priorities. The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs). IPv6 is not today a viable alternative to CGN, one has to do both for a while before hopefully devices can do IPv6-only access and one can then have a centrally placed NAT64 (or similar) gateway. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
On Mon, 26 Nov 2012, Michael Thomas wrote: I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo ready. Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6. Not on the mobile side. Wifi yes, mobile no. I'm all for bagging on those two, but it seems pretty unjustified here. What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
On Nov 27, 2012, at 11:57 AM, Mikael Abrahamsson wrote: The problem is that CGN and NAT444 works with todays devices, whereas IPv6 does not (thinking mobile devices and residential CPEs). Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. It sort of reminds me of how artificial intelligence has been only 10 years away for the last 60 years or so. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Big day for IPv6 - 1% native penetration
On Tue, 27 Nov 2012, Dobbins, Roland wrote: Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. Dual stack works with everything. IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
In message alpine.deb.2.00.1211270558340.27...@uplift.swm.pp.se, Mikael Abrah amsson writes: On Mon, 26 Nov 2012, Michael Thomas wrote: I don't see either Apple or Microsoft as being the hindrance. In fact, both of them seem pretty ready, fsvo ready. Unlike ISP's by and large. But I'm pretty sure that both iPhones and Androids are pretty happy about being in v6 land since I see them showing up in my logs all the time, for the few providers that have lit up v6. Not on the mobile side. Wifi yes, mobile no. I'm all for bagging on those two, but it seems pretty unjustified here. What they need to start doing is testing Apps for IPv6 only access capabilitity. This doesn't work today, Apps like Waze, Spotify and others do not work on IPv6 only access. One could just start adding negative reviews to any product that doesn't work in a IPv6 only network. -- Mikael Abrahamssonemail: swm...@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Big day for IPv6 - 1% native penetration
2013 - the year of the NAT. (the only way a single stacked address family is going to be able to talk to a single stacked member of a different address family... and unless we start agressive reuse of v4, this will happen sooner than later (dual-stack is rate limited to the smaller of the address families -UNLESS- NAT makes reuse possible... :) But since NAT is going to be required -anyway- 2013 will be the year of the NAT. /bill On Tue, Nov 27, 2012 at 06:32:27AM +0100, Mikael Abrahamsson wrote: On Tue, 27 Nov 2012, Dobbins, Roland wrote: Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. Dual stack works with everything. IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
In message alpine.deb.2.00.1211270628380.27...@uplift.swm.pp.se, Mikael Abrah amsson writes: On Tue, 27 Nov 2012, Dobbins, Roland wrote: Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. Dual stack works with everything. IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. IPv6 only is easy to setup if you already have dual stack. On my Mac it is System Preferences, Network Preferences, Advanced, TCP/IP, IPv4 - Off then reboot to clear any lingering IPv4 references. It's about as easy on a Linux and a *BSD box. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [serval-project-dev] Re: Adding GPS location to IPv6 header
- Forwarded message from Jeremy Lakeman jer...@servalproject.org - From: Jeremy Lakeman jer...@servalproject.org Date: Tue, 27 Nov 2012 11:10:26 +1030 To: serval-project-develop...@googlegroups.com Subject: Re: [serval-project-dev] Re: Adding GPS location to IPv6 header Reply-To: serval-project-develop...@googlegroups.com Allocate an IPv6 private network range using a scheme like this; http://tools.ietf.org/html/draft-hain-ipv6-geo-addr-01 Probably with around 36 bits (100m) of precision, leaving the rest of the /64 to flag that it's private and geographically based. Internet gateways have their own real /64. Internet traffic would be routed to the correct gateway based on the network of the source address. If each device uses the same 64bit host id on each network. Local mesh route calculations can be based on a single main address per device, with an additional routing entry added for each network we believe that host should have. A protocol like SCTP will also allow both parties to change networks without needing to re-establish links. Then the biggest scalability problem for routing packets world-wide to an individual is a directory service for publishing and resolving current network locations. On Tue, Nov 27, 2012 at 9:40 AM, Eugen Leitl eu...@leitl.org wrote: - Forwarded message from George Herbert george.herb...@gmail.com - From: George Herbert george.herb...@gmail.com Date: Mon, 26 Nov 2012 14:51:57 -0800 To: William Herrin b...@herrin.us Cc: Eugen Leitl eu...@leitl.org, nanog@nanog.org Subject: Re: Adding GPS location to IPv6 header The utility of this is somewhat moderated by limited geographical mobility while a phone's active in a single session. One rarely drives from San Francisco to LA typing all the way on their smartphone data connection, for example. To the extent that you may apply IP ranges to wider geographical areas, and limit the search space to a few % of the total, beyond which devices get a new address pushed as they travel, this is entirely manageable without the new header. Some services dislike the endpoint renumbering like that, and some connections go kerfluey, but most web based activities handle the endpoint getting a new IP just fine; this is what cookies are for. Your SSH connections will remind you that you should be using screen, or not type and drive. But the CHP and road hazards will already do that. Eventually being allowed to use air-to-ground cell data on airliners will be slightly worse, but again, most protocols shrug at this problem. -george On Mon, Nov 26, 2012 at 2:36 PM, William Herrin b...@herrin.us wrote: On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl eu...@leitl.org wrote: On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez wrote: Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to I agree. You need to put it into L2, and the core usage would be for wireless meshes. Consider cases like Serval or cjdns, which run on Android headsets and equivalent embeddeds. Technically you wouldn't need GPS everywhere if you could do ~m scale time domain reflectometry in free space. It is possible to build a local contiguous map via mutual time of flight triangulation (actually, just visibility gives you a very good hint). Actually, I think you just articulated the first use for Ammar's idea that's not either wrong, absurd on its face or obviously better handled at a different location within the protocol stack. Suppose you have a large single-owner mesh network, such as a folks walking around with cell phones. If you want them to have a stable layer 3 address (and you do) then you're handling what amounts to /128 routes for tens of millions of devices. If you can guarantee that any packet *to* that address also contains a rough geographic location then you can discard any routes internally once they're more than a short geographic distance from the origin and route on the geography until you're close enough to find a specific /128 route. Tens of millions of routes is no problem if no single router needs to know more than a few thousand of them. By putting geographic location at layer 3, you're also handling it end to end which means you don't need a stateful border device to track the current location of all of those /128 routes. The device itself doesn't need to add location if it doesn't have the data; it's good enough for the receiving tower to attach a rough location. There are some assumptions in this model which are problematic. Key ones are: 1. Only valid as an interior gateway protocol (IGP). Geographic routing has been proven false for an EGP because it induces traffic to cross links for which neither source nor destination has permitted access. 2. Requires the application at the landed end to copy the IP option information into the outbound packets as well. This
Re: Big day for IPv6 - 1% native penetration
Subject: Re: Big day for IPv6 - 1% native penetration Date: Mon, Nov 26, 2012 at 11:18:13PM + Quoting Dobbins, Roland (rdobb...@arbor.net): How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? I am -- in addition to running eBGP for my employer -- also the acting network strategist and proper IP networking evangelist at my employer. We have been buying v6 compatible gear and connections for four years now. We are configuring IPv6 on all backbone links and are carefully deploying v6 to workstation and server networks all over the enterprise. Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? There are no v6-only deployments of SQL Server. The admins request and setup v4, the server requests and sets up v6, and the clients use whatever is in the DNS. The server will register in DNS so v6 has a fair chanche of getting chosen. Maybe they're hiding in plain sight. But I don't think so. We discovered that the HUB/TRANSPORT nodes in the Exchange collective talked Link-local v6 to the MBOX nodes. Service discovery. Magic. The Exchange admins had no idea, but that probably was because they are good, obedient employees and use the mandated email client, which makes viewing headers something of a challenge. V6 will, given a few careful pushes, deploy itself. Slightly exaggerated, but that's how it is. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I love ROCK 'N ROLL! I memorized the all WORDS to WIPE-OUT in 1965!! signature.asc Description: Digital signature
Re: Big day for IPv6 - 1% native penetration
On Tue, 27 Nov 2012, Mark Andrews wrote: The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. IPv6 only is easy to setup if you already have dual stack. On my Mac it is System Preferences, Network Preferences, Advanced, TCP/IP, IPv4 - Off then reboot to clear any lingering IPv4 references. It's about as easy on a Linux and a *BSD box. Well, they don't really have access to dual stack either, so... -- Mikael Abrahamssonemail: swm...@swm.pp.se
