Re: [Nanog-futures] Possible word error in section 18.1 Liability
On Sep 20, 2012, at 00:19 , Jack Hamm jackha...@me.com wrote: I'm not a lawyer, but in section 18.1: (a) beach of the director’s or officer’s duty of loyalty to NANOG; I believe that is meant to say (a) breach of the If it were a beach, I may run again =) -- TTFN, patrick ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Big Temporary Networks
David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Masataka Ohta
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 19, 2012, at 9:58 PM, Jimmy Hess mysi...@gmail.com wrote: There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage... Excellent idea. Now build a time machine, go back to 2005, and start work. It will be somewhat less relevant of a solution by 2019, which is about when you finish if you start today... The market window is closed. George William Herbert Sent from my iPhone
Re: The Department of Work and Pensions, UK has an entire /8
On 9/20/12 12:09 AM, George Herbert wrote: On Sep 19, 2012, at 9:58 PM, Jimmy Hess mysi...@gmail.com wrote: There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage... Excellent idea. Now build a time machine, go back to 2005, and start work. Sorry it was a bad idea then, it's still a bad idea. snip The market window is closed. yes George William Herbert Sent from my iPhone
Re: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org
From jrh...@netconsonance.com Wed Sep 19 20:47:44 2012 Subject: Re: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org From: Jo Rhett jrh...@netconsonance.com Date: Wed, 19 Sep 2012 18:46:54 -0700 Cc: nanog@nanog.org To: Robert Bonomi bon...@mail.r-bonomi.com --Apple-Mail=_C592EED8-365E-43DB-A1B1-35875736F2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 19, 2012, at 5:59 PM, Robert Bonomi wrote: In the financial and/or brokerage communities, there are internal = networks with enough 'high value'/sensitive information to justify air gap isolation from the outide world.=20 =20 Also, in those industries, there are 'semi-isolated' networks where all external commnications are mediated through dual-homed = _application- layer_ gateways. No packet-level communications between 'inside' and 'outside'. The 'inside' apps onl know how to talk to the gateway; = server- side talks only to specific (pre-determined) trusted hosts for the specific request being processed. NO 'transparent pass-through' in either direction. You're all missing the point in grand style. If you would stop trying = to brag about something that nearly everyone has done in their career = and pay attention to the topic you'd realize what my point was. This is = the last time I'm going to say this.=20 Not only do I know well those networks, I was the admin responsible for = the largest commercial one (56k routes) in existence that I'm aware of. = I was at one point cooperatively responsible for a very large one in = SEANet as well. (120k routes, 22k offices) I get what you are talking = about. That's not what I am saying. For these networks to have gateways which connect to the outside, you = have to have an understanding of which IP networks are inside, and which = IP networks are outside. Your proxy client then forwards connections to = outside networks to the gateway. You can't use the same networks = inside and outside of the gateway. It doesn't work. The gateway and the = proxy clients need to know which way to route those packets.=20 THUS: you can't have your own IP space re-used by another company on the = Internet without breaking routing. Duh. RFC1918 is a cooperative venture in doing exactly this, but you simply = can't use RFC1918 space if you also connect to a diverse set of other = businesses/units/partners/etc. AND there is no requirement in any IP = allocation document that you must use RFC1918 space. So acquiring unique = space and using it internally has always been legal and permitted. Now let's avoid deliberately misunderstanding me again, alright? --=20 Jo Rhett Net Consonance : net philanthropy to improve open source and internet = projects. --Apple-Mail=_C592EED8-365E-43DB-A1B1-35875736F2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htmlhead/headbody style=3Dword-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = divdivOn Sep 19, 2012, at 5:59 PM, Robert Bonomi = wrote:/divblockquote type=3DcitedivIn the financial and/or = brokerage communities, there are internal networksbrwith enough 'high = value'/sensitive information to justify air gapbrisolation from the = outide world. brbrAlso, in those industries, there are = 'semi-isolated' networks wherebrall external commnications are = mediated through dual-homed _application-brlayer_ gateways. No = packet-level communications between 'inside' andbr'outside'. nbsp;The = 'inside' apps onl know how to talk to the gateway; server-brside talks = only to specific (pre-determined) trusted hosts for thebrspecific = request being processed. nbsp;NO 'transparent pass-through' = inbreither = direction.br/div/blockquote/divdivbr/divYou're all missing = the point in grand style. nbsp;If you would stop trying to brag about = something that nearly everyone has done in their career and pay = attention to the topic you'd realize what my point was. This is the last = time I'm going to say this.nbsp;divbr/divdivNot only do I know = well those networks, I was the admin responsible for the largest = commercial one (56k routes) in existence that I'm aware of. I was at one = point cooperatively responsible for a very large one in SEANet as well. = (120k routes, 22k offices) I get what you are talking about. That's not = what I am saying./divdivbr/divdivFor these networks to have = gateways which connect to the outside, you have to have an understanding = of which IP networks are inside, and which IP networks are outside. Your = proxy client then forwards connections to outside networks to the = gateway.nbsp;You can't use the same networks inside and outside of the = gateway. It doesn't work. The gateway and the proxy clients need to know = which way to route those packets.nbsp;/divdivbr/divdivTHUS: = you can't have your own
Re: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER
On 9/19/12 5:29 AM, Phil Regnauld wrote: Joseph M. Owino (jpmuga) writes: Hi, Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. Hello Joseph, You could do this in a number of ways, running Quagga or BIRD (or even BGPD) on a Linux or BSD server. Quagga documentation even has a chapter on this: http://www.nongnu.org/quagga/docs/quagga.html#SEC115 I'm sure several people on this list have experience with this and will contribute. Also, it might be send this inquiry to the AfNOG list as well (afnog.org). Finally (plug) we have some resources that may be of interest to you here: https://nsrc.org/route-bgp-ixp.html Cheers, Phil Thought I would add some more links (Bird related...). Seems like the genesis has been from a single-rib on the RS to RIBs-per-client. And more recently to using the IRRs for additional filtering options. AMS-IX for example: https://www.ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers Here's that BIRD stuff... http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf https://git.nic.cz/redmine/projects/bird/wiki/Route_server_with_community_based_filtering http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg00505.html John Kemp (k...@routeviews.org)
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 20, 2012, at 12:21 AM, joel jaeggli joe...@bogus.com wrote: On 9/20/12 12:09 AM, George Herbert wrote: On Sep 19, 2012, at 9:58 PM, Jimmy Hess mysi...@gmail.com wrote: There is still no technical reason that 240/4 cannot be rehabilitated, other than continued immaterial objections to doing anything at all with 240/4, and given the rate of IPv6 adoption thus far, if not for those, it could possibly be reopened as unicast IPv4, and be well-supported by new equipment, before the percentage of IPv6-enabled network activity reaches a double digit percentage... Excellent idea. Now build a time machine, go back to 2005, and start work. Sorry it was a bad idea then, it's still a bad idea. Bad Idea or not, stopgap or not, it was and remains technically, programmatically, and politically feasible. The critical failure is that starting RIGHT NOW would deliver five years-ish too late, which renders it a moot point. In two or three years we may well regret not having done it in 2005; in seven years we will have had to have solved and deployed IPv6 successfully anyways. We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. Pining for 240/4 fjords is not a time machine to change the past. George William Herbert Sent from my iPhone
Re: Big Temporary Networks
On Thu, Sep 20, 2012 at 2:21 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Heavy reliance on broadcast for a wide range of instances where the traffic is really only destined for a single node would seem to be rather sub-optimal. /TJ
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 19, 2012, at 5:01 AM, Tim Franklin t...@pelican.org wrote: So...why do you need publicly routable IP addresses if they aren't publicly routable? Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the public Internet, whatever that is at any given point in time and space. RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. FYI, /John John Curran President and CEO ARIN
RIRs give out unique addresses (Was: something has a /8! ...)
On 2012-09-20 16:01 , John Curran wrote: On Sep 19, 2012, at 5:01 AM, Tim Franklin t...@pelican.org wrote: So...why do you need publicly routable IP addresses if they aren't publicly routable? Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the public Internet, whatever that is at any given point in time and space. RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. This is quite not what is meant with using it completely off-grid, thus not showing up in the global Internet BGP routes anywhere. Greets, Jeroen
Re: The Department of Work and Pensions, UK has an entire /8
George Herbert wrote: We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. Pining for 240/4 fjords is not a time machine to change the past. George William Herbert Sent from my iPhone What is not amusing is continued evidence that the lessons from this debacle have not been learned. Baking in bogonity is bad. Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? Joe
Re: The Department of Work and Pensions, UK has an entire /8
Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? Joe Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.). Also, the impact of the changes required is close to the same in that every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)* /TJ
Re: RIRs give out unique addresses (Was: something has a /8! ...)
On Sep 20, 2012, at 10:10 AM, Jeroen Massar jer...@unfix.org wrote: On 2012-09-20 16:01 , John Curran wrote: It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are publicly routable address space (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John
Re: The Department of Work and Pensions, UK has an entire /8
TJ wrote: Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? Joe Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.). ::/3 /48 /64 Do you think we may ever come to regret baking that in? And use that regret to torpedo any attempts at change? As far as roi is concerned, we can make all the calculation we want. What we cannot do is force everyone else to come up with the same numbers we did. Also, the impact of the changes required is close to the same in that every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)* /TJ The scope of the change is far far different, no matter the use case. Never more than a simple update. Joe
RE: RIRs give out unique addresses (Was: something has a /8! ...)
I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -Original Message- From: John Curran [mailto:jcur...@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar jer...@unfix.org wrote: On 2012-09-20 16:01 , John Curran wrote: It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are publicly routable address space (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John
Re: The Department of Work and Pensions, UK has an entire /8
Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? Joe Easy - Greater return on the investment; i.e. - instead of getting an IPv4 /4 out of the effort you get an IPv6 Global Unicast Space of 2000::/3 (just for starters, counting neither the rest of the unicast nor multicast, etc. spaces.). ::/3 /48 /64 Do you think we may ever come to regret baking that in? And use that regret to torpedo any attempts at change? If we do ever grow to regret the /48 and /64 splits, I guess it is a good thing we have 5 more /3s to deal with it ... As far as roi is concerned, we can make all the calculation we want. What we cannot do is force everyone else to come up with the same numbers we did. We also cannot make everyone happy all of the time. We can only do the best we can, and make it work as good as we can. Such is life. Also, the impact of the changes required is close to the same in that every node needs to be touched - that is the hard part, getting updates deployed. *(Unless you want 240/4 to be a special/limited use case - in which case the effort is smaller, but so is the reward ...)* The scope of the change is far far different, no matter the use case. Never more than a simple update. Yes, but making a change (regardless of size) on a given platform is often dwarfed by the effort of getting the update pushed out, to every possible instance of said platform. Multiply that by the number of platforms ... With IPv6, it is a bigger single change (in code terms), but the hard part (deployment) is roughly the same order of magnitude in deployment. It is also easier to know if your platform is in an area that now has IPv6, vs a router discovering whether or not the hosts understand the new /4. That is, dual-stack (IPv4 + IPv6) create fewer problems than the coexistence of nodes supporting 240/4 and not supporting 240/4. And again, an additional IPv4 /4 is *just a bit smaller* than what IPv6 brings to the table ... /TJ *... all IMHO / IME, of course.*
RE: RIRs give out unique addresses (Was: something has a /8! ...)
There is no such thing as Internet routers there are my routers, your routers, and that guy over there's routers. Even if you get your ISP to route it for you - that does not guarantee that any other network anywhere else on the internet will accept the route. Getting your ISP to accept your prefix is arguably, only a small part of being reachable/routable. --Heather -Original Message- From: Naslund, Steve [mailto:snasl...@medline.com] Sent: Thursday, September 20, 2012 10:56 AM To: nanog@nanog.org Subject: RE: RIRs give out unique addresses (Was: something has a /8! ...) I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -Original Message- From: John Curran [mailto:jcur...@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar jer...@unfix.org wrote: On 2012-09-20 16:01 , John Curran wrote: It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are publicly routable address space (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John
Re: RIRs give out unique addresses (Was: something has a /8! ...)
On Sep 20, 2012, at 10:56 AM, Naslund, Steve snasl...@medline.com wrote: Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cut...@consultant.com
RE: RIRs give out unique addresses (Was: something has a /8! ...)
From a practical point of view as a service provider, I would assume my customer would not be pleased to be assigned an address that prevented them from communicating with anyone on the Internet that wants to communicate with them. We can debate the details of who does what but every network operator will have to deal with their own customer. If they have an address block assigned to them, they will most likely want me to route it as well as work with any other service provider to ensure that they can get where they need to go. For example, if one of my customers cannot get to anyone on ATT or Comcast they will expect me to solve the issue for them. As the customer's single point of contact with the Internet we effectively have to deal with all of their issues even if they are caused by another service provider. All the ISPs raise your hand, if you were assigned a block of address space by ARIN or RIPE and you could not globally route it, would you be upset? Of course there are times I want a globally unique address space and do not want to route it but the whole point of being globally unique is that I would like the option to route it if I wanted to. The requirement for globally unique but non-routable space is most definitely an edge case, not the norm. Steven Naslund -Original Message- From: Cutler James R [mailto:james.cut...@consultant.com] Sent: Thursday, September 20, 2012 10:36 AM To: nanog@nanog.org Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:56 AM, Naslund, Steve snasl...@medline.com wrote: Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cut...@consultant.com
Re: Big Temporary Networks
- Original Message - From: William Herrin b...@herrin.us My point is that blaming union contracts or union anything for being unable to find a place to hold a convention where you can implement the network you want to implement is nonsense. NANOG, ARIN and IETF conferences have all somehow managed to implement their own effective networks. Even in union towns. If Worldcon's site selection committee can't find a suitable host, that's their deficiency. That's as may be, Bill, but it is definitively outside *my* personal scope, here. 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: RIRs give out unique addresses (Was: something has a /8! ...)
At 9:56 -0500 9/20/12, Naslund, Steve wrote: I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. ARIN does not provide transit - how could they guarantee or even just provide best-effort routability? However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? Perhaps, but that is misguided. ARIN, et.al. don't get involved in peering or block lists or firewall configuration guides or hurricane forecasting or ... anything else that bars reachability. If I decide to unilaterally block traffic from your address range, ARIN, et.al., can't do anything about it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!
Re: Big Temporary Networks
- Original Message - From: Rick Alfvin ralf...@verilan.com Verilan is the exclusive network services provider for NANOG, IEEE 802, IETF, ICANN, ZigBee Alliance, MAAWG, OIF, GENIVI, Tizen and many other technical organizations. We deploy large temporary networks to provide high density WI-Fi for meetings, events and conferences all over the world where Internet connectivity is mission critical to the success of the event. I'm quite certain I have a good idea of the magnitude of what you'd charge for professional services for such work, and I would expect it to be 2-3 orders of magnitude larger than what a Worldcon Concom could afford to pay. :-) I would also be very surprised -- having been on NANOG for over a decade now and never having heard your name -- to find out that you were the Exclusive Network Services Provider for NANOG... And I expect they'd be surprised too. Hey! Let's ask them! :-) 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: Real world sflow vs netflow?
On Sat, Jul 14, 2012 at 1:30 AM, Łukasz Bromirski luk...@bromirski.net wrote: sFlow is really sPacket, as it doesn't deal with flows. NetFlow, jFlow, IPFIX deal with flows. I am a puzzled by the orthodoxy that seems to prevail around the value flows as a measure of network traffic in packet switched networks. The following article contains some thoughts on flow oriented and packet oriented measurements. Apologies to NANOG readers for the simplistic analogies used to describe packet switching, the article is also intended for server administrators and application developers who often don't really know what happens when they write some bytes to a TCP socket. http://blog.sflow.com/2012/09/packets-and-flows.html The article positions flows as a useful abstraction for characterizing host and application performance, but as a poor fit for understanding packet traffic and measuring the performance of packet switches and routers. This isn't really an issue of sFlow vs. NetFlow/IPFIX etc. Either protocol can be used to export both types of measurements; the question is what types of measurement should be exported. What do people think? Peter
Re: IPv6 Burgers (was: IPv6 Ignorance)
On 2012-09-17 13:48, Richard Brown wrote: Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. Just got to playing with this today, trying to put it in some sort of perspective. First off, lets bring that down to human-sized numbers, using standard units used in astronomy: 2^94 inches = 16 gigaparsecs + 304 megaparsecs + 322 kiloparsecs + 752 parsecs + 2 lightyears + 57101 au + 23233 earthradius (Gigaparsecs isn't very common, but that's because it's a bit big.) So... How big is that? What can we compare it to? Well, let's start at the top: does this thing actually fit in our universe? The size of the observable universe is set by the Hubble Constant and lightspeed: The Hubble Constant is the rate of growth of expansion in the universe - the redshift phenomena. The further away you look, the faster things are moving away from us. At a certain point, they are moving away from us faster than light, meaning that light coming from them would never reach us. That's about 14 gigaparsecs away. (Adjusting for such things as how much they will have moved since you measured them. There's a whole rabbit hole to go down for this, on Wikipedia alone.) Which means the observable universe is about 28 gigaprsecs across. (Now you can see why gigaparsecs isn't a common unit.) So our hamburger patty would fit inside it - but you wouldn't be able to see one end from the other. Ever. In fact, while someone at the center could reach either end, once they got there they'd never be able to reach the other. They wouldn't even be able to get back to where they started. Which of course means that even if you ate at lightspeed, you'd never be able to eat it. (Oh, and if it still has a radius of 3 inches - standard 1/4 pound burger at 1/4 inch thick - it's got a volume around that of 11,000 Earths, and a mass of about 1,400 Earths, about 4.6 times the mass of Jupiter.) It's straightforward unit conversions. There are 2^96 IPv4 Hamburgers at a quarter-inch apiece. That's 2^96 inches/4 (2^94 inches). Switching to decimal units, 1.98x10^32 inches; 1.65x10^27 feet; 3.13x10^23 miles; and then continuing to convert to light-years. A good tool for this kind of wacky unit conversion is Frink (http://futureboy.us/fsp/frink.fsp?fromVal=2%5E94+inchestoVal=lightyears), which can do this in one shot. Simply enter: I prefer the 'units' program, which is usually a standard utility on Unix-like boxes. (If not in your distro of choice, finding the GNU or BSD versions is left as an exercise for the reader. ;) ) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: Big Temporary Networks
On 9/20/12 9:52 AM, Jay Ashworth wrote: I'm quite certain I have a good idea of the magnitude of what you'd charge for professional services for such work, and I would expect it to be 2-3 orders of magnitude larger than what a Worldcon Concom could afford to pay. :-) I would also be very surprised -- having been on NANOG for over a decade now and never having heard your name -- to find out that you were the Exclusive Network Services Provider for NANOG... And I expect they'd be surprised too. Hey! Let's ask them! :-) Cheers, -- jra That's funny, my mailing archive says you had a conversation with the network contractor on this list during NANOG 53.
Apologies to the Verilan guy
I've had it pointed out to me that I talked to those folks on the list, during NANOG 53 or its runup. Um, oops. Sorry. :-) I still don't think we can afford you, though. 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: Real world sflow vs netflow?
On 20/09/2012 17:59, Peter Phaal wrote: What do people think? Flows are good for measuring some things; raw packet sampling is good for measuring others. Decide on what you're trying to measure, then pick the best tool for the job. Nick
Re: Real world sflow vs netflow?
On Thu, 20 Sep 2012, Peter Phaal wrote: I am a puzzled by the orthodoxy that seems to prevail around the value flows as a measure of network traffic in packet switched networks. What platforms actually do real unsampled netflow today, and do it well for multi-10gigabit worth of typical Internet traffic? Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so, and then I don't really see the fundamental difference in doing the flow analysis on the router itself (classic netflow) or doing the same but at the sFlow collector. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: The Department of Work and Pensions, UK has an entire /8
On Thu, 20 Sep 2012 00:21:45 -0400, Joe Maimon said: Why is this cast as a boolean choice? And how has the getting on with IPv6 deployment been working out? 60% of our traffic is IPv6 now. Working out pretty good for us. pgpcdxf9LHhzh.pgp Description: PGP signature
RE: Big Temporary Networks
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Wednesday, September 19, 2012 11:21 PM To: David Miller Cc: nanog@nanog.org Subject: Re: Big Temporary Networks David Miller wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Your own example --- -Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Wednesday, September 19, 2012 1:26 AM To: nanog@nanog.org Subject: Re: Big Temporary Networks ... that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs ... IPv4 has a train load of devices unicasting and retransmitting all the dropped packets, where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. Therefore IPv4 is suboptimal in its abuse of the air link which could have been used for real application traffic instead of being wasted on device configuration. Thus by extension using your logic it is not operational. Just because you personally want IPv6 to be nothing more than IPv4 in every aspect is no reason to troll the nanog list and create confusion that causes others to delay their IPv6 deployment. Your complaints about IPv6 behavior on wifi ignore the point that IPv6 ND behavior was defined before or in parallel as wifi was defined by a different committee. There will always be newer L2 technologies that arrive after an L3 protocol is defined, and the behavior of the L3 will be 'suboptimal' for the new L2. When the issue is serious enough to warrant documentation, addendum documents are issued. When it is simply a matter of personal preference, it is hard to get enough support to get those documents published. Tony
the economies of scale of a Worldcon, and how to make this topic relevant to Nanog
In a message Jay had apparently forwarded from offlist (or I missed the original) Rick said: From: Rick Alfvin ralf...@verilan.com Verilan is the exclusive network services provider for NANOG, IEEE 802, IETF, ICANN, ZigBee Alliance, MAAWG, OIF, GENIVI, Tizen and many other technical organizations. We deploy large temporary networks to provide high density WI-Fi for meetings, events and conferences all over the world where Internet connectivity is mission critical to the success of the event. This points out another significant facter to why network isn't part of what's negotiated here. Internet is *not* considered mission critical by most attendees. Cheaper hotel rooms, adequate facilities, and inexpensive food nearby are the top three items Worldcon attendees complain about. So it's not going to be on the top of things to focus on. (and why this topic as it is being discussed is not relevant to this list) Those of us who feel Internet access is mission critical carry LTE network devices or make other arrangements. Obviously the growth of smartphones and tablets is starting to change that equation, but at the moment none of the Worldcons have done a very good job of providing useful online interaction so there's no actual use for onsite data related to the conference itself. Obviously I would love to see this change. For those who care about the economics of Worldcons, the following post is from a person deeply involved in the organization which holds the rights and trademarks for Worldcon. (Think Olympic Site Selection Committee, except they don't select the locations -- the members do) He covers a lot of the topics about why Worldcons are so very, very different from any of the conferences listed above, and why the economics of scale these conventions have don't work: http://kevin-standlee.livejournal.com/1166167.html Now, if we want to make this topic relevant to Nanog, the operative question is the feasability of a data provider putting good wireless gear near these facilities and selling data access to attendees. For a useful comparison, the 2010 Worldcon in Melbourne had an expensive wifi service in the building that kept falling over. A cell provider across the street put up banners advertising cheap data service, and put people on the sidewalk in from of the convention selling pay as you go SIM cards with data service. They made brisk business. *THIS* is where us network operators can provide good networking service to a large facility, and pretty much kill the expensive data plans operated by the facility. Instead of building up and tearing down a network for each convention, put an LTE tower near the facility and sell to every group that uses the convention center. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: The Department of Work and Pensions, UK has an entire /8 nanog@nanog.org
On Sep 19, 2012, at 7:09 PM, Brett Frankenberger wrote: It works fine if the gateway has multiple routing tables (VRF or equivalent) and application software that is multiple-routing-table aware. If you are arguing that it is technically possible to build an environment in which every piece of software is aware at an application level whether or not a given service is inside the network or outside the network and thus eliminate issues with routing overlaps… uh, sure. I agree that you can do this in a very customized environment. Now if you want to suggest that most businesses with a diversity of applications and access methods should be doing this, in order to allow overlapping IP usage on the internet, I'm going to have to point and giggle. I really love how everyone keeps advancing these businesses should rebuild their entire infrastructure, at their cost, and with no benefit to themselves, so that I can use their IP space! arguments. Ya huh. Right. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
RE: The Department of Work and Pensions, UK has an entire /8
-Original Message- From: Joe Maimon [mailto:jmai...@ttec.com] Sent: Thursday, September 20, 2012 7:11 AM To: George Herbert Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8 ... Baking in bogonity is bad. Really ??? If stack vendors had not taken the statement about 'future use' at face value and had built the stacks assuming the 240/4 was just like all the other unicast space; then someone came up with a clever idea that was incompatible with the deployed assumption such that the vast deployed base would be confused by any attempt to deploy the new clever idea, wouldn't your argument be that 'the stack vendors broke what I want by not believing the text that said future use'? Undefined means undefined, so there is no reasonable way to test the behavior being consistent with some future definition. The only thing a stack vendor can do is make sure the space is unused until it is defined. At that point they can fix future products, but there is no practical fix for the deployed base. Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software so you can make use of a handful of addresses and buy yourself a couple of years delay of the inevitable. If you can accomplish that I am sure the list would bow down to your claims that there was not enough effort put into reclamation. Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? 240/4 is only 'mild' to someone that doesn't have to pay for the changes. IPv6 does require more change, but in exchange it provides longevity that 240/4 can't. Denial is a hard thing to get over, but it is only the first stage in process of grieving. IPv4 is dead, and while the corpse is still wandering about, it will collapse soon enough. No amount of bargaining or negotiation will prevent that. Just look back to the claims in the '90s about SNA-Forever and 'Serious Business doesn't operate on research protocols' to see what is ahead. Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about. IPv6 will happen with or without the ISPs, just like IPv4 happened despite telco efforts to constrain it. The edges need functionality, and they will get it by tunneling over the ISPs if necessary, just like the original Internet deployed as a tunnel over the voice network. You can choose to be a roadblock, or choose to be part of the solution. History shows that those choosing to be part of the solution win out in the end. Tony Joe
Re: The Department of Work and Pensions, UK has an entire /8
On 20-Sep-12 14:14, Tony Hain wrote: Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. To some degree yes. In this particular case, why don't you personally go out and tell all those people globally (that have what they consider to be perfectly working machines) that they need to pay for an upgrade to a yet to be shipped version of software ... In many cases, particularly embedded devices, the vendor may have gone out of business or ceased offering software updates for that product, in which case customers would have to pay to /replace/ the products, not just upgrade them--for no benefit to themselves. Good luck with that. That's why the 240/3 idea was abandoned years ago, and nothing has changed since then. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: The Department of Work and Pensions, UK has an entire /8
On Thu, Sep 20, 2012 at 7:10 AM, Joe Maimon jmai...@ttec.com wrote: George Herbert wrote: We could have started it at a more opportune time in the past. We could also have done other things like a straight IPv4-48 or IPv4-64, without the other protocol suite foo that's delayed IPv6 rollout. Operators could have either used larger baseball bats or more participating numbers to make some IPv6 protocol design go the other way. IETF could have realized they were in Epic Fail by Too Clever territory. All of these things are water under the bridge now. We have what we have. It being amusing to grouse about mistakes of the past does not magically change the present. We have rapidly vanishing IPv4 and no 240/4, IPv6, and no time. That is reality. Pining for 240/4 fjords is not a time machine to change the past. What is not amusing is continued evidence that the lessons from this debacle have not been learned. Or that other past lessons are being forgotten. Baking in bogonity is bad. Ok, but the bogonity is baked in in two areas already; both 240/4 and IPv6. 240/4 is baked in (or out) of IPv4 on a large quantity of deployed firmware and devices, and larger quantity of local OS IPv4 stacks. The local OSes are, as a rule, upgraded on 2-3 year timelines and patched in many cases something like annually or every few months. Firmware, less so. As someone else pointed out, a lot of those devices are not under support anymore or from now defunct vendors, so a hardware replace is the fix. IPv6 was also baked out of a large quantity of deployed firmware and devices, and OS stacks. This has largely already been remedied, and people are largely aware that device firmware that's not upgradable needs replacement, so the fix is mostly in and already most of the way through happening. In both cases, a roughly 7-10 year total process in practice; in one case, we're already 5-6 years of serious effort in to it. Do you understand the difference between starting a 7, 8, 10 year process fresh from zero right now versus continuing one we're nearly done with? Predicting the (f)utility of starting multi-year efforts in the present for future benefit is self-fulfilling. No. This is a classic techie-makes-business-failure problem. You are not creating products for today's customers. You're creating products for customers who will be there when the product is ready. You're not creating a product to compete with today's products; you're competing with the products that will be out when it's done and shipping, and that come out subsequently. This is what market window is all about. Let us spin this another way. If you cannot even expect mild change such as 240/4 to become prevalent enough to be useful, on what do you base your optimism that the much larger changes IPv6 requires will? We're somewhere around 2/3 of the way through on the IPv6 changes. We haven't started a 240/4 activation project yet. We have found while doing the IPv6 that there are some glitches; a very few of them at protocol level, with so-far tolerable workarounds or adjustments in expectations. A lot of them at operational process and usage levels. A lot more of them at business / user levels. There's a difference between IPv6 doesn't work and IPv6 is not perfect. IPv6 is deployed, running nationally, represents 0.6-1.0% of active IP traffic right now to big websites depending on who you talk to (Google was 0.6% I think, Wikipedia reporting 0.8% on an internal list a couple of weeks ago, etc). It's obviously not doesn't work as it's showing functional IPv6 traffic levels that approximate those of the whole Internet 15 years ago. It's obviously not perfect. It's asserted that the operational problems are big for a number of sites, but others are making it work. We'll have to see on that. In any case, it's not 7-10 years away from working. Even if we have to respin a support protocol (DHCPv6.1, anyone?) the core protocol and most of the stacks and the routers and devices probably wouldn't need replacement. Someone who objects to current operational issues is likely to eventually (soon) just write code rather than wait for arguments to settle and the protocol wizards to pronounce. Running code trumps theory and argument. If you think you can accomplish a full 240/4 support rollout across the world's devices and infrastructure faster than we can get IPv6 running, I would suggest that you reconsider. It's an easier fix at one level only - the code in the stacks that needs changing is relatively minor. Even if the protocol and code changes were completely done tomorrow by magic, the deployment phase, all 5+ years of it, is starting at zero. IPv6 is deployed; not universally, but most of the way through. We're shaving operational issues with the protocol and support protocols off now, and dealing with deployments into slow-adopters. IPv6 is able to be operational for many people now; 240/4 would not be
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Mon, Sep 17, 2012 at 1:48 PM, Richard Brown richard.e.br...@dartware.com wrote: Another measure of the size of the IPv6 address space... Back on World IPv6 Day in June 2011, Dartware had a barbecue. (Why? Because the burgers had 128 (bacon) bits and we served IP(A) to drink :-) You can see some photos at: http://www.networkworld.com/community/blog/scenes-ipv6-day-barbecue But we came up with another interesting measure for the vastness of the IPv6 address space: If an IPv4 hamburger patty has 2^32 (4.2 billion) unique addresses in its 1/4 inch thickness, how thick would an IPv6 hamburger be (with 2^128 unique addresses)? The answer is... 53 billion light-years. Interesting. If a teeny dot of gristle at the edge of the patty is an IPv4 /28 LAN and the same LAN is /64 in IPv6, how big is IPv6 now? The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or about 10 billionths of a lightyear. 68,000 miles, a little over a quarter of the distance to the moon. That's a big burger. But not so big as you thought. By 17 orders of magnitude. In point of fact, a mere 150,000 people put together will eat all that beef in their lifetimes. But for the distribution problem, the world population could chew through it in half a day. Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. Nice burger. Om nom nom nom. 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: The Department of Work and Pensions, UK has an entire /8
In message 9b9685a4-cd22-41e9-957a-23103d2c8...@corp.arin.net, John Curran wr ites: On Sep 19, 2012, at 5:01 AM, Tim Franklin t...@pelican.org wrote: So...why do you need publicly routable IP addresses if they aren't publicly routable? =20 Because the RIRs aren't in the business of handing out publicly routable = address space. They're in the business of handing out globally unique addr= ess space - *one* of the reasons for which may be connection to the public= Internet, whatever that is at any given point in time and space. =20 RIPE are really good about making the distinction and using the latter ph= rase rather than the former. I'm not familiar enough with the correspondin= g ARIN documents to comment on the language used there. It's very clear in the ARIN region as well. From=20 the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles=20 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or= other Regional Registries are not guaranteed to be globally routable. Adding or globally announced may stop some of this in the future. FYI, /John John Curran President and CEO ARIN -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The Department of Work and Pensions, UK has an entire /8
On 20/09/2012 20:14, Tony Hain wrote: Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about. Tony, ipv4 succeeded because it was compelling enough to do so (killer apps of the time: email / news / ftp, later www instead of limited BBS's, teletext, etc), because the billing model was right for longhaul access (unmetered instead of the default expensive models at the time) and because it worked well over both LANs and WANs (unlike SNA, IPX, decnet, etc). ipv6 has none of these benefits over ipv4. The only thing in its favour is a scalable addressing model. Other than that, it's a world of pain with application level support required for everything, poor CPE connectivity, lots of ipv6-incapable hardware out in the world, higher support costs due to dual-stacking, lots of training required, roll-out costs, licensing costs (even on service provider equipment - and both vendors C and J are guilty as accused here), poor application failover mechanisms (ever tried using outlook when ipv6 connectivity is down?), etc. The reality is that no-one will seriously move to ipv6 unless the pain of address starvation substantially outweighs all these issues from a business / financial perspective. It may be happening in places in china - where there is ipv4 significant address starvation and massive growth, but in places of effectively full internet penetration and relatively plentiful ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages substantially outweigh its sole advantage. I wish I shared your optimisation that we would soon be living in an ipv6 world, but the sad reality is that its sorry state bears more than a passing resemblance to the failure of the OSI protocol stack. Nick
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Thu, Sep 20, 2012 at 4:29 PM, William Herrin b...@herrin.us wrote: The 1/4 inch patty holds all the IPv4 LANs whose IPv4 capacity I'm calling 2^28. IPv6's in principle has 2^64 LANs, so an increase of 2^36 LANs. Patty was 1/4 inch, so our IPv6 patty is 2^32 inches or about 10 billionths of a lightyear. 68,000 miles, a little over a quarter of the distance to the moon. 2^34, my bad. So you get a full moon burger out of it. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The Department of Work and Pensions, UK has an entire /8
IPv4 is dead, and while the corpse is still wandering about, it will collapse soon enough. No amount of bargaining or negotiation will prevent that. Just look back to the claims in the '90s about SNA-Forever and 'Serious Business doesn't operate on research protocols' to see what is ahead. Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about. tony, something is wrong with your mail transfer agent. it is regurgitating mail you wrote a decade ago. randy
RE: The Department of Work and Pensions, UK has an entire /8
-Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Thursday, September 20, 2012 2:37 PM To: Tony Hain Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8 On 20/09/2012 20:14, Tony Hain wrote: Once the shift starts it will only take 5 years or so before people start asking what all the IPv4 fuss was about. Tony, ipv4 succeeded because it was compelling enough to do so (killer apps of the time: email / news / ftp, later www instead of limited BBS's, teletext, etc), because the billing model was right for longhaul access (unmetered instead of the default expensive models at the time) and because it worked well over both LANs and WANs (unlike SNA, IPX, decnet, etc). ipv6 has none of these benefits over ipv4. You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user. The only thing in its favour is a scalable addressing model. Other than that, it's a world of pain with application level support required for everything, poor CPE connectivity, lots of ipv6-incapable hardware out in the world, higher support costs due to dual-stacking, lots of training required, roll-out costs, licensing costs (even on service provider equipment - and both vendors C and J are guilty as accused here), Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. The real costs are in app development and support, so crap in the middle of the network (which is only there to keep the network managers from learning something new) will be worked around. While shifting apps to IPv6 has a cost, doing that is a onetime operation vs. having to do it over and over for each app class and new wart that the network managers throw into the middle. IPv4 even with all its warts makes a reasonable global layer-2 network which IPv6 will run over just fine. (Well mostly ... I am still chasing a 20ms tunnel asymmetry which is causing all my IPv6 NTP peers to appear to be off by 10ms) poor application failover mechanisms (ever tried using outlook when ipv6 connectivity is down?), etc. Outlook fails when IPv4 service is lame (but I could have stopped at the second word). I use Outlook over IPv6 regularly, and have had more problems with exhausted IPv4 DHCP pools than I have with Outlook over IPv6 in the last 10 years. The reality is that no-one will seriously move to ipv6 unless the pain of address starvation substantially outweighs all these issues from a business / financial perspective. It may be happening in places in china - where there is ipv4 significant address starvation and massive growth, but in places of effectively full internet penetration and relatively plentiful ipv4 addresses (e.g. the US + Europe + large parts of asia), its disadvantages substantially outweigh its sole advantage. That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, then you will have a hard time making a case before the customers have started jumping ship in significant enough numbers that you will never get them back. If your time horizon is measured in decade units, you will have an easier time explaining how a 5 year roll out will alleviate costs and minimize pain down the road. Most of the press and casual observers didn't get the point of the 2003 DoD/US Fed mandates for 2008. That date was not picked because they believed they needed IPv6 in production by 2008, it was picked because they had significant new equipment purchases starting at that point that would be in production well past the point when it becomes likely those devices will find themselves in some part of the world where 'IPv6-only' is the network that got deployed. The only way you turn a ship that big is to set a hard date and require things that won't make sense to most people until much later. I wish I shared your optimisation that we would soon be living in an ipv6 world, but the sad reality is that its sorry state bears more than a passing resemblance to the failure of the OSI protocol stack. If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an
Re: IPv6 Burgers (was: IPv6 Ignorance)
In message cap-gugvaksokeqevx7ayseyqrr7g2erreaasxnwayabqpqm...@mail.gmail.com, W illiam Herrin writes: Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. 6rd can be dense as native deployment. In fact it is not hard to do so and if you are using the shared /10 just allocated or RFC 1918 between you and your customers more than once simple map all of IPv4 space does not work. RFC 5969 does NOT say you must use 32 bits and actually lots of examples where it isn't done. Nice burger. Om nom nom nom. Regards, Bill Herrin --=20 William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The Department of Work and Pensions, UK has an entire /8
On 18-Sep-12 23:11, Mike Hale wrote: this is the arin vigilante cultural view of the world. luckily, the disease does not propagate sufficiently to cross oceans. I'd love to hear the reasoning for this. Why would it be bad policy to force companies to use the resources they are assigned or give them back to the general pool? In theory, that sounds great. However, the legal basis for actually taking them back is questionable since they pre-date the RIR system, registration agreements, utilization requirements, etc. And, in practice, those who _aren't_ using their assignments have, for the most part, given them back voluntarily, so it's a moot point. Also, as in the case at hand, most of the blocks that generate complaints turn out to be, upon closer examination, actively in use but just not advertised--at least on the particular internet that the complainer is using. Hint: there is more than one internet. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: IPv6 Burgers (was: IPv6 Ignorance)
On Thu, Sep 20, 2012 at 7:50 PM, Mark Andrews ma...@isc.org wrote: In message cap-gugvaksokeqevx7ayseyqrr7g2erreaasxnwayabqpqm...@mail.gmail.com, W illiam Herrin writes: Worse, that's if we were managing IPv6 delegations the way we manage IPv4 delegations. We're not. We're using sparse allocation. And 6RD. And default customer allocations of 65,000 LANs. And other interesting stuff that drastically increases the consumption characteristics. 6rd can be dense as native deployment. In fact it is not hard to Have you heard the one about the difference between theory and practice? 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: The Department of Work and Pensions, UK has an entire /8
On 19-Sep-12 03:46, Alex Harrowell wrote: On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The enterprise networking world is just as ugly as, if not uglier than, the consumer one. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Verizon IPv6 LTE
Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth
Re: Verizon IPv6 LTE
My understanding, and experience (albeit with Android), is that all VZW LTE is IPv6-capable. I'd love to hear if Apple or VZW is at fault here, or if something weird is happening ... /TJ On Sep 20, 2012 8:28 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth
Re: Verizon IPv6 LTE
I'm also curious about this. Jared Mauch On Sep 20, 2012, at 8:26 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth
Re: Verizon IPv6 LTE
On Sep 20, 2012 5:27 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth Verizon has ipv6 everywhere they have LTE. Verizon also requires it on all their LTE devices that they sell. Your problem is likely with Apple, they have not yet supported ipv6 on the cellular interface afaik. CB
Re: Verizon IPv6 LTE
Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run On Sep 20, 2012, at 8:26 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth
Re: Verizon IPv6 LTE
On Sep 20, 2012, at 8:39 PM, Cameron Byrne cb.li...@gmail.com wrote: On Sep 20, 2012 5:27 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth Verizon has ipv6 everywhere they have LTE. Verizon also requires it on all their LTE devices that they sell. Your problem is likely with Apple, they have not yet supported ipv6 on the cellular interface afaik. Looks to work. -- snip-- Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 The World IPv6 Launch day is June 6th, 2012. Good news! Your current browser, on this computer and at this location, are expected to keep working after the Launch. [more info] Congratulations! You appear to have both IPv4 and IPv6 Internet working. If a publisher publishes to IPv6, your browser will connect using IPv6. Note: Your browser appears to prefer IPv4 over IPv6 when given the choice. This may in the future affect the accuracy of sites who guess at your location. Your DNS server (possibly run by your ISP) appears to have IPv6 Internet access. Your readiness scores 10/10 for your IPv4 stability and readiness, when publishers offer both IPv4 and IPv6 10/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only Click to see test data (Updated server side IPv6 readiness stats)
Re: Verizon IPv6 LTE
On Sep 20, 2012 5:45 PM, Jared Mauch ja...@puck.nether.net wrote: Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run Cool! That is from an ipad on vzw LTE? Ios6? CB On Sep 20, 2012, at 8:26 PM, Seth Mattinen se...@rollernet.us wrote: Does Verizon have IPv6 on their LTE network everywhere or is it limited to specific regions? I ask because I have a Verizon LTE iPad just upgraded to iOS6 (which supposedly added this capability), but it's not getting an IPv6 address on the LTE interface. Or does Verizon now need to authorize these newly capable devices as IPv6-able? ~Seth
Re: Big Temporary Networks
TJ wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Heavy reliance on broadcast for a wide range of instances where the traffic is really only destined for a single node would seem to be rather sub-optimal. It's not sub-optimal w.r.t. link bandwidth, if the link is a broadcast domain. Moreover, broadcast is no worse than all-node multicast. And, given the CATENET model of the Internet to connect broadcast domains including small number of devices by routers, over which there is no broadcast, that is a sub-optimal operation. In this thread, there is an example of such an operation to have a lot of WiFi base stations with omnidirectional antennas at full power. No protocol can be fool proof against sub-optimal operations. Masataka Ohta
Re: Verizon IPv6 LTE
On Sep 20, 2012, at 8:49 PM, Cameron Byrne cb.li...@gmail.com wrote: On Sep 20, 2012 5:45 PM, Jared Mauch ja...@puck.nether.net wrote: Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run Cool! That is from an ipad on vzw LTE? Ios6? Yes... Please don't hack or ddos it :-) I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on vzw tomorrow. Should be interesting if apple turned on their Phobos domains for App Store as v6 via akamai. I would expect a lot of traffic to shift then. - Jared
Re: Verizon IPv6 LTE
thank god for unlimited 4g on vz :) hold onto it while you can they are trying hard to kill it! On Thu, Sep 20, 2012 at 8:58 PM, Jared Mauch ja...@puck.nether.net wrote: On Sep 20, 2012, at 8:49 PM, Cameron Byrne cb.li...@gmail.com wrote: On Sep 20, 2012 5:45 PM, Jared Mauch ja...@puck.nether.net wrote: Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run Cool! That is from an ipad on vzw LTE? Ios6? Yes... Please don't hack or ddos it :-) I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on vzw tomorrow. Should be interesting if apple turned on their Phobos domains for App Store as v6 via akamai. I would expect a lot of traffic to shift then. - Jared
Re: Verizon IPv6 LTE
One other thing... When on non-v6 wifi, it appears to still be using LTE for v6... (At least according to test-ipv6.com) This could result in some unexpected usage patterns.. - Jared On Sep 20, 2012, at 8:49 PM, Cameron Byrne cb.li...@gmail.com wrote: Cool! That is from an ipad on vzw LTE? Ios6?
Re: Verizon IPv6 LTE
On 9/20/12 5:39 PM, Cameron Byrne wrote: Your problem is likely with Apple, they have not yet supported ipv6 on the cellular interface afaik. Well, that's true under iOS 5, but iOS 6 released yesterday (and assuming you have a third gen iPad with LTE) was supposed to correct that. It runs IPv6 like a champ on wifi but I was excited to install the update to finally have my first IPv6 connection that wasn't through my AS. ~Seth
Re: Verizon IPv6 LTE
Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I definitely wasn't at the office. I verified with an app called IT Tools that shows the interfaces and routing table, plus it does traceroute/ping. Maybe the nearest tower over there doesn't support IPv6? Odd. Running test-ipv6.com it passes all tests except test if your ISP's DNS server uses IPv6. ~Seth
Re: Verizon IPv6 LTE
On 9/20/12 6:33 PM, Seth Mattinen wrote: Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I definitely wasn't at the office. I verified with an app called IT Tools that shows the interfaces and routing table, plus it does traceroute/ping. Maybe the nearest tower over there doesn't support IPv6? Odd. Safari on the iPad seems to be preferring A over if a hostname has both, though. I can browse to a bracketed IPv6 address so it is working. ~Seth
Re: Verizon IPv6 LTE
Did Apple use their version of Happy Eyeballs on the iPads? ISTR they cache certain timeouts, so if IPv6 was failing before it may take awhile for it to become preferred again. /TJ On Thu, Sep 20, 2012 at 9:37 PM, Seth Mattinen se...@rollernet.us wrote: On 9/20/12 6:33 PM, Seth Mattinen wrote: Huh, so I come home and now I'm getting IPv6 from Verizon LTE. But I definitely wasn't at the office. I verified with an app called IT Tools that shows the interfaces and routing table, plus it does traceroute/ping. Maybe the nearest tower over there doesn't support IPv6? Odd. Safari on the iPad seems to be preferring A over if a hostname has both, though. I can browse to a bracketed IPv6 address so it is working. ~Seth
Re: Verizon IPv6 LTE
On 9/20/12 6:47 PM, TJ wrote: Did Apple use their version of Happy Eyeballs on the iPads? ISTR they cache certain timeouts, so if IPv6 was failing before it may take awhile for it to become preferred again. Well, I can try creating a new DNS record that never existed before and see. ~Seth
Re: The Department of Work and Pensions, UK has an entire /8
On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk step...@sprunk.org wrote: On 19-Sep-12 03:46, Alex Harrowell wrote: On the other hand, the scarcity is of *globally unique routable* addresses. You can make a case that private use of (non-RFC1918) IPv4 resources is wasteful in itself at the moment. To be provocative, what on earth is their excuse for not using IPv6 internally? By definition, an internal network that isn't announced to the public Internet doesn't have to worry about happy eyeballs, broken carrier NAT, and the like because it doesn't have to be connected to them if it doesn't want to be. A lot of the transition issues are much less problematic if you're not on the public Internet. Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The enterprise networking world is just as ugly as, if not uglier than, the consumer one. I haven't worked much on the commercial private internets, but I did work for someone who connected on the back end into numerous telco cellphone IP data networks. For all of those who argue that these applications should use 1918 space, I give you those networks, where at one point I counted literally 8 different 10.200.x/16 nets I could talk to at different partners (scarily enough, 2 of those were the same company...). And hundreds and hundreds of other space conflicts. Yes, you can NAT all of that, but if you get network issues where you need to know the phone end address and do end to end debugging on stuff, there are no curse words strong enough in the English language. -- -george william herbert george.herb...@gmail.com
Re: Verizon IPv6 LTE
On 9/20/12 6:47 PM, TJ wrote: Did Apple use their version of Happy Eyeballs on the iPads? ISTR they cache certain timeouts, so if IPv6 was failing before it may take awhile for it to become preferred again. It seems you may be correct. ~Seth
Re: Verizon IPv6 LTE
Safari is definitely preferring IPv4. In a happier note, if you tether a device via hotspot on an IOS6 iPad, the clients get native IPv6. Strangely, they get addresses out of the same /64 as the iPad's LTE interface. Anyone know how that is working? I would have thought they would use prefix-delegation, and there would be a separate routed /64. thanks, -Randy - Original Message - On 9/20/12 6:47 PM, TJ wrote: Did Apple use their version of Happy Eyeballs on the iPads? ISTR they cache certain timeouts, so if IPv6 was failing before it may take awhile for it to become preferred again. It seems you may be correct. ~Seth
Re: Verizon IPv6 LTE
On Thu, 20 Sep 2012, TJ wrote: My understanding, and experience (albeit with Android), is that all VZW LTE is IPv6-capable. I'd love to hear if Apple or VZW is at fault here, or if something weird is happening ... I don't know about Apple devices on VZW, but my Android phone definitely has IPv6 connectivity on VZW 4G LTE in Pittsburgh. jms
Re: Big Temporary Networks
Tony Hain wrote: So, a single example of IPv4 behaving in a suboptimal manner would be enough to declare IPv4 not operational? For example? Your own example --- ... that a very crowded train arrives at a station and all the smart phones of passengers try to connect to APs ... IPv4 has a train load of devices unicasting and retransmitting all the dropped packets, IPv4 merely need a broadcast ARP request and broadcast DHCP discover to be piggy backed in a single IEEE802.11ai frame reliably unicast to an AP. where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. You miss multicast storm caused by DAD. Just because you personally want IPv6 to be nothing more than IPv4 in every aspect is no reason to troll the nanog list and create confusion that causes others to delay their IPv6 deployment. Just because IPv6 is working without much problem somehow somewhere is not a valid reason to say others should use IPv6. As IP is so essential to the Internet, IP protocol must be perfect w.r.t. the scale and diversity of the Internet. IPv4 has evolved so, as the Internet evolve. IPv6 could have been so, if it were a exact copy of IPv4 save address length. But, it is not, which is why IPv6 failed on various points which are different from IPv4. Your complaints about IPv6 behavior on wifi ignore the point that IPv6 ND behavior was defined before or in parallel as wifi was defined by a different committee. The problem is ND uber Alles approach, which makes it impossible to make IP uber Alles. There will always be newer L2 technologies that arrive after an L3 protocol is defined, and the behavior of the L3 will be 'suboptimal' for the new L2. When the issue is serious enough to warrant documentation, addendum documents are issued. Because of ND uber Alles approach, the document just says IPv6 works suboptimal without solving the issue. OTOH with IPv4, the document can solve the problem by having a new adaptation mechanism much different from ARP or PPP. Masataka Ohta
Re: Verizon IPv6 LTE
On Thu, 20 Sep 2012, Randy Carpenter wrote: In a happier note, if you tether a device via hotspot on an IOS6 iPad, the clients get native IPv6. Strangely, they get addresses out of the same /64 as the iPad's LTE interface. Anyone know how that is working? I would have thought they would use prefix-delegation, and there would be a separate routed /64. Prefix delegation isn't generally available in mobile networks yet, that'll come in the next few years. It's probably using ND proxy or similar technique. https://tools.ietf.org/html/rfc6459 is a good starting point for further study, more specifically https://tools.ietf.org/html/rfc6459#section-5.3 to answer your above question. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon IPv6 LTE
Please don't hack or ddos it :-) Unfortunately, while you do get an ipv6 address, mobile terminated data doesn't work, so you don't have to worry about this. It is firewalled by Verizon. I actually tried to set up a VPN on a LTE data card using the ipv6 address since the IPV4 one is behind carrier grade NAT. I found out the hard way that was a no-go, either. One more tip: IPv6 will work over the legacy 3g network. Don't ask me much about it, but it tunnels it using eHRPD to the same IP/IPv6 headend to enable seamless EVDO/LTE handover. On Thu, Sep 20, 2012 at 6:58 PM, Jared Mauch ja...@puck.nether.net wrote: On Sep 20, 2012, at 8:49 PM, Cameron Byrne cb.li...@gmail.com wrote: On Sep 20, 2012 5:45 PM, Jared Mauch ja...@puck.nether.net wrote: Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run Cool! That is from an ipad on vzw LTE? Ios6? Yes... Please don't hack or ddos it :-) I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on vzw tomorrow. Should be interesting if apple turned on their Phobos domains for App Store as v6 via akamai. I would expect a lot of traffic to shift then. - Jared
Re: Verizon IPv6 LTE
* PC One more tip: IPv6 will work over the legacy 3g network. Don't ask me much about it, but it tunnels it using eHRPD to the same IP/IPv6 headend to enable seamless EVDO/LTE handover. Interesting. Does this happens only if you start out in LTE coverage and then roam onto EV-DO, or does IPv6 work if you connect to the network outside of LTE coverage too? I wonder if there will be similar magic provided for UMTS/LTE networks.. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Verizon IPv6 LTE
On Fri, 21 Sep 2012, Tore Anderson wrote: I wonder if there will be similar magic provided for UMTS/LTE networks.. I doubt it. The path there should be to upgrade GSM/UMTS network to release 9 and support v4v6 pdp context and then you don't need any magic at all (as far as I can tell). -- Mikael Abrahamssonemail: swm...@swm.pp.se
