Re: IPv6 internet broken, cogent/telia/hurricane not peering

On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > And tonight we saw in public that even that path is being attempted: > > http://www.flickr.com/photos/77519...@n00/4031434206/ > > (and yes, it was yummy and enjoyed by all at the peering BoF!) > > So Cogent...won't you please mak

Re: ISP customer assignments

On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote: > > On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: > > >In practice, changing stuff, especially globally, is not as simple > >as that. > > From : > > 'Some took it on themselves to convince the

Re: IPv6 internet broken, cogent/telia/hurricane not peering

On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen wrote: > On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote: > > And tonight we saw in public that even that path is being attempted: > > > > http://www.flickr.com/photos/77519...@n00/4031434206/ > > > > (and yes, it was yummy an

[NANOG-announce] Elections - polls close within the hour!

Hey folks, Just a reminder that the NANOG Election polls will be closing at 09.15 EDT. If you are listed here http://www.nanog.org/governance/elections/2009elections/2009_voters.php you can vote, no matter where in the world you are. Ballot is here: https://nanog.merit.edu/election/ MLC nomina

2009.10.21 NANOG47 day 3 notes

And last, but not least, here's the notes from the morning part of the NANOG meeting. I strongly, STRONLY suggest people read Aaron's IPv6 deployment in a nutshell slides; while I differ from him on some of the thoughts around address allocation schemes for very large networks, for small to midsiz

Consistent asymetric latency on monitoring?

Although the implementation is Cisco-specific, this feels more appropriate for NANOG. We've started rolling out a state-wide monitoring system based on Cisco's "IP SLA" feature set. Out of 5 sites deployed so far (different locations, different providers), we are consistently seeing one-way laten

Re: 2009.10.21 NANOG47 day 3 notes

Regarding: http://nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fundamentals_N47_Wed.pdf Very common misconception for the "ipv6 enable" interface config statement for IOS on slides 19, 21, etc. The "ipv6 enable" statement is only necessary to enable IPv6 on an interface if y

CRTC rules on Traffic Management Practices

For those following the regulatory / net neutrality debate, the Canadian Radio and Telecommunications Commission released this morning a decision requiring additional transparency with respect to the traffic management practices of Canadian service providers. News Release: http://www.crtc.gc.ca/e

Re: CRTC rules on Traffic Management Practices

Holy Hannah! ISP actions affecting content According to the Telecommunications Act, a telecommunications company must obtain the Commission’s prior approval to “control the content or influence the meaning or purpose of telecommunications” carried over its network. The Commission does not consi

Re: 2009.10.21 NANOG47 day 3 notes

Matt, On 2009-10-21, at 10:54, Matthew Petach wrote: And last, but not least, here's the notes from the morning part of the NANOG meeting. As someone who had to disappear early from the meeting for various reasons, your notes are fabulously useful (much better than video archives, for me,

Re: CRTC rules on Traffic Management Practices

On 2009-10-21, at 12:03, Michael Peddemors wrote: The email marketing lobby already got the legislation watered down on the spam front, but does this in essence say that ISP's are no longer allowed to block email content, viruses et al? No more null-routing targets in your own network as

Re: CRTC rules on Traffic Management Practices

Realistically this has to do with one main thing, traffic throttling (Mainly of bittorrent and other p2p applications). In previous decisions and hearings they discussed at length the management of networks in regards to spam and viruses. These have nothing to do with what this ruling is about an

Re: CRTC rules on Traffic Management Practices

On 2009-10-21, at 12:14, Joe Abley wrote: On 2009-10-21, at 12:03, Michael Peddemors wrote: The email marketing lobby already got the legislation watered down on the spam front, but does this in essence say that ISP's are no longer allowed to block email content, viruses et al? No more

Re: CRTC rules on Traffic Management Practices

Tim Lampman wrote: Realistically this has to do with one main thing, traffic throttling (Mainly of bittorrent and other p2p applications). In previous decisions and hearings they discussed at length the management of networks in regards to spam and viruses. These have nothing to do with what t

Re: CRTC rules on Traffic Management Practices

Joe Maimon wrote: Tim Lampman wrote: Realistically this has to do with one main thing, traffic throttling (Mainly of bittorrent and other p2p applications). In previous decisions and hearings they discussed at length the management of networks in regards to spam and viruses. These have nothin

ISP/VPN's to China?

I have a client in the US looking to connect up an office in China and I'm wondering what type of connections are avilable and wether IPSEC VPNs can be established through the 'Great firewall of China'. I talked to a China Telcom rep in the US that says that the network congestion even in Chin

Re: ISP/VPN's to China?

I travel to China at least once a year, often several times. I generally visit major cities like Shanghai and Beijing, but have been to a number of other cities. I generally use Cisco VPN (an IPsec VPN) to Cisco DMZs in Tokyo or Hong Kong for business purposes. As with hotels in other parts

Re: CRTC rules on Traffic Management Practices

Tim Lampman wrote: Joe Maimon wrote: In that scenario, a broadband user who is a customer of Mom'N'Pop ISP is getting throttled by a third party providing a L2 backhaul. From what you have posted, this would now require prior approval. As I feel strongly that this behavior is quite wrong

Re: ISP/VPN's to China?

Hi, if you're talking about Mainland China in general (not Hong Kong specifically), indeed IPSEC VPN may not provide desired level of service. During the time I spent there, we opted for: - CNC MPLS for 4 sites in China - Equant MPLS between Beijing and other worldwide sites - Then replaced at

Re: IPv6 Deployment for the LAN

On 18 okt 2009, at 5:51, Karl Auer wrote: Do the advertisements "right", advise sysadmins that hosts should not do SLAAC, Doesn't it tell you something that you're fighting this hard to avoid hosts from doing what comes naturally? It occurs to me that I haven't met anyone who uses the te

Re: IPv6 Deployment for the LAN

On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. And DHCPv6 is just

Re: IPv6 Deployment for the LAN

Iljitsch, On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 10:03, Andy Davidson wrote: >> Support default-routing options for DHCPv6 ! > This would be a big mistake. [...] It's time for this DHC stuff to reach its > final resting place. I'm curious: are you anticipa

Re: ISP/VPN's to China?

Very interesting rundown of current infrastructure option -- thanks! On Oct 21, 2009, at 3:14 PM, Benjamin Billon wrote: Hi, if you're talking about Mainland China in general (not Hong Kong specifically), indeed IPSEC VPN may not provide desired level of service. During the time I spent t

Re: 2009.10.21 NANOG47 day 3 notes

Ray Soucy wrote: Would be a good idea to stop spreading the false assumption that "ipv6 enable" determines whether or not IPv6 is active on an interface. Play with IPv6 and is-is enough on a Cisco router, and you'll enable it as a matter of practice too. It's the definitive way to say "yes, t

Re: IPv6 Deployment for the LAN

On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packet

Re: IPv6 Deployment for the LAN

On 21 okt 2009, at 21:50, David Conrad wrote: On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place

Re: IPv6 Deployment for the LAN

I respectfully disagree. In my opinion there is no future for IPv6 that doesn't involve DHCPv6. DHCPv6 is part of the design of IPv6 as is clear by the existence of M, O, and A flags in RA. Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 w

Re: IPv6 Deployment for the LAN

On 21 okt 2009, at 21:55, Owen DeLong wrote: However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level. For the same reason that

Re: IPv6 Deployment for the LAN

On Oct 21, 2009, at 1:08 PM, Ray Soucy wrote: Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 was designed in a way where SLAAC could be used for addressing and DHCPv6 for "other" configuration is an example of how DHCPv6 is an integral c

Re: IPv6 Deployment for the LAN

Once upon a time, Iljitsch van Beijnum said: > What we need is a thing that gives us what we need to > connect to the network (addresses, DNS servers) and then a pointer in > the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration m

Re: IPv6 Deployment for the LAN

On 21 okt 2009, at 22:23, Chris Adams wrote: What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration managem

[DHCPv6] was Re: IPv6 Deployment for the LAN

We have networks and businesses to run. Why are we rehashing this yet again? For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html shows messages regarding exactly this issue. for emphasis I redundantly requote, "You have seen this before from me: Cons

Re: IPv6 Deployment for the LAN

What we have now is not a mess. What we have is a solid base to build on. The problem is in education, the fact that both stateless and stateful configuration are valid components to IPv6 for example, and proper implementation by vendors. There are a few challenges with IPv6 that need to be work

Re: IPv6 Deployment for the LAN

On Oct 21, 2009, at 1:08 PM, Iljitsch van Beijnum wrote: On 21 okt 2009, at 21:55, Owen DeLong wrote: However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent th

Re: IPv6 Deployment for the LAN

On Oct 21, 2009, at 1:05 PM, Iljitsch van Beijnum wrote: On 21 okt 2009, at 21:50, David Conrad wrote: On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It'

Re: IPv6 Deployment for the LAN

- Original Message >From: Iljitsch van Beijnum iljit...@muada.com >Then again, if we remove all the improvements from IPv6 what's the point of >adopting it? How about "IPv4 address depletion?" I'm perfectly happy with how my network works.  I do, however, want it to keep growing, and t

equinix is acquiring switch & data

http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant.

Re: IPv6 Deployment for the LAN

Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than

Re: IPv6 Deployment for the LAN

I am replying to several people here in one message. I think most issues were covered fairly well, but I obviously like to hear myself talk, and I think there are a few things that need to be said more plainly (I hope). On Sat, Oct 17, 2009 at 08:55:28PM -0400, Ray Soucy wrote: > Looking for gen

Re: ISP customer assignments

On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart wrote: ... If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. As I was told by Cisco, that's a security "feature". Fixed VPN endpoi

Re: IPv6 Deployment for the LAN

On Wed, 2009-10-21 at 21:42 +0200, Iljitsch van Beijnum wrote: > On 18 okt 2009, at 5:51, Karl Auer wrote: > > Do the advertisements "right", advise sysadmins that hosts should > > not do SLAAC, > > Doesn't it tell you something that you're fighting this hard to avoid > hosts from doing what c

Re: ISP/VPN's to China?

At 02:16 PM 10/21/2009, Fred Baker wrote: I travel to China at least once a year, often several times. I generally visit major cities like Shanghai and Beijing, but have been to a number of other cities. I generally use Cisco VPN (an IPsec VPN) to Cisco DMZs in Tokyo or Hong Kong for business pur

Re: ISP/VPN's to China?

OpenVPN is ideal. It functions purely over application-level UDP transport (IP-IP) instead of using GRE/IPSec/other encapsulation protocols that could potentially be blocked by a protocol filter on a router. Route that traffic to a server outside of China and NAT it out to the rest of the Int

Re: equinix is acquiring switch & data

I had a S&D rep at a convention recently tell me that their prices were much more competitive than Equinix. I guess that's about to be out the window. Jeff On Wed, Oct 21, 2009 at 4:42 PM, Cord MacLeod wrote: > http://www.equinix.com/news/press/na/2009/news-5109/ > > Thought this was relevant.

Re: equinix is acquiring switch & data

On 2009-10-21, at 19:44, Jeffrey Lyon wrote: I had a S&D rep at a convention recently tell me that their prices were much more competitive than Equinix. I guess that's about to be out the window. I imagine the general practice of ${vendor1} reps telling potential customers that their pri

Re: IPv6 Deployment for the LAN

On Wed, Oct 21, 2009 at 10:08:13PM +0200, Iljitsch van Beijnum wrote: > On 21 okt 2009, at 21:55, Owen DeLong wrote: > > >However, making it available as an option in DHCPv6 allows the end- > >user/operator > >to choose the technology that fits their needs best. I do not know > >why you are so

Re: ISP/VPN's to China?

On Oct 21, 2009, at 4:36 PM, Alex Balashov wrote: It is precisely because the traffic has no signature distinguishable from normal application traffic oh my goodness. You're behind on your reading...

Re: ISP/VPN's to China?

Fred Baker wrote: On Oct 21, 2009, at 4:36 PM, Alex Balashov wrote: It is precisely because the traffic has no signature distinguishable from normal application traffic oh my goodness. You're behind on your reading... I didn't mean DPI. I meant in a way that can be inferred from the head

Re: IPv6 Deployment for the LAN

On Wed, 2009-10-21 at 14:34 -0700, David W. Hankins wrote: > folks on this mailing list who have proposed you can predict SLAAC > addresses based on prefix and MAC are confused; they are not taking > into account the many clients that use temporary addresses by default > when the A flag is set (the

Re: IPv6 Deployment for the LAN

What it does deprive them of, with increasing layers of NAT or proxy service, is "dial-in" access. Many do not require this feature. The cost of providing it is increased support costs; debugging two networks and three or four protocols. Today, even debugging IPv4 problems with customers is p

Re: ISP/VPN's to China?

On Wed, Oct 21, 2009, Alex Balashov wrote: > >oh my goodness. You're behind on your reading... > > I didn't mean DPI. I meant in a way that can be inferred from the > headers themselves, and aside from the port number. You don't think that statistical analysis of traffic patterns of your UDP t

Re: Consistent asymetric latency on monitoring?

Rick Ernst wrote: Although the implementation is Cisco-specific, this feels more appropriate for NANOG. We've started rolling out a state-wide monitoring system based on Cisco's "IP SLA" feature set. Out of 5 sites deployed so far (different locations, different providers), we are consistently

Re: Consistent asymetric latency on monitoring?

On 22/10/2009, at 2:31 PM, Perry Lorier wrote: I assume this product works by having a packet with a timestamp sent from the source to the destination where it is timestamped again and either sent back, or another packet is sent in the other direction. The difference between the two timest

Re: ISP/VPN's to China?

I was not aware that tools or techniques to do this are widespread or highly functional in a way that would get them adopted in an Internet access control application of a national scope. Tell me more? -- Sent from mobile device On Oct 21, 2009, at 9:27 PM, Adrian Chadd wrote: On Wed,

Re: ISP/VPN's to China?

On Wed, Oct 21, 2009, Alex Balashov wrote: > I was not aware that tools or techniques to do this are widespread or > highly functional in a way that would get them adopted in an Internet > access control application of a national scope. > > Tell me more? It's been a while since I tinkered wit

Re: ISP customer assignments

In message , "Ricky Beam" writes: > On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart > wrote: > > ... If you've got a VPN tunnel device, too often the remote > > end will want to contact you at some numerical IPv4 address and isn't > > smart enough to query DNS to get it. > > As I was told by

Re: Consistent asymetric latency on monitoring?

Resent, since I responded from the wrong address: --- The basic operation of IP SLA is as surmised; payload with timestamps and other telemetry data is sent to a 'responder' which manipulates the payload, including adding its own timestamps, and returns the altered payload. I had to do a mental wa

Re: NetFlow analyzer software

Jeffrey Negro wrote: > Yes my experience was the same on with Manage Engine. Although, they do have > an article buried in their archives that shows how to tweak the mysql and > java memory settings on start of the app. We found that helped a bit. We > were successfully using it for netflows

Re: Consistent asymetric latency on monitoring?

On Wed, 21 Oct 2009, Rick Ernst wrote: Has anybody seen this type of behavior? We are solidly convinced that we are using the proper OIDs and making the proper transformations of the data. The two remaining causes appear to be either "natural behavior of the links" and/or "artifact in the IP S

Re: ISP/VPN's to China?

They exist and for certain applications are pretty effective. On Oct 21, 2009, at 6:47 PM, Alex Balashov wrote: I was not aware that tools or techniques to do this are widespread or highly functional in a way that would get them adopted in an Internet access control application of a national

Re: Consistent asymetric latency on monitoring?

Rick Ernst wrote: Resent, since I responded from the wrong address: --- The basic operation of IP SLA is as surmised; payload with timestamps and other telemetry data is sent to a 'responder' which manipulates the payload, including adding its own timestamps, and returns the altered payload.