Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 10/02/2011 06:15, Ricky Beam wrote: On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg nat...@atlasnetworks.us wrote: What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. That's pretty much the definition of in use. If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me. I don't think that this is a correct definition. The question should be if there is a need for a globally unique number for a device. In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. If all 22 /8 that aren't in use would be reclaimed, that would only postpone the problem by a few years, it would not solve problem that IPv4 address space is limited and we will, sooner or later, run out. Reclaiming will take a considerable amount of time and effort from everybody, I think this is better spent working on a solution that will solve the problem forever. Henk (Speaking for myself, not for my employer). -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- I confirm today what I denied yesterday.Anonymous Politician.
Re: Looking for an IPv6 naysayer...
George Bonser gbon...@seven.com writes: In other words, the broadband provider provides a single global IP to the always up CPE. That CPE does DHCP to user stations and hands out 1918 addresses and NATs them to the single global IP. Ah there is the misunderstanding. Same her in good old Europe. If you pay for it you'll get more than one public IP. I though you were talking about the CPE getting an RFC1918 address and than hand out RFC1918 addresses to the inside as well and (maybe) another instance of NAT along the way. Well yes, there are providers which are already doing this. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Is your ASN advertising v6 prefixes?
2011/2/10 Jack Bates jba...@brightok.net On 2/9/2011 8:21 PM, Fred Richards wrote: Mine is. Well? http://www.cidr-report.org/cgi-bin/as-report?as=8025view=2.0v=6 Love that tool! Jack Love that one : http://www.sixxs.net/tools/grh/dfp/all/ -- Pierre-Yves Maunier
Re: Looking for an IPv6 naysayer...
Mark Andrews ma...@isc.org writes: DS-Lite over 6rd using RFC 1918 / multi-use ISP assigned block (I'd love to be able to say class E here) provides a single NAT translation for IPv4 and public IPv6. Okay, it's 10:15 in the morning and I really want a drink know. ;-) Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: IPv6 - a noobs prespective
In article 7000830.352.1297276636748.javamail.fra...@franck-martins-macbook-pro.loc al, Franck Martin fra...@genius.com writes You missed the IPv6 hour at Nanog42: http://www.civil-tongue.net/grandx/wiki/nanog42 https://wiki.tools.isoc.org/IETF71_IPv4_Outage May be another one is needed? If you are going to debug very much (and/or undertake a dummies course) it's probably going to take more than an hour, at one of those venues - useful though the hour is for other purposes. What these meetings need is an IPV6 room, where you have several days to work through all the issues (hopefully with some help - I've seen people struggle to get IPv6 working on a Windows XP laptop, for example). Roland. - Original Message - From: Mike Lyon mike.l...@gmail.com To: Jack Bates jba...@brightok.net Cc: nanog@nanog.org Sent: Thursday, 10 February, 2011 7:30:55 AM Subject: Re: IPv6 - a noobs prespective With the recent allocation of the last existing IPv4 /8s (which now kind of puts pressure on going v6), it would be wonderful if at the next couple of NANOGs if there could be an IPv6 for dummies session or two :) -Mike On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates jba...@brightok.net wrote: -- Roland Perry
Re: Strange L2 failure
Jack Bates jba...@brightok.net writes: Hi, a little late, but just catching up the list. Has anyone seen issues with IOS where certain MACs fail? 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system I had something similar using a Catalyst 3550. Very simple setup: Host - Cat3550 - Router You could see arp-request from the host to the router and arp-replies from the router using tcpdump, but the arp-replies didn't make it to the host. No change in the interface counters on the switch either. When using a static arp-entry on the host and then ping the router you could the echo-request and echo-replies there but still no answers. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
10GBASE-T Switches
Looking for feedback/recommendations on higher density Switch’s in the 10GBASE-T arena. Preferably TOR switches if possible. Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. Any Thoughts and/or suggestions would be greatly appreciated. This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email.
Re: Looking for an IPv6 naysayer...
Jens Link li...@quux.de writes: Okay, it's 10:15 in the morning and I really want a drink know. ;-) s/know/now/ I think I'll need more coffee. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: My upstream ISP does not support IPv6
On Feb 10, 2011, at 1:10 AM, Frank Bulk wrote: I'm not sure what you mean -- once the ISP identifies CPE that works on their network, couldn't early adopters who are interested in the technology be pointed to a short list? Frank -Original Message- From: Cutler James R [mailto:james.cut...@consultant.com] Sent: Monday, February 07, 2011 5:00 PM To: NANOG list Subject: Re: My upstream ISP does not support IPv6 All this talk about CPE is wasted until folks like ATT have someone on the retail interface (store, phone, or, web) who even knows what is this IPv6 thing. Exploring this issue with DSL providers and Uverse is like that old exercise with combat boots. It feels much better when I stop. Would if att (and others) would support IPv6 (via dedicated, residential or even cellular). Where I am, all contact people I have spoken to don't have a clue. The best I got was call back late summer and we'll know something) Their residential and cellular folks couldn't even spell IPv6. Tom
Re: Too bigs are sacred, was: Re: IPv6 addressing for core network
On 10 feb 2011, at 0:26, David Freedman wrote: Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages. Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about? What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place.
Re: Looking for an IPv6 naysayer...
On 10 feb 2011, at 1:52, Jeff McAdams wrote: I've always worked in small to middle sized shops, and I have always found that I've been able to yell and scream about IPv6 (and other features) loud enough, and long enough that I get heard by someone in a decision making position for product features (usually along the lines of a product manager or so). And every time I've made the effort to do that (admittedly, not a small effort), that product or line of product has had IPv6 available for it within about a year or so (if not sooner). About 10 years ago I was involved in a project where we were looking for one or two dozen or so gigabit ethernet switches. That order would have barely broken into six figure territory. One sales engineer came around with their product and I remarked no jumboframe support? your competitors all do 9000 bytes! A week later, he was back with a newer version of the same box... with 64000-byte jumboframe support. :-)
Re: Too bigs are sacred, was: Re: IPv6 addressing for core network
Iljitsch van Beijnum wrote: On 10 feb 2011, at 0:26, David Freedman wrote: Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages. Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about? What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place. I think the point I'm making is, that I'm not, I wont accept any traffic to these backbone interfaces from outside the AS, this means no management sessions from outside the network! (and in the rare, emergency cases where something does need to get in from the outside, policy may dictate acl hole-punching to support it) In the case of people having an unreachable core (i.e MPLS hidden or RFC1918/ULA/LinkLocal), this happens already, if they decide to expose this somehow (MPLS TTL propagation, and/or allowing the ICMP out) then it is only to assist troubleshooting (not that I accept RFC1918/ULA sourced traffic from such networks at my edge , anyway), these people are doing this by design, I think thats the point I'm trying to get across, if you will never need to process TOOBIG in your design, there is no need to accept it. -- David Freedman Group Network Engineering Claranet Group
Re: My upstream ISP does not support IPv6
On Feb 10, 2011, at 1:26 AM, Owen DeLong wrote: The problem is conversations like this: ATT Customer Service: ATT uVerse, how can I help you? Customer: Yes, I have uVerse service and I'd like to get IPv6. ATT Customer Service: I pea vee what? Is this a prank call? Owen The ATT cellular folks respond... ATT: ATT Wireless. My name is and I'm here to help User: My iPhone web browser can't reach sites like ipv6.google.com via your cellular network but it can over my wifi at home. ATT: So you are having problems with your uVerse wireless connection? ... after escalating to L2 support ATT: So we will start be reseting your iPhone and then configure it for data access ...after 45 minutes... ATT: Are you sure the website is valid? Let me check that website on my desktop here Well, thats the problem! http://ipv6.google.com/ doesn't exist. I can't get to it via my desktop here at support. You need to use www instead of ipv6 and everything will be fine. Is there anything else I can help you with today?
Re: 10GBASE-T Switches
On Thu, 2011-02-10 at 09:33 +, Roberts, Brent wrote: Looking for feedback/recommendations on higher density Switch’s in the 10GBASE-T arena. Preferably TOR switches if possible. Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. Any Thoughts and/or suggestions would be greatly appreciated. Dell sell (I doubt they make it) their '8024' 24-port 10GBASE-T switch. http://dell.to/dJP1ka I've not used one myself, and it's probably not pretty, but it fits your description. Tom
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 12:15 AM, Ricky Beam wrote: On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg nat...@atlasnetworks.us wrote: What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. That's pretty much the definition of in use. If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me. In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. --Ricky This dead horse keep coming back for another beating. The purpose of a global registry of numbers is to provide a common source for unique numbers. The definition of in use by internet registries does not require appearance in your routing tables or even in the route servers. Not only that, the users may not even want or need to exchange traffic with you. As a survivor of many network consolidations due to corporate acquisitions, I have many scars from trying to get separate RFC 1918 islands to interwork properly. That is the reason that even so-called private networks need unique IP addressing. And now, since IPv6 is actually being deployed and used, there is absolutely no economic incentive to continue to fight the IPv4 addresses not in my routing table are not 'in use' battle any more. It is a waste of time and money. James R. Cutler james.cut...@consultant.com
Re: Leasing of space via non-connectivity providers
On 2/10/2011 1:49 AM, Owen DeLong wrote: Yeah, this is a sure path to having all of them say exactly that in unison. Do you want to be right? Or would you prefer to be effective? I think he wants to know which bogons will continue to be safe to use. :P Jack
Re: Looking for an IPv6 naysayer...
On Feb 9, 2011, at 6:01 PM, Jack Bates wrote: On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: Or 6rd and go native on their permanent prefix as the forklift upgrade schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. ds-lite tends to be friendlier LSN from various tests, and is native v6. DS-lite is still CGN. You may be thinking of the comparison versus NAT444 described in draft-donley-nat444-impacts (https://datatracker.ietf.org/doc/draft-donley-nat444-impacts/). But you should read the criticisms of that draft on the BEHAVE mailing list, http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and http://www.ietf.org/mail-archive/web/behave/current/msg09030.html. Cheers, -Benson
Re: Looking for an IPv6 naysayer...
On 2/9/11 10:32 PM, Owen DeLong wrote:
On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:
I disagree... I think that offering alternate name space views to the existing
{b,m}illions of v4 addressed spindles requires IPv6 reachability as well since
those will also be adding IPv6 capabilities in the next year or two.
so your claim is that to have a .cat, serving registrants currently using v4
provisioned hosting services, and end-users currently using v4 provisioned
eyeball networks, and initially address and resources (but not names) currently
extant in the com/net/org/biz/info namespaces [1], the .cat registry first has
to be v6 reachable.
My claim is that about the time these zones are rolling out, the registrants
currently using v4 provisioned hosting services and end users currently using
v4 provisioned eyeball networks will also, at least in some cases, be using
dual stack and/or v6 services.
in some cases is a poor motivation for a general
mandatory-to-implement requirement. a v6 where required (by other
market actors than icann's legal staff in marina del rey) form would
be appropriate -- but you're making a universal claim, so on we go...
inter alia, that both ends of the chain of resolution (stub resolver
on an eyeball network and mapped resource in a hosting provider rack)
may be using dual-stack fails to motivate why the authoritative name
to address resolver must be v6 reachable.
and this claim is true because the webhosting operators, primarily in
Catalonia, who have v4 now, will themselves be v6 reachable in the next year or
two ... i think this requires either the existing hosting operators abandon
vhosting as a service model or abandon their existing v4 allocations.
You do not have to abandon v4 to deploy v6. That's an absurd claim.
yet it is the claim you are making. the resource must be v6 reachable,
and you're not offering arbitrary capriciousness of some evangelically
unbalanced lawyers in a high-rise in marina del ray as a rational, so
you must have a material necessity rational.
now rinse and repeat for .nyc. the claim is somehow that the market for hosting
operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol,
... and their downstream resellers, which is statistically likely to have 51%
of all .nyc registrations), and/or (your choice) the eyeball network operators
for the tri-state area, are going to either abandon vhosting as a service model
or abandon their existing v4 allocations ...
Again, the need for v6 is not predicated on the abandonment of v4.
you've managed to elide responding to both (a) an actual new (in 2005)
registry, with existing v4 provisioning, and (b) a pending new (in
2012) registry, again with existing v4 provisioning.
i look forward to learning why .cat failed for lack of v6, and why
.nyc will fail, for lack of v6, in a sentence that doesn't contain a
reference to lawyers in a high-rise in marina del ray.
where the v6 ab initio convinces me some is the area i currently work on --
developing economies. nigeria is a good example, fewer than 10^^5 computers, a
population of 15x10^^7, and cell phone penetration rate approaching 1 in 3.
even so, the number of v6 prefixes in afnic's inventory of allocations is ...
very small ... for all of africa as a region.
I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are
saying here.
try looking beyond what the iana has allocated to a rir, and look at
what prefixes the rir has allocated. alternatively, something along
the lines of trivial pursuits, name the data centers and/or eyeball
networks in africa in which v6 was deployed in q42010.
It's not that I think you only serve the future. It's that we think you are
failing to recognize that IPv6 is now
and that what is IPv4 today will be at least dual-stack tomorrow.
if the window for applications opens 4 months after icann-41 (amman, jordan),
in q42011, then delegations will occur as soon as q32012.
Yes.
is your claim that registry operators where v6 is _sparce_, and/or where v6
eyeball networks are _sparce_, two years from today, are properly failed for
technical reasons, two years from today, for lack of v6 capability?
I'm not sure what you mean by _sparce_.
See africa, v6 availability, above.
My claim is that by 4q2012, I expect we will see much much wider IPv6
deployment and potentially eyeball
networks that are primarily or exclusively IPv6 with at best limited or
degraded IPv4 support through multiple
layers of NAT.
now that is an interesting claim. suppose it is true and there is at
best limited or degraded IPv4 on eyeball networks. why is a once per
session trip up and down the chain of resolution sufficient to
motivate anything?
further, why do you suppose that new gtld registries, but not existing
gtld registries, have an affirmative duty to be v6 reachable from
resolvers on v6-only eyeball networks?
what is the
Re: 10GBASE-T Switches
On Thu, Feb 10, 2011 at 09:33:50AM +, Roberts, Brent wrote: Looking for feedback/recommendations on higher density Switch’s in the 10GBASE-T arena. Preferably TOR switches if possible. Minimum 16 ports usable for Rack Server connectivity + Uplinks to Collapsed Twin Distro/Core setup. Found the Arista 7X00 family to have the density I am looking for but others of similar spec would be appreciated. Any Thoughts and/or suggestions would be greatly appreciated. Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Need to buy SFP+ modules or use direct-attach SFP+ cables though.
Re: 10GBASE-T Switches
Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Need to buy SFP+ modules or use direct-attach SFP+ cables though. And is now shipping with a model that can stack and/or join a EX4200 VC stack. It's either EX4500-40F-VC1-BF or EX4500-40F-VC1-FB depending on whether you want Front-to-Back or Back-to-Front airflow. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges.
Re: Ipv6 addressing for Core network
HI Geroge, Thanks for the input. Appreciate some more info wrt TCAM usuage if possible. Another thought, I agree ip schema is individual preference, but I want to know the best practise (vague term best practice). Personally even I am in favor of /64 p-t-p. Regards, Vikas On Wed, Feb 9, 2011 at 12:11 PM, George Bonser gbon...@seven.com wrote: I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below - 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet 3- Use Unique local ipv6 address 4- Use Public Ipv6 with /64 Also I am interested to understand the impact on TCAM ... Regards, Vikas I would use a /64 with ND turned off and static neighbors configured. TCAM impact will depend on vendor. Some vendors give you the option of storing the first 64 bits of a V6 IP or the entire address. Using a /64 means your CAM usage might be less depending on your vendor. If the addresses on the point-to-point links never accept or source direct traffic to/from outside your net, you can use whatever you want on them. ULA might be ok there. I am using public IPs but I filter traffic destined for them at the edge but to each their own choice. But if you use ULA you aren't going to be able to ping anything outside your net if you source the pings from the ULA interface. Just something to keep in mind. What you are asking is a matter of individual preference.
Re: Leasing of space via non-connectivity providers
Date: Thu, 10 Feb 2011 01:13:49 -0600 From: Jimmy Hess mysi...@gmail.com With them not requiring a /8 in the first place (after CIDR); one begins to wonder how much of their /8 allocations they actually touched in any meaningful way. i expect that after final depletion there will be some paid transfers from some of the large legacy blocks. i have no personal knowledge of HP's situation or indeed any /8 holder's situation, but if the market value of these transfers ever meaningfully exceeds the renumbering penalty then their beancounters will find a way to get it done. that's the way of the world. i can imagine this NOT happening. most businesses are looking for long term strategic investments not quick-fix short-term band-aids. a buddy loaned me a macbook after my thinkpad was stolen, and i loved it, and i went down to the apple store to buy one of my own just like my buddy's loaner and they said we only sell that with the chicklet keyboard now and i tried it and hated it. i could buy my buddy's laptop but without applecare and without the ability to replace it if it's lost/stolen i'm not willing to make that investment. so for me it's another thinkpad. so if a company who traditionally needs a lot of IPv4 to grow their network knows that they can get one last quarter's worth of it from some legacy /8 holder, they might do some kind of paid transfer, or they might just hum some dire straits and keep moving with their ipv6 plans. Now it's past last call for alcohol Past recall has been here and gone The landlord finally paid us all The satin jazzmen have put away their horns And we're standing outside of this wonderland Looking so bereaved and so bereft Like a Bowery bum when he finally understands The bottle's empty and there's nothing left (Your Latest Trick) for some IPv4 based businesses a /8 would be more than a lifetime supply, but there's a value ceiling imposed by the space other people can get. (when everybody else has made other arrangements, the relative value of one's own hoard decreases.) Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned. The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs Hell no In any case, the registry should ASK and publish an indication for each legacy /8 at least. So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for. The community should also know which /8 legacy holders say Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using. this gets into the controversial topic of an RIR's standing with respect to legacy space, and i'll leave that to the lawyers to talk about. but as owen and others have said, if a legacy holder were approached in this way knowing that their answer was going to be on the public record in the way, they probably would see no incentive at all to answer the question.
Re: My upstream ISP does not support IPv6
On Feb 10, 2011, at 10:28 AM, Cameron Byrne wrote: T-mobile USA has a nationwide ipv6 beta. You can google it. Regarding iphone, its more an iPhone issue than anything else Nope its ATT. My iPhone works fine on IPv6. I connect wifi at home and can go anywhere but on on ATT wireless. Tom
Re: Too bigs are sacred, was: Re: IPv6 addressing for core network
On Thu, 10 Feb 2011 12:15:52 GMT, David Freedman said: these people are doing this by design, I think thats the point I'm trying to get across, if you will never need to process TOOBIG in your design, there is no need to accept it. And how many networks break PMTUD because their design says they never need to deal with ICMP so there's no need to accept it, or break DNS because TCP/53 is only used for zone transfers that should never happen, or... pgppAX6ykO5Gn.pgp Description: PGP signature
Re: My upstream ISP does not support IPv6
On 2/10/11 7:42 AM, TR Shaw wrote: On Feb 10, 2011, at 10:28 AM, Cameron Byrne wrote: T-mobile USA has a nationwide ipv6 beta. You can google it. Regarding iphone, its more an iPhone issue than anything else Nope its ATT. My iPhone works fine on IPv6. I connect wifi at home and can go anywhere but on on ATT wireless. Your iphone supports v6 in the operating system that runs the user facing side of it. It's baseband radio controller (with a seperate processor and operating system) does not support v6 and thus the cellular side of the device cannot. Tom
Re: Leasing of space via non-connectivity providers
On Thu, Feb 10, 2011 at 01:13:49AM -0600, Jimmy Hess wrote: Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned. And then they (read: their attorneys) fire back a okay, who are you, and why do you have the right to ask us this question? Or they cheerfully engage in some vigorous handwaving. Most of us living in a dual stack world really do not need any more prefixes advertised, so cutting a bunch of discrete /22s out of a /8 is not helpful. The only people this benefits are the very few that might get some of the space. Even in the best possible situation (an entire /8 returned,) which they'd be under NO obligation to consider doing -- it'd last a few weeks. Under your scenario, you might scrounge together enough /22s to last an RIR a couple of days. Then what? That's an awful lot of pain for not much benefit. Can we move on and stop trying to squeeze prefixes from legacy holders? What's done is done. --msa
Re: Looking for an IPv6 naysayer...
On 2/10/2011 8:36 AM, Benson Schliesser wrote: DS-lite is still CGN. It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. Jack
Re: Failure modes: NAT vs SPI
On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: 1.Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds which is 213,503,982,334 days or 584,542,000 years. I would posit that since most networks cannot absorb a 1,000 pps attack even without the deleterious effect of incomplete ND on the router, no network has yet had even a complete /64 scanned. IPv6 simply hasn't been around that long. Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds?
Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 9:53 AM, Jack Bates wrote: On 2/10/2011 8:36 AM, Benson Schliesser wrote: DS-lite is still CGN. It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 guarantees you have IPv4 connectivity. As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate. In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. Cheers, -Benson
Re: Looking for an IPv6 naysayer...
On 2/10/2011 10:05 AM, Benson Schliesser wrote: DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 guarantees you have IPv4 connectivity. Who in their right mind would feed IPv6 to a CPE, deploy a CPE that supports DS-Lite, and NOT give out prefixes? In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. To even determine your public IP address, you must ask someone on the other side of the NAT, this applies also when you are doing udp hole punches. So what happens when you try and talk to you neighbor? Who's going to tell you what you need to know between your NAT and the providers NAT? This is one way that NAT444 breaks more than NAT44 (even in LSN configurations) And yes, I find that neighbors do like to play with one another, and most LSNs don't support hair pinning translations between customers (most NAT in general won't support that). Jack
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/9/2011 9:15 PM, Ricky Beam wrote: On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg nat...@atlasnetworks.us wrote: What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. That's pretty much the definition of in use. If they don't appear in the global routing table, then they aren't being used. There is no one universal global routing table. They probably appear in someone's routing table, somewhere... just not yours. If Cogent stops peering with you (I picked them, because that's not out of the question) and you stop seeing all their downstream routes, did those addresses suddenly become available for reassignment? I cannot send traffic to them; they cannot send traffic to me. That's true of almost all addresses these days, what with firewalls and all. In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. How many days do you think a single /8 lasts at current assignment rates? How would ARIN/ICANN go about reclaiming addresses that someone believes they are using but that you don't think are in use? Matthew Kaufman
Comcast BGP issue?
Not quite sure what the issue is, but I suspect Comcast announcements are not quite right? Trying to get from Verizon Business to a Comcast address in NH (on 75.15.64.0/18), and it's going through San Jose. Anyone else having similar issues or suggestions? Opened a ticket with Comcast, but they want to check the cable modem (sigh) 6 6 ms 6 ms 6 ms 0.so-3-2-0.XL3.BOS4.ALTER.NET [152.63.22.178] 713 ms14 ms13 ms 0.xe-6-1-2.XL3.NYC4.ALTER.NET [152.63.0.166] 814 ms46 ms13 ms 0.ae3.BR3.NYC4.ALTER.NET [152.63.16.181] 914 ms14 ms13 ms te-7-0-0.edge2.NewYork2.level3.net [4.68.110.69] 1013 ms13 ms14 ms vlan52.ebr2.NewYork2.Level3.net [4.69.138.254] 1114 ms14 ms14 ms ae-6-6.ebr2.NewYork1.Level3.net [4.69.141.21] 1285 ms88 ms90 ms ae-2-2.ebr4.SanJose1.Level3.net [4.69.135.185] 1385 ms85 ms89 ms ae-94-94.csw4.SanJose1.Level3.net [4.69.134.254] 1483 ms83 ms84 ms ae-4-99.edge1.SanJose1.Level3.net [4.68.18.206] 1597 ms95 ms95 ms COMCAST-IP.edge1.SanJose1.Level3.net [4.79.43.134] 16 125 ms 125 ms 124 ms pos-0-14-0-0-cr01.denver.co.ibone.comcast.net [68.86.85.129] 17 135 ms 129 ms 125 ms pos-0-14-0-0-cr01.chicago.il.ibone.comcast.net [68.86.85.117] 18 122 ms 121 ms 121 ms pos-1-15-0-0-ar01.woburn.ma.boston.comcast.net [68.86.93.122] 19 128 ms 127 ms 127 ms po-66-ur02.manchester.nh.boston.comcast.net [68.85.69.170] 20 123 ms 121 ms 121 ms 68.85.161.226 21 116 ms 118 ms 119 ms x-x-x-x-newengland.hfc.comcastbusiness.net [75.150.80.x] -Keith
RE: Comcast BGP issue?
Sorry, my typo. The Net is 75.150.64.0/18 -Original Message- From: Wallace Keith Sent: Thursday, February 10, 2011 12:20 PM To: nanog@nanog.org Subject: Comcast BGP issue? Not quite sure what the issue is, but I suspect Comcast announcements are not quite right? Trying to get from Verizon Business to a Comcast address in NH (on 75.15.64.0/18), and it's going through San Jose. Anyone else having similar issues or suggestions? Opened a ticket with Comcast, but they want to check the cable modem (sigh) 6 6 ms 6 ms 6 ms 0.so-3-2-0.XL3.BOS4.ALTER.NET [152.63.22.178] 713 ms14 ms13 ms 0.xe-6-1-2.XL3.NYC4.ALTER.NET [152.63.0.166] 814 ms46 ms13 ms 0.ae3.BR3.NYC4.ALTER.NET [152.63.16.181] 914 ms14 ms13 ms te-7-0-0.edge2.NewYork2.level3.net [4.68.110.69] 1013 ms13 ms14 ms vlan52.ebr2.NewYork2.Level3.net [4.69.138.254] 1114 ms14 ms14 ms ae-6-6.ebr2.NewYork1.Level3.net [4.69.141.21] 1285 ms88 ms90 ms ae-2-2.ebr4.SanJose1.Level3.net [4.69.135.185] 1385 ms85 ms89 ms ae-94-94.csw4.SanJose1.Level3.net [4.69.134.254] 1483 ms83 ms84 ms ae-4-99.edge1.SanJose1.Level3.net [4.68.18.206] 1597 ms95 ms95 ms COMCAST-IP.edge1.SanJose1.Level3.net [4.79.43.134] 16 125 ms 125 ms 124 ms pos-0-14-0-0-cr01.denver.co.ibone.comcast.net [68.86.85.129] 17 135 ms 129 ms 125 ms pos-0-14-0-0-cr01.chicago.il.ibone.comcast.net [68.86.85.117] 18 122 ms 121 ms 121 ms pos-1-15-0-0-ar01.woburn.ma.boston.comcast.net [68.86.93.122] 19 128 ms 127 ms 127 ms po-66-ur02.manchester.nh.boston.comcast.net [68.85.69.170] 20 123 ms 121 ms 121 ms 68.85.161.226 21 116 ms 118 ms 119 ms x-x-x-x-newengland.hfc.comcastbusiness.net [75.150.80.x] -Keith
Self-referential whois queries
I'm noticing an increase in getting query rate exceeded at whois services that might be connected to a symptom described by ARIN at NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois record of their own IP address. Are there any clues of what is causing this ? Rubens
Re: 10GBASE-T Switches
On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote: Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. DHCPv6). Affects whole EX-series and current plan is to fix it sometime end of year (Q4 release). If you use IPv4 multicast and need IGMP snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that might be a showstopper for now and the VLANs where IGMP snooping is enabled. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
ARIN and IPv6 Requests
Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: 10GBASE-T Switches
On Thu, Feb 10, 2011 at 08:33:43PM +0100, Daniel Roesen wrote: On Thu, Feb 10, 2011 at 10:05:54AM -0500, Chuck Anderson wrote: Juniper EX4500 has 40 fixed SFP/SFP+ ports plus 2 uplink modules that can contain 4 SFP/SFP+ ports each for a total of 48 10GBASE-X ports. Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. DHCPv6). Affects whole EX-series and current plan is to fix it sometime end of year (Q4 release). If you use IPv4 multicast and need IGMP snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that might be a showstopper for now and the VLANs where IGMP snooping is enabled. I should add that we're quite happy with the EX4500 on the features it has (want QinQ yesterday, prettypretty please). No datacenter usage though. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
re: ARIN and IPv6 Requests
We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: IPv6 - a noobs prespective
On Wed, Feb 09, 2011 at 03:43:35PM -0500, Jared Mauch wrote: Jack (hates all routers equally, doesn't matter who makes it) Welcome to the life of being a network operator. :) That's called carrier grade these days by all those vendors! :-) SCNR, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
re: ARIN and IPv6 Requests
Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: 10GBASE-T Switches
On Thu, 2011-02-10 at 20:33 +0100, Daniel Roesen wrote: Be aware, that IGMP snooping breaks some(!) IPv6 multicast (e.g. DHCPv6). Affects whole EX-series and current plan is to fix it sometime end of year (Q4 release). If you use IPv4 multicast and need IGMP snooping to prevent flooding and plan to use e.g. stateful DHCPv6, that might be a showstopper for now and the VLANs where IGMP snooping is enabled. Not disagreeing, I've never met this device, just curious about the problem and wondering if it is a generic class of problem. Is this device supposed to be IPv6-capable? If so, IGMP snooping and MLD snooping should be able to coexist, I'd have thought. In fact, it will be a major blow for the future of dual-stacking if they can't. So is the problem of which you speak just a bug, or is it an artifact of the switch not being IPv6 capable and so limiting broadcasts at the ethernet level to IGMP-discovered listeners only, ignoring IPv6 multicast listeners? Or something :-) Also. why does it only affect DHCPv6? Or was that just an example of a service that would be affected by the problem? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
box.net network engineer
Can someone with the box.net engineering group email me off list. I have a peering issue with you guys at any2 in socal. Thanks, Drew
Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 7:00 AM, Eric Brunner-Williams wrote:
On 2/9/11 10:32 PM, Owen DeLong wrote:
On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:
I disagree... I think that offering alternate name space views to the
existing {b,m}illions of v4 addressed spindles requires IPv6 reachability
as well since those will also be adding IPv6 capabilities in the next year
or two.
so your claim is that to have a .cat, serving registrants currently using
v4 provisioned hosting services, and end-users currently using v4
provisioned eyeball networks, and initially address and resources (but not
names) currently extant in the com/net/org/biz/info namespaces [1], the
.cat registry first has to be v6 reachable.
My claim is that about the time these zones are rolling out, the registrants
currently using v4 provisioned hosting services and end users currently
using v4 provisioned eyeball networks will also, at least in some cases, be
using dual stack and/or v6 services.
in some cases is a poor motivation for a general mandatory-to-implement
requirement. a v6 where required (by other market actors than icann's legal
staff in marina del rey) form would be appropriate -- but you're making a
universal claim, so on we go...
I said at least in some cases. Since we know that it will be a monotonically
increasing set of some cases which will rapidly grow to
a very high fraction of some cases, yes, it is a good motivation for a
general mandatory-to-implement requirement.
inter alia, that both ends of the chain of resolution (stub resolver on an
eyeball network and mapped resource in a hosting provider rack) may be using
dual-stack fails to motivate why the authoritative name to address resolver
must be v6 reachable.
We can agree to disagree about this.
and this claim is true because the webhosting operators, primarily in
Catalonia, who have v4 now, will themselves be v6 reachable in the next
year or two ... i think this requires either the existing hosting operators
abandon vhosting as a service model or abandon their existing v4
allocations.
You do not have to abandon v4 to deploy v6. That's an absurd claim.
yet it is the claim you are making. the resource must be v6 reachable, and
you're not offering arbitrary capriciousness of some evangelically unbalanced
lawyers in a high-rise in marina del ray as a rational, so you must have a
material necessity rational.
No, it is not. I am claiming that you need to have IPv6 capabilities on
critical internet infrastructure because:
+ The internet is moving to IPv6.
+ We will be out of free IPv4 addresses by the time these
services are being deployed.
+ A monotonically increasing number of clients will have no or
limited/degraded IPv4 access at or soon after deployment
of these new GTLDs.
now rinse and repeat for .nyc. the claim is somehow that the market for
hosting operators (ok, the hosting lines of business of godaddy, tucows,
enom, netsol, ... and their downstream resellers, which is statistically
likely to have 51% of all .nyc registrations), and/or (your choice) the
eyeball network operators for the tri-state area, are going to either
abandon vhosting as a service model or abandon their existing v4
allocations ...
Again, the need for v6 is not predicated on the abandonment of v4.
you've managed to elide responding to both (a) an actual new (in 2005)
registry, with existing v4 provisioning, and (b) a pending new (in 2012)
registry, again with existing v4 provisioning.
i look forward to learning why .cat failed for lack of v6, and why .nyc will
fail, for lack of v6, in a sentence that doesn't contain a reference to
lawyers in a high-rise in marina del ray.
I never claimed that .cat failed because of lack of IPv6 as I have no first
hand knowledge of the failure of .cat.
I never claimed that .nyc would fail because of lack of IPv6.
I don't know whether either of those claims is true. If either claim is true,
then, certainly, it would be evidence that we need IPv6 for new deployments of
critical infrastructure that it is a valid requirement for new GTLDs. However,
even if both claims are false, it does not eliminate the need for new
GTLDs to provide support for IPV6.
There are no lawyers in Marina Del Rey in these statements:
+ The internet is moving to IPv6.
+ We will be out of free IPv4 addresses by the time these
services are being deployed.
+ A monotonically increasing number of clients will have no or
limited/degraded IPv4 access at or soon after deployment
of these new GTLDs.
+ In a world where there are IPv4 only, IPv4/IPv6 dual stack and
IPv6 only hosts, critical infrastructure such as GTLD
services should be required to be dual-stack.
where the v6 ab initio convinces me some is the area i currently work
Re: Self-referential whois queries
On Thu, 10 Feb 2011 17:27:26 -0200 Rubens Kuhl rube...@gmail.com wrote: I'm noticing an increase in getting query rate exceeded at whois services that might be connected to a symptom described by ARIN at NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois record of their own IP address. Are there any clues of what is causing this ? Some spam bots do these automated self-referential queries, but if you are seeing those rate exceeded messages when you perform queries from your client, you may simply be probably bumping up against a limit for the source host or network in question. John
Re: ARIN and IPv6 Requests
It also looks like there isn't a policy for orgs with multiple multihomed sites to get a /48 per site. Is there an exception policy somewhere? On Thu, Feb 10, 2011 at 12:50 PM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: ARIN and IPv6 Requests
Don't remember about the v4 part, but 3 years ago they issued me a /48, specifically for my first site and indicated that a block was reserved for additional sites. I can probably dig that up. Sent from my iPad On Feb 10, 2011, at 12:18 PM, Jason Iannone jason.iann...@gmail.com wrote: It also looks like there isn't a policy for orgs with multiple multihomed sites to get a /48 per site. Is there an exception policy somewhere? On Thu, Feb 10, 2011 at 12:50 PM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: 10GBASE-T Switches
Hi, On Fri, Feb 11, 2011 at 06:52:07AM +1100, Karl Auer wrote: Not disagreeing, I've never met this device, just curious about the problem and wondering if it is a generic class of problem. Is this device supposed to be IPv6-capable? We're using EX switches currently only in L2-only roles, cannot comment on L3. If so, IGMP snooping and MLD snooping should be able to coexist, I'd have thought. MLD snooping wasn't enabled (EX4500 doesn't even support it yet) so that's no factor. Expected behaviour would be to flood any IPv6 multicast frames to all ports in a VLAN. We've found the bug on EX3200-24T btw. but JTAC confirms it affects all EX series. So is the problem of which you speak just a bug, or is it an artifact of the switch not being IPv6 capable and so limiting broadcasts at the ethernet level to IGMP-discovered listeners only, ignoring IPv6 multicast listeners? Or something :-) Also. why does it only affect DHCPv6? Or was that just an example of a service that would be affected by the problem? Example of a frame (DHCPv6 SOLICIT) which is not being passed with IGMP snooping enabled: 00:1a:64:99:0f:5c 33:33:00:01:00:02, ethertype 802.1Q (0x8100), length 118: vlan 633, p 0, ethertype IPv6, (hlim 1, next-header UDP (17) payload length: 60) fe80::21a:64ff:fe99:f5c.dhcpv6-client ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=be0a2d (client-ID hwaddr/time type 1 time 345579243 001a64990f5c) (option-request DNS DNS-name) (elapsed-time 725) (IA_NA IAID:1687752540 T1:3600 T2:5400)) L3/L2 destination address is all-dhcpv6-agents. IPv6 RA (destination all nodes) are being passed just fine, e.g.: 20:24:35.480395 00:26:cb:d5:8b:d9 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::226:cbff:fed5:8bd9 ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32 My guess is that L2 filters aren't being properly handled by the IGMP snooping feature - not permitting 33:33:*, but e.g. only 33:33:00:00:00:* or so. We didn't poke around to find out exactly which multicast destination MACs do work and which don't. What surprises me, that this hasn't come up in enterprise LAN type of testing IGMP+MLDv2 snooping I'd consider a must there, and DHCPv6 a basic requirement in enterprise IPv6 deployments. PR/456700 Looks like that bug will see its second birthday in summer. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Self-referential whois queries
I'm noticing an increase in getting query rate exceeded at whois services that might be connected to a symptom described by ARIN at NANOG 48/ARIN XXV and ARIN XXVI where machines ask for the whois record of their own IP address. Are there any clues of what is causing this ? Some spam bots do these automated self-referential queries, but if you are seeing those rate exceeded messages when you perform queries from your client, you may simply be probably bumping up against a limit for the source host or network in question. The ceil seems to be at the joint whois chain, where a RIR can ask another RIR or NIR about an IP. RIRs/NIRs answering such queries with It's you! or Self-referential queries not allowed would be too harsh or a reasonable approach ? Rubens
Re: ARIN and IPv6 Requests
On Thu, Feb 10, 2011 at 2:38 PM, adw...@dstsystems.com wrote: Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. Hi Adam, I think it's a basic who are you and why are you speaking to us? question. If ARIN already knows you from previous registration activity (question 11) then you skip questions 13 and 14 (list IPv4 usage). Kind of like: why does a cop ask for your vehicle registration? He's already plugged your license plate into his computer, so he knows everything that's on the card. It's a spot check, an opportunity to see that something is amiss, requiring a closer look. 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: Failure modes: NAT vs SPI
On Feb 10, 2011, at 7:53 AM, Lamar Owen wrote: On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds which is 213,503,982,334 days or 584,542,000 years. I would posit that since most networks cannot absorb a 1,000 pps attack even without the deleterious effect of incomplete ND on the router, no network has yet had even a complete /64 scanned. IPv6 simply hasn't been around that long. Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds? The point is that you DOS the network on traffic before you can usefully scan it. A 600 million node botnet scanning a /64 on a gigabit ethernet can still only successfully inject ~1,000,000 PPS or less. Even if we assum 1,000,000 pps success rate, you've only reduced the scan time to 584,542 years. Even if you're somehow able to get 600 million nodes to successfully inject 1,000,000,000 packets per second (an unachievable number in any present day technology) you still need 584 years to scan a single /64 subnet. Owen
Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 8:05 AM, Benson Schliesser wrote: On Feb 10, 2011, at 9:53 AM, Jack Bates wrote: On 2/10/2011 8:36 AM, Benson Schliesser wrote: DS-lite is still CGN. It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion. DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 guarantees you have IPv4 connectivity. As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate. I think that at the point where you go to NAT444 instead of tunneling the IPv4, it's Dual-Stack, but, not Dual-Stack-Lite. In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private-public-private scenario will break in a private-private2-public-private2-private scenario. There are technologies and applications which depend on this. (I believe, among others, that's how many of the p2p systems work, no?) Owen
RE: Looking for an IPv6 naysayer...
From: William Herrin [mailto:b...@herrin.us] * Carrier NAT... I spend most of my days fighting with carriers to actually carry bits from point A to point B like they're paid to do. I'm sick and tired of them blaming CPE for circuit bounces and outages that are magically fixed without us doing anything to CPE. I have absolutely ZERO confidence that the carriers can implement NAT on a global scale such that it works and actually provides decent customer service. (realizing that this broad characterization is probably unfair to many smaller carriers who actually give a crap; my daily pain is generally caused by the Tier 1 guys)
NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 10, 2011, at 2:58 PM, Owen DeLong wrote: In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private-public-private scenario will break in a private-private2-public-private2-private scenario. There are technologies and applications which depend on this. (I believe, among others, that's how many of the p2p systems work, no?) This is an oft-repeated rumor, but as I stated in my recent message: the evidence doesn't support the theory. NAT traversal architectures that leverage public rendezvous such as STUN, etc, should continue to work and testing demonstrates this. The tiering of NAT does mean that neighborhood-local traffic must traverse the CGN, which is sub-optimal but not broken. Dynamic control protocols like UPNP are the only source of problems I'm aware of. Frequently, the solution for a given app is as simple as turning off UPNP. But in the near future, PCP will replace and/or augment UPNP and is more scalable. If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. We've known this for a long time. Cheers, -Benson
Re: Looking for an IPv6 naysayer...
On Wed, Feb 9, 2011 at 6:11 PM, Fred Richards fr...@geexology.org wrote: On Wed, Feb 9, 2011 at 6:47 PM, George Bonser gbon...@seven.com wrote: I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. One huge reason to adopt ipv6. Any of the ones I've used at home do provide global IPv4s to the home networks. I'm kinda selective, though. -- -george william herbert george.herb...@gmail.com
BCP38 considerations in IPv6
Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Ryan
Re: Looking for an IPv6 naysayer...
On 2/10/2011 3:19 PM, George Herbert wrote: On Wed, Feb 9, 2011 at 6:11 PM, Fred Richardsfr...@geexology.org wrote: On Wed, Feb 9, 2011 at 6:47 PM, George Bonsergbon...@seven.com wrote: I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. One huge reason to adopt ipv6. Maybe Roku will add the ipv6 tunnel endpoint channel next? Seems like an opportunity? Ken Any of the ones I've used at home do provide global IPv4s to the home networks. I'm kinda selective, though. -- Ken Anderson Pacific Internet - http://www.pacific.net
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, 10 Feb 2011 01:35:42 -0500, Matthew Moyle-Croft m...@internode.com.au wrote: Because it is a waste of time and money. That's an assertion I've heard, but has anyone quantified it? ... Not that I've ever seen. All the bitching I've seen here and elsewhere boils down to it being more involved than sending an email, so they won't bother. To be fair, it *is* a lot more work than sending an email. For starters, just finding out *who* to email. Many companies that were given assignments have been sold or went out of business. Determining the proper holder can be as much work as getting the space back. Given the current state of affairs, getting any legacy holders to hand over the space is not going to happen. That space is now worth more than anti-matter. Had they started the process a deacde ago instead of complaining that it's too much work, not worth it, etc., etc., then some of it might have been reclaimed by now. (and at current ARIN rates, a /8 is worth ~1.2mil/yr. on the open market, it's worth much more than that. esp. since legacy holders don't pay ANYTHING for it.) --Ricky
Re: BCP38 considerations in IPv6
In message acd7c570039e58b67bbf64e467f4b12b@192.168.152.50, Ryan Rawdon writes : Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Ryan You should definitely make sure you block ULA prefixes leaving your site by default. e.g. add unreach admin all from any to fc00::/7 via gif0 add unreach admin all from fc00::/7 to any via gif0 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: BCP38 considerations in IPv6
On 10 feb 2011, at 22:34, Ryan Rawdon wrote: What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? There's a lot of language in the RFCs about this type of addresses not being forwarded by routers, so filtering shouldn't be necessary. I know that Cisco lets neighbor discovery through before the implicit deny is applied, so specifically allowing link locals for neighbor discovery isn't necessary either. (I would assume other vendors do the same, but it's of course a good idea to check.) The only time you have to be careful is when you do a deny all, because you need neighbor discovery unless you use static neighbor cache entries. ND also uses multicast, so you need to let that through as appropriate, too.
Re: BCP38 considerations in IPv6
On Thu, 10 Feb 2011, Ryan Rawdon wrote: What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? That's a consideration, and one other candidate which has already been welcomed to my black-hole server: 2001:DB8::/32. I'll leave that as an exercise to everyone to see who's block that is. :-) wfms
Re: ARIN and IPv6 Requests
Some policies allow you to use your IPv4 usage as justification of your need for IPv6. If you are applying under one of those policies, you need to fill in that information. If you are applying under a different qualification criteria, I believe you can leave that section blank. Owen On Feb 10, 2011, at 11:50 AM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: ARIN and IPv6 Requests
From the NRPM: 6.11. IPv6 Multiple Discrete Networks Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: The organization shall be a single entity and not a consortium of smaller independent entities. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: Regulatory restrictions for data transmission, Geographic distance and diversity between networks, Autonomous multihomed discrete networks. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. Requests for additional space: Organization must specify on the application which discreet network(s) the request applies to Each network will be judged against the existing utilization criteria specified in 6.5.2 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy If that doesn't meet your need, please contact me off list with more information. Owen On Feb 10, 2011, at 12:18 PM, Jason Iannone wrote: It also looks like there isn't a policy for orgs with multiple multihomed sites to get a /48 per site. Is there an exception policy somewhere? On Thu, Feb 10, 2011 at 12:50 PM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: ARIN and IPv6 Requests
But how is it relevant? Ever? It's like a bank asking you to justify your need for a loan by asking you how many apples you can pick in an hour. -- Adam Webb From: Owen DeLong o...@delong.com To: adw...@dstsystems.com Cc: nanog@nanog.org Date: 02/10/2011 04:10 PM Subject: Re: ARIN and IPv6 Requests Some policies allow you to use your IPv4 usage as justification of your need for IPv6. If you are applying under one of those policies, you need to fill in that information. If you are applying under a different qualification criteria, I believe you can leave that section blank. Owen On Feb 10, 2011, at 11:50 AM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: Is your ASN advertising v6 prefixes?
On Wed, Feb 9, 2011 at 10:55 PM, Jack Bates jba...@brightok.net wrote: On 2/10/2011 12:42 AM, Scott Weeks wrote: Prefixes Originated (v6): 4 Why 4? Click on the v6 prefixes tab and look at them. There's a US, Taiwan and Europe /32's, and then one additional /48 out of the US /32. Jack more specifically, we did an initial /48 test deployment, to make sure we weren't going to screw things up royally, then we anchored a /32 in each registry region we do business in, and announced those out. Now that the testbed phase is over, I can probably go back and remove that more specific, since the covering /32 is in place; but the other 3 /32s can't be aggregated. Matt
RE: ARIN and IPv6 Requests
Hello Adam: You may want to post this on the ARIN PPML list since the policy folks are all there. They will be able to point your directly to the portion of the NPRM that applies. In addition, this would be the appropriate list to submit policy changes if you don't like the way things are being done now. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: adw...@dstsystems.com [mailto:adw...@dstsystems.com] Sent: Thursday, February 10, 2011 2:23 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: ARIN and IPv6 Requests But how is it relevant? Ever? It's like a bank asking you to justify your need for a loan by asking you how many apples you can pick in an hour. -- Adam Webb From: Owen DeLong o...@delong.com To: adw...@dstsystems.com Cc: nanog@nanog.org Date: 02/10/2011 04:10 PM Subject: Re: ARIN and IPv6 Requests Some policies allow you to use your IPv4 usage as justification of your need for IPv6. If you are applying under one of those policies, you need to fill in that information. If you are applying under a different qualification criteria, I believe you can leave that section blank. Owen On Feb 10, 2011, at 11:50 AM, adw...@dstsystems.com wrote: Initial. Documenting IPv4 usage is in the request template. -- Adam Webb From: Nick Olsen n...@flhsi.com To: nanog@nanog.org Date: 02/10/2011 01:45 PM Subject: re: ARIN and IPv6 Requests We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: ARIN and IPv6 Requests
On Thu, Feb 10, 2011 at 5:23 PM, adw...@dstsystems.com wrote: But how is it relevant? Ever? It's like a bank asking you to justify your need for a loan by asking you how many apples you can pick in an hour. You're asking for a loan to plant an orchard. Oranges this time, but you've only ever grown apples. 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: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 11:46 AM, Ricky Beam wrote: Had they started the process a deacde ago instead of complaining that it's too much work, not worth it, etc., etc., then some of it might have been reclaimed by now. How about 15 years ago: http://tools.ietf.org/html/rfc1917 Regards, -drc
ANNOUNCE: NANOG List and Website Downtime
Hello All: The NANOG website and NANOG mailing list will be unavailable during the times listed below. There is an issue with the present location within the University of Michigan environment that requires a physical move of the NANOG servers to a discrete location. We apologize for the short notice and will do our best to minimize the associated downtime. If you have any questions, feel free to let me know or you can address it on nanog-futures as well. Date of Outage: Sunday, February 13th, 2011 Start of Outage: 0500 EST (GMT -5) End of Outage: 0900 EST (GMT -5) Impact: www.nanog.org will be unavailable and the NANOG mailing list will not accept mail. Regards, Mike On behalf of the NANOG Communications Committee -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
Re: Looking for an IPv6 naysayer...
In message 4d53fd00.40...@ispalliance.net, Scott Helms writes: On 2/9/2011 7:22 PM, Mark Andrews wrote: And some of their customers have been asking for IPv6 all along. I started asking my ISP at home in 2003. I suspect if all the ISPs here were honest they would say that they have had a trickle of IPv6 requests for the last 8 years. Mark Mark, I don't doubt that but request levels have to rise to a certain point. I still get a trickle of requests for UUCP service along with other very low volume features/products. Its the same thing as when you guys get a feature request for BIND or ISC DHCP that only a tiny fraction of your customers will use. Everyone has to prioritize and given that all of the tech folks who wanted to get an IPv6 connection could do so via tunneling there has been absolutely 0 pressure from residential customers and very very little from commercial customers. The federal government's requirement generated a few months of interest until everyone figured out they could satisfy their requirements by setting a tunnel with HE. We sometime react on a single request. Also IPv6 is not something that only a few of our customers will ever use. Close to 100% of our customers will use IPv6. We put IPv6 support, transport and records, into BIND over a decade ago. F was running and answering on IPv6 addresses for years before the were added. We have been using IPv6 for production services for nearly a decade now. I've had a IPv6 tunnel from home to HE for 7 or 8 years and have been reaching the work machines over that for just as long. ISPs know it takes years to move a customer base. They should have been ready years ago. They still arn't ready. I was asking for what features to look for in a new CPE so that it won't need to be replaced when they turn on IPv6 and got this as a answer. It really isn't helpful. Mark  Subject IPv6 support   Discussion Thread  Response Via Email (Russell) 07/02/2011 02.04 PM Dear Mark, Thank you for your email. IPv6 deployment within Optus has not been broadly discussed. At this point in time Optus has no immediate plans for implementation. Kind Regards, Optus Technical Support -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Looking for an IPv6 naysayer...
I'd argue that all TLD registries should be reachable over IPv6 by now and all TLD should be reachable over IPv6 by now. It's not that hard nor is it any more expensive. It just requires will to turn it on. Requiring that new TLDs and the registry infrastucture be reachable over IPv6 from day one is perfectly reasonable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: BCP38 considerations in IPv6
On Thu, 10 Feb 2011, Ryan Rawdon wrote: Hello NANOGers - What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? Have look at some icmpv6 consideration in RFC 4890. Regards, Janos
Re: Looking for an IPv6 naysayer...
On Thu, Feb 10, 2011 at 11:07:26AM +1100, Mark Andrews wrote: Double NAT prevents most of the work arounds working. And quite important for residential ISPs of some size: have fun teaching your call centers diagnosing double-NAT failure modes. NAT444 is a hell I don't want to visit really. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Looking for an IPv6 naysayer...
On Wed, Feb 09, 2011 at 06:01:46PM -0600, Jack Bates wrote: ds-lite tends to be friendlier LSN from various tests, Any pointers to study reports etc. heartly welcome. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: ARIN and IPv6 Requests
Here's the template we just completed last week, and we received our /32 minimum allocation within a couple of days. No justification for initial allocation, only subsequent v6 allocations. https://www.arin.net/resources/templates/v6-isp.txt https://www.arin.net/resources/templates/v6-isp.txtTom Pipes T6 Broadband On Thu, Feb 10, 2011 at 1:38 PM, adw...@dstsystems.com wrote: Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- Tom Pipes T6 Broadband Office: 815-380-3773 Direct: 815-544-1882 Fax: 815-380-6513
Re: Looking for an IPv6 naysayer...
Jens Link wrote: I never thought it was that bad. In some 3G/wireless networks in Germany the providers use NAT and transparent HTTP-proxy. But this is only wireless. I'm not aware of any DSL or Cable provider NATing their customers. I guess in the early days of DSL and Cable internet this was more common (until clue sinked in). I know xs4all in the Netherlands used some NAT flavour or another. Although come to think of it, it was probably the telco (KPN) who did that and the ISP just had to abide. They quickly got rid of that whole idea. It's a strange idea that the telco provides NAT'ing on DSL but I am pretty sure it was that way for a while. KPN since bought xs4all, but that's another story. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Looking for an IPv6 naysayer...
On Wed, Feb 09, 2011 at 04:42:01PM -0800, Owen DeLong wrote: Actually Comcast is willing to give out more than a /64 to a home, they're waiting for the CPE to catch up. Catch up to what? Are there dualstack CPE routers out there only able to handle /64 prefix delegation? I expect that they will eventually come around to giving out /48s, but, for now they seem to feel they need to see the use case develop before they deploy it. Well-known (in Germany) CPE router vendor AVM supports running WiFi in either bridged or routed mode. In routed mode, LAN ports get the first /64 from the DHCPv6-PD delegated prefix, and the WiFi domain gets the second /64. Et voila, there is the first use case. ;-) This is also why their 6RD implementation doesn't accept anything less than a /63. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: My upstream ISP does not support IPv6
On Fri, 4 Feb 2011, david raistrick wrote: Amazon AWS - No. But I'm asking again, that's a few months old. To follow up on this: We are investigating IP v6 but, unfortunately, have no plans that are available for sharing at present -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 3:13 AM, Jimmy Hess wrote: Perhaps the RIRs should personally and directly ask each /8 legacy holder to provide account of their utilization (which portions of the allocation is used, how many hosts), and ASK for each unused /22 [or shorter] to be returned. I've done close: contacted each one, explained the situation, and asked for whatever resources they can return to please return. This has yielded results. I have not asked for an account of their utilization. The legacy holders might (or might not) refuse. They might (or might not) tell the RIRs Hell no In any case, the registry should ASK and publish an indication for each legacy /8 at least. I asked them all. Some have been returned, some are in progress, some are opted to hold them to be monetized via the Specified Transfer policy. So the community will know which (if any) legacy /8 holders are likely to be returning the community's IPv4 addresses that they obtained but don't have need for. There is likely to be another fractional /8 being returned, but not much more. The community should also know which /8 legacy holders say Hell no, we're keeping all our /8s, and not telling you how much of the community's IPv4 resources we're actually using. As I did not explain in advance to each to the parties that their responses would be public, it would not be proper to publicly post the information. Discussions with individual resource holders is treated as confidential information. FYI, /John John Curran President and CEO ARIN
Re: Looking for an IPv6 naysayer...
Daniel Roesen d...@cluenet.de writes: And quite important for residential ISPs of some size: have fun teaching your call centers diagnosing double-NAT failure modes. NAT444 is a hell I don't want to visit really. No it's great! It's secure! It's easy to implement! It's the only way to do it right! Till the end of the month I'm working for a rather large enterprise customer and they use NAT, NAT NAT, NAT NAT NAT, and even even NAT NAT NAT NAT connections for their VPN. They claim that it's easy. I think it isn't and I relay need to get drunk after troubleshooting such a problem. So I must be stupid, because NAT is so *easy*. On the other hand, when you tell them about IPv6 they say it's to complicated and that they don't need it. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Leasing of space via non-connectivity providers
On 2/10/2011 6:07 PM, John Curran wrote: As I did not explain in advance to each to the parties that their responses would be public, it would not be proper to publicly post the information. Discussions with individual resource holders is treated as confidential information. Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly. I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them. As a side effect, it also kills any need of any proposals in various institutions to reserve virgin space for utilization of LSN and such. Jack
Re: Leasing of space via non-connectivity providers
On 2/10/2011 8:10 PM, Jack Bates wrote: As a side effect, it also kills any need of any proposals in various institutions to reserve virgin space for utilization of LSN and such. It might not be too far fetched that they might even endorse us reusing their addressing with permission for such private, non-routed purposes. Jack
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 10:10 PM, Jack Bates wrote: Since you have gone through the process before. It would be nice (especially concerning the DoD networks) if you could ask if they plan to keep them (not monetize) and if you could make such a statement publicly. I mention this, as DoD is most common bogons utilized by people who need to steal IP addressing. Locking in a statement that there is no intention to ever sell, transfer, or return those blocks would ease possible concerns on using them. I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. /John John Curran President and CEO ARIN
Re: Leasing of space via non-connectivity providers
On 2/10/2011 8:15 PM, John Curran wrote: I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) Jack
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: On 2/10/2011 8:15 PM, John Curran wrote: I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) In organizations of all sizes, positions and policies change, with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4 address blocks to ARIN for reuse by the community if they no longer needed. If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. FYI, /John John Curran President and CEO ARIN
Re: Leasing of space via non-connectivity providers
On 2/10/2011 8:44 PM, John Curran wrote: If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that 1) We won't route this, so use it 2) We won't be giving it back or allocating it to someone else where it might be routed. All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Jack
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 9:44 PM, John Curran wrote: On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: On 2/10/2011 8:15 PM, John Curran wrote: I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) In organizations of all sizes, positions and policies change, with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4 address blocks to ARIN for reuse by the community if they no longer needed. If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. I would have to say I agree. Anything short of a posting in the federal register is just a statement of the short-term future. US Gov 201: The federal register from the GPO is the primary source of rule making and RFI the government will use prior to regulation that is not purely legislative. It may be worthwhile to subscribe, or periodically read/search. - Jared
Semi-Annual 'System Status Page' solicitation
If you work for a backbone, content, access, or service provider, and you know that your company has a publicly accessible System/Service/Network Status Page available on the web, we'd love it if you'd add it to the Outages Dashboard, at http://wiki.outages.org/index.php/Dashboard If you have an account on the wiki, you can add it directly; if not, you can add it to the associated Talk page, or email it to me off list, and I'll be happy to add it for you. You're perfectly welcome to add any other pages we don't have listed as well, as long as they're publicly accessible. This was a recording. Cheers, -- jra
Re: box.net network engineer
On Thu, Feb 10, 2011 at 12:01 PM, Andrew Matthews exstat...@gmail.comwrote:
Can someone with the box.net engineering group email me off list.
I have a peering issue with you guys at any2 in socal.
One would think, if you are interconnecting with another network you should
have some contact info for them. Or know where to find
the information necessary for situations like this.
https://www.peeringdb.com/private/participant_view.php?id=1904
$ whois -h whois.radb.net as33011
aut-num:AS33011
as-name:BOXNET
descr: Box.net, Inc.
import: from AS-ANY accept ANY
export: to AS-ANY announce AS33011 AND NOT {0.0.0.0/0}
admin-c:JQU26-ARIN
tech-c: GCG-ARIN
notify: n...@box.net
mnt-by: MNT-BOXNE-1
changed:gg...@box.net 20080513
source: ARIN
Thanks,
Drew
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 9:54 PM, Jack Bates wrote: On 2/10/2011 8:44 PM, John Curran wrote: If you'd like to reserve a large block for purposes of LSN without any concern of future address conflict, it would be best to actually reserve it via community-developed policy. When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that 1) We won't route this, so use it 2) We won't be giving it back or allocating it to someone else where it might be routed. All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Jack, I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..) I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be that much pain. Obviously the pain will vary per subscriber/home. I think despite everyones dislike, distaste and wish that the IPv6 situation didn't smell quite as bad as it does, we're certainly stuck with it. I don't see anyone deploying a new solution anytime soon, and it having broad market acceptance/coding. Many of us wish that IPv6 didn't have a lot of unecessary/ugly stuff. I wish that the network situation wasn't as ugly, but none of this will make it so. We will have to continue to improve and augment the autoconf, dhcpv6, etc environment. The existing hosts need to be fixed (eg: my laptop won't do ipv6 over pptp/vpn properly without a hack), etc.. IPv4 is dead in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Please make sure you list IPv6 *first* in your RFPs, and the IPv4 capabilities under the 'legacy protocols' for 2011. If we're truly going to have the promise of the Internet, we need these market forces to drive the carriers and SME/Prosumer markets to lead the way for the grandparents to still get to their Google, Bing et al, and not just those of us who know there will be an IPv6 day and have our mailboxes filled with IPv6 spam this month. - Jared
Re: Leasing of space via non-connectivity providers
On Feb 10, 2011, at 10:54 PM, Jack Bates wrote: When there are X /8 networks reserved by the USG, it seems extremely wasteful to reserve from what little space we have a large block dedicated to LSN when the USG can give assurances that 1) We won't route this, so use it 2) We won't be giving it back or allocating it to someone else where it might be routed. All proposals concerning reserving a /8 of unallocated space for LSN purposes was seen as obscene, and many proposals compromised with a /10, which some feel is too small. I don't think it would hurt for someone with appropriate connections to ask the USG on the matter. It is, after all, in the USG's interest and doesn't conflict with their current practices. Many don't consider it a concern (shown by wide use of DoD space already deployed), yet some do apparently have concern since there has been multiple requests for a new allocation for LSN purposes (in the IETF and in RIRs). Indeed, that does sound simple. Obtaining such a commitment may prove to be a little more difficult, since it permanently encumbers use of one or more address blocks. I am happy to ask, however, if there is a strong level of support to do so. Alternatively, there is valid contact information listed in WHOIS for US DOD and other commercial /8 address block holders if you wish to ask one directly. /John John Curran President and CEO ARIN p.s. Considering that we've collectively allocated the 95%+ of the address space which was made available outside of DoD's original blocks, and the DoD additionally returned 2 more /8's for the community (noted here: http://blog.icann.org/2008/02/recovering-ipv4-address-space/), they may actually have a different perspective us coming back to impair some of the remaining space they still hold. I'm happy to discuss it, but wanted to point out the long history and potential different perspective.
Re: Leasing of space via non-connectivity providers
On 2/10/2011 9:11 PM, Jared Mauch wrote: I was explaining to my wife today how it felt like the nanog list went to 3x the typical mail volume recently with all the IPv6 stuff this month. Why the pro-IPv6 crowd was happy, the anti-IPv6 crowd is groaning (including those that truly despise the whole thing, etc..) I was having fun discussing with my wife how ARIN stuff ended up on NANOG, NANOG stuff ended up on PPML, and I've been listening and participating in debates concerning IPv6 and CGN (apparently BEHAVE WG adopted CGN over LSN) on 4 different mailing lists. To be honest, though. I'm pro-IPv6, but I'm not happy. Anyone who is happy doesn't care about those innocent people who are ignorant of what is going on and why. I honestly think that the LSN situations won't be as bad as some of us think. The big carriers have already been doing some flavor of this with their cellular/data networks. Doing this on some of the consumer networks will likely not be that much pain. Obviously the pain will vary per subscriber/home. snip lots of good stuff I agree with IPv4 is dead in my opinion. Not dead as in useless, but to the point where I don't think there is value in spending a lot of time worrying about the v4 side of the world when so much needs to be fixed in IPv6 land. Service requirements in cellular networks are considerably different than wireline. Apparently, most cell customers don't hook a CPE router into their cell network and play their game consoles over it, along with many other situations. This actually means that most often, they are running a single stage NAT44 LSN (which still breaks stuff, but most of the things it would break aren't normally transiting the cellular networks). snip more good stuff I agree with I agree. However, because the largest networks and corporations decided (and some still do) to wait until the last moment to deal with IPv6, we will have to deal with IPv4 in much worse conditions. I know that there are large cellular networks which use DoD bogons behind huge LSN implementations. I know that some networks apparently aren't happy with using DoD bogons and would like to waste even more space. The best solution for such a case (and to solve all arguments on the matter) is to secure assurances on the bogons so that they can be safely used. Jack
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman matt...@matthew.at wrote: There is no one universal global routing table. They probably appear in someone's routing table, somewhere... just not yours. Using public address space for private networking is a gross misuse of the resource. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. How many days do you think a single /8 lasts at current assignment rates? APNIC says the last 2 /8's they were assigned (triggering the dead-man clause) would last ~6mo. With responsible use, 22 /8's would last several years. (3-5 best guess. Of course, there could be a land-rush and all of it disappear next week -- see also: responsible use) How would ARIN/ICANN go about reclaiming addresses that someone believes they are using but that you don't think are in use? First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used (announced) the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it. As the powers that be have drug their feet for over a decade already, I really doubt they'll even take 5 minutes to look at *a single* route server. As for this not fixing the problem, IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being out of space is getting news attention now, but will fade from the spotlight shortly. The people who have space will continue to have it and generally not notice the lack of availablity. The likes of Facebook, etc., have jumped on IPv6 because they have a reason to... they have volumes of IPv6 connected eyeballs. Yet the likes of Amazon and Akamai, aren't supporting IPv6 (and have no published plans to.) Almost all of the major ISPs in the country still don't fully support IPv6 -- the few that do embrace v6 make it a pain in the ass to get it setup. I don't support IPv6 (since elink killed their experiment); I can get everywhere I care to go, and everyone who cares to get to me does. I, like many/most others, will fix that problem when it *is* a problem. (For the record... TWTC: not supported, Speakeasy: not supported, VZB: not recommended for an existing connection (if you want it to stay working)) --Ricky
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/10/2011 9:46 PM, Ricky Beam wrote: On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman matt...@matthew.at wrote: There is no one universal global routing table. They probably appear in someone's routing table, somewhere... just not yours. Using public address space for private networking is a gross misuse of the resource. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. https://www.arin.net/policy/nrpm.html#four35 Encourages use of RFC1918, but does not require it, especially when private peering with other networks is involved. How many days do you think a single /8 lasts at current assignment rates? APNIC says the last 2 /8's they were assigned (triggering the dead-man clause) would last ~6mo. With responsible use, 22 /8's would last several years. (3-5 best guess. Of course, there could be a land-rush and all of it disappear next week -- see also: responsible use) If all 22 /8's were free to use, yes, 3-5 years. However, it violates existing RIR policies if those addresses are in use, even if not routed publicly. First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used (announced) the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it. All of this would have to be accomplished in less than 6-9 months, but no one is going to wait in the hopes it might be accomplished, as failure would mean ruin. So the networks will deploy counter measures before the 6-9 month mark. They are already in the process. As for this not fixing the problem, IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being out of space is getting news attention now, but will fade from the spotlight shortly. The people who have space will continue to have it and generally not notice the lack of availablity. The likes of Facebook, etc., have jumped on IPv6 because they have a reason to... they have volumes of IPv6 connected eyeballs. Yet the likes of Amazon and Akamai, aren't supporting IPv6 (and have no published plans to.) Almost all of the major ISPs in the country still don't fully support IPv6 -- the few that do embrace v6 make it a pain in the ass to get it setup. I don't support IPv6 (since elink killed their experiment); I can get everywhere I care to go, and everyone who cares to get to me does. I, like many/most others, will fix that problem when it *is* a problem. IPv4 will not be a problem for MANY years to come. If it survives 5 years in the DFZ, I'll be shocked. Errr, wasn't it this list that Akamai said they were testing and working on IPv6 deployments less than a week ago? Also, just because I have space (currently a /19 free), only means I have until that space runs out (assigning a /22 to a telco tomorrow morning as they just hit 98% utilization tonight, technically 100%, but I managed to free up a few). After that, IPv4 requires CGN or IPv6 with NAT64/DNS64. Neither option is pretty. Jack
Cruzio peering
A Cruzio employee kindly provided me with the following information regarding their peering and connectivity. I pasted it below (with permission) because I thought it might be of use to others: Cruzio maintains a backbone of wireless points of presence (POP) on various mountain tops overlooking the Monterey Bay, South San Francisco Bay, and Silicon Valley Regions. Cruzio wireless POPs are present on Mount Umunhum, Mount Allison, Loma Prieta and Black Mountain to name a few. Cruzio wireless POPs are fed from the Equinix San Jose facility. At Equinix, Cruzio is cross connected into a peering exchange to an aggregate of content providers which include Google, You Tube and several others. Non-peered connectivity is provided by Above.net who is also colocated in that facility. Cruzio leases dark fiber on the cable built and owned by Sunesys, which is also used by UCSC. This fiber cable links the Cruzio facility at 877 Cedar Street in downtown Santa Cruz with the Level 3 Sunnyvale facility 46 miles away. Connectivity to the Internet is provided by Level 3 and Cogent. A high-speed/high-bandwidth wireless link connects the Cruzio 877 Cedar facility with the Equinix San Jose facility via Mount Umunhum to provide a wireless failover to the fiber in event of a fiber outage. Cruzio wholesales ATT DSL. All DSL traffic is aggregated over ATT fiber to the 200 Paul Avenue facility where it is connected to the Internet through a variety of providers. While the fiber and new data center are being turned up and tested, Cruzio hosted servers remain connected over ATT fiber to the he.net Fremont 1 facility. Connectivity to the Internet is through he.net, who are themselves connected and peered to multiple Tier 1 providers. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Looking for an IPv6 naysayer...
On 02/09/2011 03:47 PM, George Bonser wrote: I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. The big providers probably categorise a static IP in their enterprise/business offerings. But both my provider here (Cruzio) as well as xs4all back in the Netherlands provide a static IP with configurable rDNS. For no fee or a minimal fee. I guess it depends more on which type of provider you choose and their lousy el cheapo offerings. There are more providers than comcast, verizon and att. And I bet the majority of them are more knowledgeable (and less likely to do nasty things with your traffic). Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
RE: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
As for this not fixing the problem, IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being out of space is getting news attention now, but will fade from the spotlight shortly I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic. Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have ATT with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again.
Re: Leasing of space via non-connectivity providers
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Thu Feb 10 20:35:01 2011 Date: Thu, 10 Feb 2011 20:31:32 -0600 From: Jack Bates jba...@brightok.net To: John Curran jcur...@arin.net Subject: Re: Leasing of space via non-connectivity providers Cc: NANOG na...@merit.edu On 2/10/2011 8:15 PM, John Curran wrote: I'm not certain that you could rely on any organizations statements made today to provide any assurance that circumstances would not change in the future and result in the address space being returned to ARIN or transferred per current policy. An official statement from the DoD? I'm sure we could hold them to it as a community. Is it too much for us to ask the US government to give us assurance that we can safely utilize huge chunks of address space assigned to them for purposes such as LSN without fear? :) Even the DoD cannot say for sure that they would never route some of that space 'in time of need' over the public internet.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 5:46 PM, Ricky Beam wrote: On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman matt...@matthew.at wrote: There is no one universal global routing table. They probably appear in someone's routing table, somewhere... just not yours. Using public address space for private networking is a gross misuse of the resource. Amusingly enough, I personally (along with others) made arguments along these lines back in 1995 or so when the IAB was coming out with http://www.ietf.org/rfc/rfc1814.txt. Given the publication of 1814, you can probably guess how far those arguments fared. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment. I haven't looked recently but I believe all the RIRs have policies that requires them to allocate unique numbers regardless of whether those addresses will be used on the Internet, as long as the requester documents appropriate utilization. Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) I gather you're volunteering to pay higher fees to cover the increased legal costs? Regards, -drc
Re: Leasing of space via non-connectivity providers
In message 78697910-f7a6-4d53-ad93-377fce660...@arin.net, John Curran writes: On Feb 10, 2011, at 10:31 PM, Jack Bates wrote: On 2/10/2011 8:15 PM, John Curran wrote: I'm not certain that you could rely on any organizations statements made= today to provide any assurance that circumstances would not change in the futu= re and result in the address space being returned to ARIN or transferred per cu= rrent policy. =20 An official statement from the DoD? I'm sure we could hold them to it as = a community. Is it too much for us to ask the US government to give us assu= rance that we can safely utilize huge chunks of address space assigned to t= hem for purposes such as LSN without fear? :) In organizations of all sizes, positions and policies change,=20 with revised statements as a result. One thing that does not change, however, is contractual commitments, and in this one case I can state that there is a commitment to return IPv4=20 address blocks to ARIN for reuse by the community if they no=20 longer needed. If you'd like to reserve a large block for purposes of LSN=20 without any concern of future address conflict, it would be=20 best to actually reserve it via community-developed policy. The first half of Class E would work. There are 134+ million addresses there and you only have to be able to route it between the CPE and the LSN / 6rd BR. The CPE signals that it support Class E (DHCP/PPP option) and the ISP only assigns a address from the block if it knows the path is Class E clean. Anyone that can't work with double NAT would clear the option and it would be on by default. It should be possible to patch all existing CPE devices to support this without flash memory constraints. The same can't be said for upgrading then to support IPv6. It does require the whole world to upgrade to be useful. It can be done incrementally. It will significiantly reduce the remaining IPv4 consumption rate. Those CPE's that turn on 6to4 automatically now have another well known address range where it is known not to work. It doesn't clash with address ranges already in use by customers. It can be used with 6rd so that IPv6 can be deployed over it for ISP's that have boxes that can't be upgraded to IPv6. It gives them a little more breathing room. 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: Failure modes: NAT vs SPI
On 2/10/11 7:53 AM, Lamar Owen wrote: On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote: 1. Scanning even an entire /64 at 1,000 pps will take 18,446,744,073,709,551 seconds which is 213,503,982,334 days or 584,542,000 years. I would posit that since most networks cannot absorb a 1,000 pps attack even without the deleterious effect of incomplete ND on the router, no network has yet had even a complete /64 scanned. IPv6 simply hasn't been around that long. Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds? There are more useful things to do with the compute cycles...
