Re: NAT444 or ?
Op 8 sep 2011, om 07:26 heeft Geoff Huston het volgende geschreven: > > On 08/09/2011, at 2:41 AM, Leigh Porter wrote: > > It may not be what Randy was referring to above, but as part of that program > at APNIC32 I reported on the failure rate I am measuring for Teredo. I'm not > sure its all in the slides I was using, but what I was trying to say was that > STUN is simply terrible at reliably negotiating a NAT. I was then wondering > what pixie dust CGNs were going to use that would have any impact on the ~50% > connection failure rate I'm observing in Teredo. And if there is no such > thing as pixie dust (damn!) I was then wondering if NATs are effectively > unuseable if you want anything fancier than 1:1 TCP connections (like > multi-user games, for example). After all, a 50% connection failure rate for > STUN is hardly encouraging news for a CGN deployer if your basic objective is > not to annoy your customers. The striking thing I picked up is that NTT considers the CGN equipment a big black hole where money goes into. Because it won't solve their problem now or in the future and it becomes effectively a piece of equipment they need to buy and then scrap "soon" after. They acknowledge the need, but they'd rather not buy one. That and they (the isp) get called for anything which doesn't work. Regards, Seth
Re: NAT444 or ?
On 08/09/2011, at 2:41 AM, Leigh Porter wrote: > > >> -Original Message- >> From: Daniel Roesen [mailto:d...@cluenet.de] >> Sent: 07 September 2011 17:38 >> To: nanog@nanog.org >> Subject: Re: NAT444 or ? >> >> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: I'm going to have to deploy NAT444 with dual-stack real soon now. >>> >>> you may want to review the presentations from last week's apnic >> meeting >>> in busan. real mesurements. sufficiently scary that people who were >>> heavily pushing nat444 for the last two years suddenly started to say >>> "it was not me who pushed nat444, it was him!" as if none of us had >> a >>> memory. >> >> Hm, I fail to find relevant slides discussing that. Could you please >> point us to those? >> >> I'm looking at http://meetings.apnic.net/32 > > There is a lot in the IPv6 plenary sessions: > > http://meetings.apnic.net/32/program/ipv6 > > This is what I am looking at right now. Randy makes some good comments in > those sessions. I have not found anything yet, but I am only on session 3, > pertaining specifically to issues around NAT444. It may not be what Randy was referring to above, but as part of that program at APNIC32 I reported on the failure rate I am measuring for Teredo. I'm not sure its all in the slides I was using, but what I was trying to say was that STUN is simply terrible at reliably negotiating a NAT. I was then wondering what pixie dust CGNs were going to use that would have any impact on the ~50% connection failure rate I'm observing in Teredo. And if there is no such thing as pixie dust (damn!) I was then wondering if NATs are effectively unuseable if you want anything fancier than 1:1 TCP connections (like multi-user games, for example). After all, a 50% connection failure rate for STUN is hardly encouraging news for a CGN deployer if your basic objective is not to annoy your customers. regards, Geoff
Re: Mailing list/group for datacenter facilities folks
On Wed, Sep 07, 2011 at 08:03:24PM -0500, Jimmy Hess said: >On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim wrote: >> I would love to be a part of this list if there is one!!! >> >> Cooling is not as easy as just pumping cold air into a room. >> >? >Indeed... it's even easier than that. Cooling is as easy as making >an entire room emit heat >to the outside environment at an average rate that is consistently >faster than heat transfer >into the room from all sources. > >There are many ways of accomplishing that. One of the best ways >is to repeal the laws of thermodynamics /kc -- Ken Chase - k...@sizone.org
Re: Brighthouse Outage in Tampa, FL
It affected outside Tampa even. Even went as far south as Bradenton so I am guessing it was systemwide. For awhile their call center was so overloaded you received a fast busy when you called. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.twitter.com/j2sw Follow me on Twitter -Original Message- From: "Eric C. Miller" Date: Wed, 7 Sep 2011 23:45:09 + To: "nanog@nanog.org" Subject: Brighthouse Outage in Tampa, FL >Does anyone know what the "software bug" that hit Brighthouse in Tampa? > >Eric Miller >
RE: Mailing list/group for datacenter facilities folks
LOL too funny guys.. I agree it has to do with air flowplus temps have to be just right. You don't want it too cold and equipment start freezingor ice forming > Date: Wed, 7 Sep 2011 18:32:01 -0700 > From: sur...@mauigateway.com > To: nanog@nanog.org > Subject: Re: Mailing list/group for datacenter facilities folks > > > - From: Jimmy Hess - > On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim > wrote: > > > Cooling is not as easy as just pumping cold air into a room. > > > : There are many ways of accomplishing that. One of the best ways > : is to put your room in an already cold environment, in contact > : with an excellent thermal conductor. > : > : For example... server room in the arctic region, > -- > > > > Years ago there was a guy on this list that ran the network at the Antarctic > station and he told me that he had overheating issues in his datacenter, so > it may not be as easy as one would think... ;-) > > scott >
Re: Mailing list/group for datacenter facilities folks
- From: Jimmy Hess - On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim wrote: > Cooling is not as easy as just pumping cold air into a room. : There are many ways of accomplishing that. One of the best ways : is to put your room in an already cold environment, in contact : with an excellent thermal conductor. : : For example... server room in the arctic region, -- Years ago there was a guy on this list that ran the network at the Antarctic station and he told me that he had overheating issues in his datacenter, so it may not be as easy as one would think... ;-) scott
Re: Mailing list/group for datacenter facilities folks
On Wed, Sep 7, 2011 at 2:06 PM, Brandon Kim wrote: > I would love to be a part of this list if there is one!!! > > Cooling is not as easy as just pumping cold air into a room. > ? Indeed... it's even easier than that. Cooling is as easy as making an entire room emit heat to the outside environment at an average rate that is consistently faster than heat transfer into the room from all sources. There are many ways of accomplishing that. One of the best ways is to put your room in an already cold environment, in contact with an excellent thermal conductor. For example... server room in the arctic region,at the bottom of some lake. Probably with all air removed from the environment, and a sound thermal medium such as oil pumped in in its place (make sure to use SSDs for all storage and no mechanical devices). -- -JH
Re: Mailing list/group for datacenter facilities folks
+1 -- Pardon the typos - sent from a silly keyboard On Sep 7, 2011, at 12:09, Matt Ryanczak wrote: > On 09/07/2011 03:06 PM, Brandon Kim wrote: >> I would love to be a part of this list if there is one!!! > > +1 >
Re: NAT444 or ?
On Sep 7, 2011, at 1:05 PM, Leigh Porter wrote: > > >> -Original Message- >> From: Seth Mos [mailto:seth@dds.nl] >> Sent: 07 September 2011 20:26 >> To: NANOG >> Subject: Re: NAT444 or ? >> >> I think you have the numbers off, he started with 1000 users sharing >> the same IP, since you can only do 62k sessions or so and with a >> "normal" timeout on those sessions you ran into issues quickly. >> >> The summary is that with anything less then 20 tcp sessions per user >> simultaneous google maps or earth was problematic. From 15 and >> downwards almost unsable. >> >> He deducted from testing that about 10 users per IP was a more >> realistic limit without taking out the entire CGN "experience". >> >> On a personal note, this isn't even taking into question things like >> broken virus scanners or other software updates that will happily try >> to do 5 sessions per second, or a msn client lost trying to do 10 per >> second. The most the windows IP stack will allow on client versions. >> >> The real big issue that will be the downfall of NAT444 is the issue >> with ACLS and automatic blocklists and the loss of granular access >> control on that which the ISP has no control of. Which roughly >> estimates to the internet. >> >> Regards, >> >> Seth > > I was thinking of an average of around 100 sessions per user for working out > how things scale to start with. It would also be handy to be able to apply > sensible limits to new sessions, say limit the number of sessions to a single > destination IP address and apply an overall session limit of perhaps 200 > sessions per source IP address. > > ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more > and more common, such things will gradually die out. > I think that such things will kill the NAT444 user experience rather than having the NAT444 user experience problems kill the block lists. The people maintaining said lists are generally trying to protect larger systems from abusers and don't have any strong motivation to preserve the user experience of particular ISPs or particular subsets of users. > Considering that offices, schools etc regularly have far more than 10 users > per IP, I think this limit is a little low. I've happily had around 300 per > public IP address on a large WiFi network, granted these are all different > kinds of users, it is just something that operational experience will have to > demonstrate. > Yes, but, you are counting individual users whereas at the NAT444 level, what's really being counted is end-customer sites not individual users, so the term "users" is a bit misleading in the context. A given end-customer site may be from 1 to 50 or more individual users. > I would love to avoid NAT444, I do not see a viable way around it at the > moment. Unless the Department of Work and Pensions release their /8 that is > ;-) > The best mitigation really is to get IPv6 deployed as rapidly and widely as possible. The more stuff can go native IPv6, the less depends on fragile NAT444. Owen > > -- > Leigh > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __
Brighthouse Outage in Tampa, FL
Does anyone know what the "software bug" that hit Brighthouse in Tampa? Eric Miller
Tampa Colos: IPv6
So I think my shortlist is Esol, Equinix, Qwest, and DirectColo, if they're not already a tenant of one of the other 3. Anyone got any info on how those three/four are about native IPv6? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
RE: NAT444 or ?
> -Original Message- > From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] > Sent: 07 September 2011 23:14 > To: Dorn Hetzel > Cc: Leigh Porter; NANOG > Subject: Re: NAT444 or ? > > On Wed, 07 Sep 2011 16:13:26 EDT, Dorn Hetzel said: > > > Perhaps it can be made ever so slightly less ugly if endpoints get an > > "address" that consists of a 32 bit IP address + (n) upper bits of > > port number. > > > > This might be 4 significant bits to share an IP 16 ways, or 8 > > significant bits to share it 256 ways, or whatever. > > And you store the 4 or 8 bits in what part of the IPv4 header, exactly? Nobody uses the TOS bits, do they? ;-) -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: NAT444 or ?
On Wed, 07 Sep 2011 16:13:26 EDT, Dorn Hetzel said: > Perhaps it can be made ever so slightly less ugly if endpoints get an > "address" that consists of a 32 bit IP address + (n) upper bits of port > number. > > This might be 4 significant bits to share an IP 16 ways, or 8 significant > bits to share it 256 ways, or whatever. And you store the 4 or 8 bits in what part of the IPv4 header, exactly? pgpMvoSVIVthu.pgp Description: PGP signature
RE: Mailing list/group for datacenter facilities folks
Have found http://www.linkedin.com/groups?about=&gid=94108 to have some gems in it. I mention only because it's otherwise a case of YAML (that is, Yet Another Mailing List, not the logging format...) Of course, not everyone uses or likes LinkedIn. Mark. On Wed, 2011-09-07 at 16:09 -0400, Drew Weaver wrote: > dc-...@puck.nether.net thanks Jared =) > > http://puck.nether.net/mailman/listinfo/dc-ops > > -Drew > > > -Original Message- > From: Drew Weaver [mailto:drew.wea...@thenap.com] > Sent: Wednesday, September 07, 2011 2:28 PM > To: 'nanog@nanog.org' > Subject: Mailing list/group for datacenter facilities folks > > Just wondering, > > Is anyone aware whether there is already an active mailing list/group for > datacenter facilities folks to discuss power, cooling, physical > infrastructure, etc, etc...? > > thanks, > -Drew > > >
Re: NAT444 or ?
David Israel wrote, on 09/07/2011 04:21 PM: > In theory, this > particular performance problem should only arise when the NAT gear insists on > a > unique port per session (which is common, but unnecessary) What you're describing is known as "endpoint-independent mapping" behaviour. It is good for not breaking applications, not so good for scalability. RFC 4787 section 4.1 makes it a MUST. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca
RE: NAT444 or ?
> -Original Message- > From: David Israel [mailto:da...@otd.com] > Sent: 07 September 2011 21:23 > To: nanog@nanog.org > Subject: Re: NAT444 or ? > > On 9/7/2011 3:24 PM, Seth Mos wrote: > > I think you have the numbers off, he started with 1000 users sharing > the same IP, since you can only do 62k sessions or so and with a > "normal" timeout on those sessions you ran into issues quickly. > > > > Remember that a TCP session is defined not just by the port, but by the > combination of source address:source port:destination > address:destination port. So that's 62k sessions *per destination* per > ip address. In theory, this particular performance problem should > only > arise when the NAT gear insists on a unique port per session (which is > common, but unnecessary) or when a particular destination is > inordinately popular; the latter problem could be addressed by > increasing the number of addresses that facebook.com and google.com > resolve to. Good point, but aside from these scaling issues which I expect can be resolved to a point, the more serious issue, I think, is applications that just do not work with double NAT. Now, I have not conducted any serious research into this, but it seems that draft-donley-nat444-impacts does appear to have highlight issues that may have been down to implementation. Other simple tricks such as ensuring that your own internal services such as DNS are available without traversing NAT also help. Certainly some more work can be done in this area, but I fear that the only way a real idea as to how much NAT444 really doe break things will be operational experience. -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Mailing list/group for datacenter facilities folks
On Sep 7, 2011, at 3:09 PM, Drew Weaver wrote: > dc-...@puck.nether.net thanks Jared =) +1, beat me to it. Thanks! --Chris
Re: NAT444 or ?
On 9/7/2011 3:24 PM, Seth Mos wrote: I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly. Remember that a TCP session is defined not just by the port, but by the combination of source address:source port:destination address:destination port. So that's 62k sessions *per destination* per ip address. In theory, this particular performance problem should only arise when the NAT gear insists on a unique port per session (which is common, but unnecessary) or when a particular destination is inordinately popular; the latter problem could be addressed by increasing the number of addresses that facebook.com and google.com resolve to. I'm not advocating CGN; my point is not that this problem *should* be solved, merely that it *can* be. -Dave
Re: NAT444 or ?
On Wed, Sep 7, 2011 at 4:05 PM, Leigh Porter wrote: > > I was thinking of an average of around 100 sessions per user for working > out how things scale to start with. It would also be handy to be able to > apply sensible limits to new sessions, say limit the number of sessions to a > single destination IP address and apply an overall session limit of perhaps > 200 sessions per source IP address. > > ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more > and more common, such things will gradually die out. > > Considering that offices, schools etc regularly have far more than 10 users > per IP, I think this limit is a little low. I've happily had around 300 per > public IP address on a large WiFi network, granted these are all different > kinds of users, it is just something that operational experience will have > to demonstrate. > > I would love to avoid NAT444, I do not see a viable way around it at the > moment. Unless the Department of Work and Pensions release their /8 that is > ;-) > > Perhaps it can be made ever so slightly less ugly if endpoints get an "address" that consists of a 32 bit IP address + (n) upper bits of port number. This might be 4 significant bits to share an IP 16 ways, or 8 significant bits to share it 256 ways, or whatever. In a perfect world, all of the endpoints sharing a single IP would be off a single concentration point of whatever sort (same tower, etc)... The end users can still do their own NAT then, their NAT device just has to restrict the external port range to the one assigned (or have packets with bad source ports dropped when sent). Ok, not really pretty, but maybe a little less ugly than twice NAT, and at least users could have "fixed" addresses (including the upper bits of port number). Of course, the value for upper port bits can be reserved for "business" grade users so they get the nice ports like 80, etc.
Re: NAT444 or ?
>> However these are with a very high address-sharing ratio (several >> thousands users per address). Using a sparser density (<= 64 users per >> address) is likely to show much less dramatic user impacts. > > I think you have the numbers off, he started with 1000 users sharing > the same IP, since you can only do 62k sessions or so These numbers were not off. From page 19: "...we should assign at least 1000 [..] ports per customer to assure good performance of IPv4 applications" "At least 1000 ports per customers" is roughly the same than "less than 64 users per address" as I stated above. Btw, 90% of subscribers have less than 100 active connections at any time, if I read these tiny graphs correctly: http://www.wand.net.nz/~salcock/pam2009_final.pdf > and with a "normal" timeout on those sessions you ran into issues quickly. Agreed for UDP, but most of these sessions are TCP, which arguably time out rather rapidly after a FIN and an extra hold time. Normal duration of a TCP session is usually under a few seconds. This study saw an average connection time of 8 seconds for DSL, but it's from 2004. http://www.google.com/#q=A+Comparative+Study+of+TCP/IP+Traffic+Behavior+in+Broadband+Access+Networks /JF
RE: Mailing list/group for datacenter facilities folks
dc-...@puck.nether.net thanks Jared =) http://puck.nether.net/mailman/listinfo/dc-ops -Drew -Original Message- From: Drew Weaver [mailto:drew.wea...@thenap.com] Sent: Wednesday, September 07, 2011 2:28 PM To: 'nanog@nanog.org' Subject: Mailing list/group for datacenter facilities folks Just wondering, Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...? thanks, -Drew
RE: NAT444 or ?
> -Original Message- > From: Seth Mos [mailto:seth@dds.nl] > Sent: 07 September 2011 20:26 > To: NANOG > Subject: Re: NAT444 or ? > > I think you have the numbers off, he started with 1000 users sharing > the same IP, since you can only do 62k sessions or so and with a > "normal" timeout on those sessions you ran into issues quickly. > > The summary is that with anything less then 20 tcp sessions per user > simultaneous google maps or earth was problematic. From 15 and > downwards almost unsable. > > He deducted from testing that about 10 users per IP was a more > realistic limit without taking out the entire CGN "experience". > > On a personal note, this isn't even taking into question things like > broken virus scanners or other software updates that will happily try > to do 5 sessions per second, or a msn client lost trying to do 10 per > second. The most the windows IP stack will allow on client versions. > > The real big issue that will be the downfall of NAT444 is the issue > with ACLS and automatic blocklists and the loss of granular access > control on that which the ISP has no control of. Which roughly > estimates to the internet. > > Regards, > > Seth I was thinking of an average of around 100 sessions per user for working out how things scale to start with. It would also be handy to be able to apply sensible limits to new sessions, say limit the number of sessions to a single destination IP address and apply an overall session limit of perhaps 200 sessions per source IP address. ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more and more common, such things will gradually die out. Considering that offices, schools etc regularly have far more than 10 users per IP, I think this limit is a little low. I've happily had around 300 per public IP address on a large WiFi network, granted these are all different kinds of users, it is just something that operational experience will have to demonstrate. I would love to avoid NAT444, I do not see a viable way around it at the moment. Unless the Department of Work and Pensions release their /8 that is ;-) -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Mailing list/group for datacenter facilities folks
I'd like to have discussions on air flow, CRAC units, A/B power circuitsbest practices etc etc. > From: a...@corp.nac.net > To: brandon@brandontek.com; drew.wea...@thenap.com; nanog@nanog.org > Date: Wed, 7 Sep 2011 15:20:56 -0400 > Subject: RE: Mailing list/group for datacenter facilities folks > > Perhaps there should be a DC track at NANOG? > > One of the reasons I have not gone in years. > > I have much knowledge and experience to share, but no one to share it with. > > > > > I would love to be a part of this list if there is one!!! > > > > Cooling is not as easy as just pumping cold air into a room. > > > > > > > > > Just wondering, > > > > > > Is anyone aware whether there is already an active mailing list/group for > > datacenter facilities folks to discuss power, cooling, physical > > infrastructure, etc, > > etc...?
Re: Mailing list/group for datacenter facilities folks
On Sep 7, 2011, at 1:28 PM, Drew Weaver wrote: > Just wondering, > > Is anyone aware whether there is already an active mailing list/group for > datacenter facilities folks to discuss power, cooling, physical > infrastructure, etc, etc...? > There was one at shorty.com, but that's now a paintball / Airsoft site. $DAYJOB is willing to host a new maillist though. Give me a while and we'll get one set up. --Chris
Re: NAT444 or ?
Op 7 sep 2011, om 19:06 heeft jean-francois.tremblay...@videotron.com het volgende geschreven: > On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: >>> I'm going to have to deploy NAT444 with dual-stack real soon now. >> you may want to review the presentations from last week's apnic meeting >> in busan. real mesurements. sufficiently scary that people who were >> heavily pushing nat444 for the last two years suddenly started to say >> "it was not me who pushed nat444, it was him!" as if none of us had a >> memory. >> >> Hm, I fail to find relevant slides discussing that. Could you please >> point us to those? > > I had the same question. I found Miyakawa-san's presentation has some > dramatic examples of CGN NAT444 effects using Google Maps: > http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf > > > > However these are with a very high address-sharing ratio (several > thousands users per address). Using a sparser density (<= 64 users per > address) is likely to show much less dramatic user impacts. I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly. The summary is that with anything less then 20 tcp sessions per user simultaneous google maps or earth was problematic. From 15 and downwards almost unsable. He deducted from testing that about 10 users per IP was a more realistic limit without taking out the entire CGN "experience". On a personal note, this isn't even taking into question things like broken virus scanners or other software updates that will happily try to do 5 sessions per second, or a msn client lost trying to do 10 per second. The most the windows IP stack will allow on client versions. The real big issue that will be the downfall of NAT444 is the issue with ACLS and automatic blocklists and the loss of granular access control on that which the ISP has no control of. Which roughly estimates to the internet. Regards, Seth
RE: Mailing list/group for datacenter facilities folks
Perhaps there should be a DC track at NANOG? One of the reasons I have not gone in years. I have much knowledge and experience to share, but no one to share it with. > > I would love to be a part of this list if there is one!!! > > Cooling is not as easy as just pumping cold air into a room. > > > > > Just wondering, > > > > Is anyone aware whether there is already an active mailing list/group for > datacenter facilities folks to discuss power, cooling, physical > infrastructure, etc, > etc...?
Re: Mailing list/group for datacenter facilities folks
On 09/07/2011 03:06 PM, Brandon Kim wrote: > I would love to be a part of this list if there is one!!! +1
RE: Mailing list/group for datacenter facilities folks
I would love to be a part of this list if there is one!!! Cooling is not as easy as just pumping cold air into a room. > From: drew.wea...@thenap.com > To: nanog@nanog.org > Date: Wed, 7 Sep 2011 14:28:05 -0400 > Subject: Mailing list/group for datacenter facilities folks > > Just wondering, > > Is anyone aware whether there is already an active mailing list/group for > datacenter facilities folks to discuss power, cooling, physical > infrastructure, etc, etc...? > > thanks, > -Drew > >
FW: .mil DNSSEC operational message
The United States Department of Defense (DoD) has authorized the DoD Network Information Center (NIC) to sign the .mil zone using DNSSEC. The DoD NIC will sign the .mil zone using a phased implementation plan that will span a three (3) month period. The first phase will consist of signing the .mil zone with an unvalidatable key, similar to the method used to initially sign several other gTLDs, as well as the root zone. During the second phase, the .mil zone will be signed using a validatable key. However, this key will not be released to IANA for inclusion in the root zone until an operational test and assessment have been completed. Essentially, the .mil domain will remain an island (for DNSSEC purposes) during this phase. The third and final phase will consist of submitting the .mil key to IANA for publication in the Internet root zone to allow Internet-wide validation of .mil DNS responses. Tentative timeline to a signed .mil zone: Sep 14-Sep 18 .mil zone signed with an unvalidatable key Sep 19-Dec 11 .mil zone signed with an unpublished, validatable key Dec 12 .mil zone signed, and its DS record is included in the root zone This rollout is expected to be transparent to the Internet user community, however, if there are issues during this period, please contact the DoD NIC at 1-800-365-3642; +1 614-692-2708. Thank you, DoD NIC Administration smime.p7s Description: S/MIME cryptographic signature
Mailing list/group for datacenter facilities folks
Just wondering, Is anyone aware whether there is already an active mailing list/group for datacenter facilities folks to discuss power, cooling, physical infrastructure, etc, etc...? thanks, -Drew
Re: iCloud - Is it going to hurt access providers?
Most networks have been trying to avoid that, building out a quarterly pop thing,... problem is now its an ongoing cumulative quarterly pop across many years, With pent up frustrated consumer demand for more and more videoincluding face time on these apple devices! Iridescent iPhone +1 972 757 8894 On 7 Sep 2011, at 11:40, Joel jaeggli wrote: > On 9/7/11 09:37 , valdis.kletni...@vt.edu wrote: >> On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said: >> >>> The way to achieve a return on invested capital is to attract and retain >>> customers who pay for a service which they find compelling. >> >> Only true if long-term returns on investment are suitable for consideration >> instead of short-term returns. > > When was the last time you built out a network plant for a quarterly pop? > >
Re: NANOGers home data centers - What's in your closet?
Friends of mine recently bought a large traditionally-designed house. The former "servant's quarters" are now the server room.
Re: NAT444 or ?
On Wed, Sep 07, 2011 at 01:06:11PM -0400, jean-francois.tremblay...@videotron.com wrote: > I had the same question. I found Miyakawa-san's presentation has some > dramatic examples of CGN NAT444 effects using Google Maps: > http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf > Those effects are not specific to NAT444, but apply to any provider-based NAT limiting the amount of parallel sessions available to any one customer. Randy was (as I understood him) referring to the evilness of double-NAT in contrast to single-state NAT (as used with e.g. DS-Lite). Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: NAT444 or ?
On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: > > I'm going to have to deploy NAT444 with dual-stack real soon now. > you may want to review the presentations from last week's apnic meeting > in busan. real mesurements. sufficiently scary that people who were > heavily pushing nat444 for the last two years suddenly started to say > "it was not me who pushed nat444, it was him!" as if none of us had a > memory. > > Hm, I fail to find relevant slides discussing that. Could you please > point us to those? I had the same question. I found Miyakawa-san's presentation has some dramatic examples of CGN NAT444 effects using Google Maps: http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf However these are with a very high address-sharing ratio (several thousands users per address). Using a sparser density (<= 64 users per address) is likely to show much less dramatic user impacts. /JF
Re: iCloud - Is it going to hurt access providers?
On Wed, Sep 7, 2011 at 9:28 AM, Joel jaeggli wrote: > On 9/7/11 09:02 , Michael Holstein wrote: >> >>> I would love a world where engineering was consulted by marketing :( >>> >> >> Wouldn't be a problem is management invested based on engineering's >> recommendations. >> >> There are few problems that money can't solve .. in this case, it's >> "sure, we can offer unlimited bandwidth, we just need to build (x) new >> towers at this map of locations, based on our usage patterns". > > The way to achieve a return on invested capital is to attract and retain > customers who pay for a service which they find compelling. Good simplification, but i think this thread is about the word "pay" who and how much.
Re: iCloud - Is it going to hurt access providers?
On 9/7/11 09:37 , valdis.kletni...@vt.edu wrote: > On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said: > >> The way to achieve a return on invested capital is to attract and retain >> customers who pay for a service which they find compelling. > > Only true if long-term returns on investment are suitable for consideration > instead of short-term returns. When was the last time you built out a network plant for a quarterly pop?
RE: NAT444 or ?
> -Original Message- > From: Daniel Roesen [mailto:d...@cluenet.de] > Sent: 07 September 2011 17:38 > To: nanog@nanog.org > Subject: Re: NAT444 or ? > > On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: > > > I'm going to have to deploy NAT444 with dual-stack real soon now. > > > > you may want to review the presentations from last week's apnic > meeting > > in busan. real mesurements. sufficiently scary that people who were > > heavily pushing nat444 for the last two years suddenly started to say > > "it was not me who pushed nat444, it was him!" as if none of us had > a > > memory. > > Hm, I fail to find relevant slides discussing that. Could you please > point us to those? > > I'm looking at http://meetings.apnic.net/32 > > Best regards, > Daniel There is a lot in the IPv6 plenary sessions: http://meetings.apnic.net/32/program/ipv6 This is what I am looking at right now. Randy makes some good comments in those sessions. I have not found anything yet, but I am only on session 3, pertaining specifically to issues around NAT444. I would be looking for issues such as implementing ALGs on both NAT devices, ALG scaling on LSN boxes and issues surrounding application compatibility. I'm also looking at NAT logging for law enforcement issues. Is there anything planned for the next NANOG around these issues? -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: NAT444 or ?
On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: > > I'm going to have to deploy NAT444 with dual-stack real soon now. > > you may want to review the presentations from last week's apnic meeting > in busan. real mesurements. sufficiently scary that people who were > heavily pushing nat444 for the last two years suddenly started to say > "it was not me who pushed nat444, it was him!" as if none of us had a > memory. Hm, I fail to find relevant slides discussing that. Could you please point us to those? I'm looking at http://meetings.apnic.net/32 Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: iCloud - Is it going to hurt access providers?
On Wed, 07 Sep 2011 09:28:28 PDT, Joel jaeggli said: > The way to achieve a return on invested capital is to attract and retain > customers who pay for a service which they find compelling. Only true if long-term returns on investment are suitable for consideration instead of short-term returns. pgpEtq4TlrMWQ.pgp Description: PGP signature
Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates
On Wednesday 07 Sep 2011 17:17:10 Network IP Dog wrote: > FYI!!! > > http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee > ms_all_diginotar_certificates_untrust.html > > Google and Mozilla have also updated their browsers to block all DigiNotar > certificates, while Apple has been silent on the issue, a emblematic zombie > response! > > Cheers. > It would be really nice if the folk at Twitter would fix their images servers (i.e si*.twimg.com) to use a non-evil CA (i.e. not Comodo or DigiNotar or Bubba Gump's Bait, Firearms & Crypto Verification). Not that user pics are a great loss, but if you use Tweetdeck/Seesmic/whatever, the constant SSL cert warnings from dozens- to-hundreds of user pics are noisy. This is trivial whining on my part but it is operational. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
Re: iCloud - Is it going to hurt access providers?
On 9/7/11 09:02 , Michael Holstein wrote: > >> I would love a world where engineering was consulted by marketing :( >> > > Wouldn't be a problem is management invested based on engineering's > recommendations. > > There are few problems that money can't solve .. in this case, it's > "sure, we can offer unlimited bandwidth, we just need to build (x) new > towers at this map of locations, based on our usage patterns". The way to achieve a return on invested capital is to attract and retain customers who pay for a service which they find compelling. > Michael Holstein > Cleveland State University > >
Microsoft deems all DigiNotar certificates untrustworthy, releases updates
FYI!!! http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee ms_all_diginotar_certificates_untrust.html Google and Mozilla have also updated their browsers to block all DigiNotar certificates, while Apple has been silent on the issue, a emblematic zombie response! Cheers.
Re: iCloud - Is it going to hurt access providers?
> I would love a world where engineering was consulted by marketing :( > Wouldn't be a problem is management invested based on engineering's recommendations. There are few problems that money can't solve .. in this case, it's "sure, we can offer unlimited bandwidth, we just need to build (x) new towers at this map of locations, based on our usage patterns". Michael Holstein Cleveland State University
Re: DDoS - CoD? - Activision contact
On 9/6/2011 6:02 AM, BH wrote: Looking around, I believe the issue is that the IP has ended up on a master game list, so we are now getting the queries directed at US. Having written multiple versions of a Quake III master server (again, much self-hate) I pulled one of my old master query scripts out of mothballs and checked. You are not listed on the CoD4 master server (assuming you did not alter the UDP frames you originally posted). If you were you would be seeing "getInfo" and "getStatus" queries, but you're not. You're seeing the "getInfoResponse" and "getStatusResponse" packets from a server which is listed on the master server. This is an attack, nothing sinister is happening. Your best bet is to filter all UDP traffic except for what you need (DNS comes to mind). You might also want to get in contact with killku...@hotmail.com and encourage them to install the previously mentioned patched server executable to prevent their server from being used as an attack amplifier. -- Jeff Walter Network Engineer Hurricane Electric <>
RE: NAT444 or ?
> -Original Message- > From: Randy Bush [mailto:ra...@psg.com] > Sent: 07 September 2011 11:18 > To: Leigh Porter > Cc: North American Network Operators' Group > Subject: Re: NAT444 or ? > > > I'm going to have to deploy NAT444 with dual-stack real soon now. > > you may want to review the presentations from last week's apnic meeting > in busan. real mesurements. sufficiently scary that people who were > heavily pushing nat444 for the last two years suddenly started to say > "it was not me who pushed nat444, it was him!" as if none of us had a > memory. > > randy > Thankyou, I'm watching it now, but I am under no illusion that it will work well. NAT44 is bad enough. -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: NAT444 or ?
> I'm going to have to deploy NAT444 with dual-stack real soon now. you may want to review the presentations from last week's apnic meeting in busan. real mesurements. sufficiently scary that people who were heavily pushing nat444 for the last two years suddenly started to say "it was not me who pushed nat444, it was him!" as if none of us had a memory. randy
RE: NAT444 or ?
> -Original Message- > From: Arturo Servin [mailto:arturo.ser...@gmail.com] > Sent: 07 September 2011 01:37 > To: Serge Vautour > Cc: nanog@nanog.org > Subject: Re: NAT444 or ? > > > NAT444 alone is not enough. > > You will need to deploy it along with 6rd or DS-lite. > > Whilst you still have global v4, use it. The best is to deploy > dual-stack, but that won't last for too long. > > Regards, > as- I'm going to have to deploy NAT444 with dual-stack real soon now. So I am expecting to see some issues. A+P would be nicer perhaps, but none of the CPE I have will support it. I'll try and give people who do NAT in their CPE a public address for as long as I can, but it'll soon run out and then NAT444 will have to be used and some things will just not work very well. -- Leigh Porter __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: NAT444 or ?
> In a typical DS-Lite deployment you won't be using NAT444. One of the > key advantages of DS-Lite (and A+P, I believe) is that there's only one > level of NAT between the end user and the public internet. yep. and in ds-lite that nat is in the core, so you talk to comcast's lawyers when you need a new alg. with a+p, the nat is under customer control, and they just go to best buy to get the cpe that supports the alg that they want. randy
Re: NAT444 or ?
* Arturo Servin > NAT444 alone is not enough. > > You will need to deploy it along with 6rd or DS-lite. In a typical DS-Lite deployment you won't be using NAT444. One of the key advantages of DS-Lite (and A+P, I believe) is that there's only one level of NAT between the end user and the public internet. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com