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 make nice with HE.net and get back together again? ^_^ Matt (speaking for neither party, but very happy to eat cake nonetheless) Cogent Pleas IPv6... for some reason that cake typo is even funnier than the correct version. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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 http://tools.ietf.org/html/rfc4192: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' We tried Fred's procedure some 4 years ago within 6NET: http://www.6net.org/publications/deliverables/D3.6.2.pdf The 'prefix schizo' actually worked out quite well. The routing changes and multi-refix links generally behaved as expected. Address selection did its thing. The basics worked as advertised. The complexity is of course not in the routing and hosts, it's as pointed out in the firewalls and similar devices (yours and more importantly other people's) for which new capabilities of IPv6 can't help. We captured some of these thoughts at the time in http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05 and since then Brian Carpenter has produced a much more up to date and rounded set of thoughts in http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03 We're far from a magic button press. In smaller networks RFC4192 is workable, but the larger and more complex the network/site, there's still so many open issues that it's completely understandable the people will want PI. -- Tim
Re: IPv6 internet broken, cogent/telia/hurricane not peering
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen r...@e-gerbil.netwrote: 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 make nice with HE.net and get back together again? ^_^ Matt (speaking for neither party, but very happy to eat cake nonetheless) Cogent Pleas IPv6... for some reason that cake typo is even funnier than the correct version. :) And now even better shots of the cake have been forthcoming from people. :) http://www.flickr.com/photos/77519...@n00/4031195041/ (I was all the way at the far other end of the room taking notes on the laptop, so I never got to see the cake intact at all--all the photos are from others who were closer to the cake, and got to see it in its pristine glory). Fortunately, I did get to partake in the eating of it. ^_^ Matt (This cake is great, it's so delicious and moist...* ;) *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
[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 nominations will remain open until 29 Octobe: http://www.nanog.org/governance/elections/2009elections/2009mlc_candidates.php For thos at the meeting *or* watching the streams, take the survey! http://tinyurl.com/nanog47/ Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ NANOG-announce mailing list nanog-annou...@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
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 midsized networks, it's a very, very good cookbook to follow for getting IPv6 rolled out: http://nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fundamentals_N47_Wed.pdf Thanks to everyone for participating, both locally and remotely! subsequent ARIN notes will be posted to ppml list. Matt 2009.10.21 NANOG47 Wednesday morning notes Don't forget to fill out your survey!! http://tinyurl.com/nanog47 Dave Meyer welcomes everyone back from their hangovers at 0904 hours Eastern Time. John Curran isn't here, so he misses his 13 minutes of fame, and we go straight over to Mark Kosters. Mark Kosters, IPv6: Emerging stories of success. A stellar panel of people to talk about transitioning to v6. IPv4 is running out; in 2 years or so, we'll no longer have a flow of addresses from IANA to the RIRs. But why isn't more traffic moving onto IPv6, given the imminent runout? Still less than 1% of the overall traffic. What do you need to do to make the move to v6, from the enterprise and ISP viewpoint? John B, comcast Matt R, ARIN Owen DeLong, HE.net Aaron Hughes, 6connect John B from comcast is up first Native, dual stack core and access networks started as means to leverage device management; then moved to subscriber access service. Backoffice, where applicable, also dual stack Cable modems (DOCSIS) single stack v4 or v6 eMTAs remain v4 eSTBs targeted to support v4 or v6 only Native dual-stack subscriber services Leverage well known transition technologies to enable enterprise desktop IPv6 connectivity. Some of the backoffice pieces, like DHCP, are still evolving. This is a team organizational effort, so it takes many pieces working together. Core concept--intial key piece was device management. Core network, access network, and back office systems all have to work together, or the program fails. So, the iteratively extend those three elements to offer services over IPv6 Native is preferred whenever possible over tunnels and other techniques; but sometimes it's just not possible. There's still much learning to happen in the area to figure out how best to make the deployment happen. Lessons Learned IPv6 must become business as usual for staff from every area of business lack of attention here be be problematic for v6 deployment deferring or avoiding IPv6 will be problematic. it's really, REALLY important to do large scale testing of interoperability, especially when you have millions of devices. You test the key interconnect points where devices interact, especially with high levels of diversity in your gear. Also leverages technologies that newer releases, like DOCSIS3.0 provide. Find opportunties like that in your own environment. Challenges Need to manage the deployment of v6 relative to other business needs. channel bonding vs v6, which gets business priority, for example Security on v6 is still a challenge vendors often say but you're the only one who has asked for that backoffice and tool upgrades to support IPv6 are non-trivial best approach is to divide these efforts into smaller activities. Very substantial chunk of work; don't underestimate the challenges of this! IPv6 data services for subscribers. preferred approach is to offer native dual-stack v6 service to customers; v4 continues unchanged, just adds v6. Directly connected device that supports v6, or home gateway device that supports v6. all the support systems must support both models for the rollout to work. Most people in the room use a gateway device at home. most home gateway devices don't support v6 yet, so pushing the retail type devices to support v6 natively, off the shelf is a challenge. Challenges associated with routing for delegated v6 prefixes should be uniformly addressed. Support for v6 in many products is still considered 'new' and isn't as mature as v4. testing and interoperability are critical for successful deployment bugs and issues will arise scale makes a difference! deploying IPv6 must not impact existing services (this is pretty much true for everyone--can't break existing customers!) Content and Services availability of content and services over IPv6 to date appears to be lacking simply having v6 connectivity isn't sufficient john_brzowo...@cable.comcast.com Matt Ryanczak, network ops manager at ARIN History of IPv6 @ARIN They're a small, 50 person multihomed customer network. Their network has been running IPv6 since 2003, with a beta Sprint circuit. it was a T1 line, appeared native, but was tunneled inside Sprint. v6 internet wasn't well connected. 2004 Worldcom circuit, similar issue. Started connecting to exchange points, got transit there, and is now starting to
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 latency mirror the opposite direction. As source-destination latency goes up, destination-source latency goes down and vice versa. Myself and the monitoring team have ripped apart the OIDs, IP SLA configuration, and monitoring system. We've also built an ad-hoc system to compare the results. It's still consistent behavior. It's not a true mirror; there is definitely variation between the data collection, but at the 10,000 foot level, there is an obvious and consistent mirror to the data. The network topology is independant service providers all providing backhaul to a local ethernet exchange. 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 SLA mechanism. Any ideas? Thanks!
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 you are not assigning it an IPv6 address (e.g. this will simply enable IPv6 with a LL address). Otherwise it is useless. Would be a good idea to stop spreading the false assumption that ipv6 enable determines whether or not IPv6 is active on an interface. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
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/eng/NEWS/RELEASES/2009/r091021.htm Policy Details: http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm Jeff Gallagher Network Engineering jeff.gallag...@bellaliant.ca
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 consider such disruptive actions to be proper Internet traffic management practices, and they will always require prior approval. An ISP would therefore need to seek the Commission’s approval before it implemented a practice that would: block the delivery of content to an end-user, or slow down time-sensitive traffic, such as videoconferencing or Internet telephone (Voice over Internet Protocol) services, to the extent that the content is degraded. When faced with these requests, the Commission will only grant its approval in the most exceptional cases. 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? On October 21, 2009, Jeff Gallagher wrote: 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/eng/NEWS/RELEASES/2009/r091021.htm Policy Details: http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm Jeff Gallagher Network Engineering jeff.gallag...@bellaliant.ca -- -- Catch the Magic of Linux... Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com A Wizard IT Company - For More Info http://www.wizard.ca LinuxMagic is a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
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, in fact). Many thanks once again for taking the time to make them. (followups set) Joe
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 a DDoS mitigation technique? Joe
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 and they stated that there is a clear distinction between managing spam and viruses and management of traffic for specific applications. This ruling really doesn't amount to much at this point as bell, rogers, shaw, cogeco etc will all still throttle whatever they want, whenever they want without much regard for the rulings of the CRTC. They ignore many other rulings every day, why would this one be any different. Michael Peddemors wrote: 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 consider such disruptive actions to be proper Internet traffic management practices, and they will always require prior approval. An ISP would therefore need to seek the Commission’s approval before it implemented a practice that would: block the delivery of content to an end-user, or slow down time-sensitive traffic, such as videoconferencing or Internet telephone (Voice over Internet Protocol) services, to the extent that the content is degraded. When faced with these requests, the Commission will only grant its approval in the most exceptional cases. 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? On October 21, 2009, Jeff Gallagher wrote: 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/eng/NEWS/RELEASES/2009/r091021.htm Policy Details: http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm Jeff Gallagher Network Engineering jeff.gallag...@bellaliant.ca -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *c.* 905-746-3114 www.broadlinenetworks.com http://www.broadlinenetworks.com/ | t...@broadlinenetworks.com mailto:t...@broadlinenetworks.com
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 null-routing targets in your own network as a DDoS mitigation technique? Some better-informed person dropped me a note off-list, pointing me to the following. On the face of it it seems like consideration for this aspect has already been incorporated into the ruling. ITMPs used for network security or employed temporarily to protect network integrity 44. The Commission notes that Canadian ISPs have used certain ITMPs for the purposes of network security and integrity. Specifically, these ITMPs have been employed to protect users from network threats such as malicious software, spam, and distribution of illicit materials. In the Commission's view, such activities are unlikely to trigger complaints or concerns under the Act and are a necessary part of an ISP's network operations. 45. The Commission is therefore not addressing, in this decision, ITMPs used only for the purpose of network security, nor those employed temporarily9 to address unpredictable traffic events (e.g. traffic surges due to global events and failures on part of an ISP's network) in order to protect network integrity.
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 this ruling is about and they stated that there is a clear distinction between managing spam and viruses and management of traffic for specific applications. This ruling really doesn't amount to much at this point as bell, rogers, shaw, cogeco etc will all still throttle whatever they want, whenever they want without much regard for the rulings of the CRTC. They ignore many other rulings every day, why would this one be any different. The issue that interests me most is the reputed filtering and throttling performed by these companies for broadband L2 connections backhauled to ISP's doing the L3 on them, such as with ATM or L2TP. 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 and should not happen, I am encouraged by these rules. Joe
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 nothing to do with what this ruling is about and they stated that there is a clear distinction between managing spam and viruses and management of traffic for specific applications. This ruling really doesn't amount to much at this point as bell, rogers, shaw, cogeco etc will all still throttle whatever they want, whenever they want without much regard for the rulings of the CRTC. They ignore many other rulings every day, why would this one be any different. The issue that interests me most is the reputed filtering and throttling performed by these companies for broadband L2 connections backhauled to ISP's doing the L3 on them, such as with ATM or L2TP. 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 and should not happen, I am encouraged by these rules. Joe It would appear this is how it should be, however the track record of Bell heeding the CRTC's rulings has not been good. Last year Bell was ordered to offer matching speeds to their wholesale GAS customers to that of their retail offerings, they simply never complied. This ruling only applies to time sensitive traffic, most of which Bell does not currently throttle. While I think most people would agree that its completely wrong to throttle the traffic of a third party wholesale customer, the reality is that Bell does this every day and will continue to do so regardless of what the CRTC tells them. -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *c.* 905-746-3114 www.broadlinenetworks.com http://www.broadlinenetworks.com/ | t...@broadlinenetworks.com mailto:t...@broadlinenetworks.com
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 China makes VPN's difficult. From their website, I see that the majority of the country is using xDSL, or 2MB dedicated lines. Can anyone shed any light on this topic? Thanks! ch...@chrisserafin.com
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 and should not happen, I am encouraged by these rules. Joe It would appear this is how it should be, however the track record of Bell heeding the CRTC's rulings has not been good. Last year Bell was ordered to offer matching speeds to their wholesale GAS customers to that of their retail offerings, they simply never complied. This ruling only applies to time sensitive traffic, most of which Bell does not currently throttle. While I think most people would agree that its completely wrong to throttle the traffic of a third party wholesale customer, the reality is that Bell does this every day and will continue to do so regardless of what the CRTC tells them. Disappointing, but at least it is not a step in the wrong direction.
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 high price Equant by Verizon MPLS in order to connect worldwide sites through Pacific links instead of Suez Canal - Then replaced Verizon by higher bandwidth Equant MPLS because Verizon's service was seriously bad. Not the link, but the service around it. At that time, Verizon used China Telecom as contractor, and I think Equant used CNC. Not sure about that, though. Between each site (Beijing to three others in China, and Beijing to others worldwide), there was backup IPSEC VPN set up just in case. Hopefully we didn't had to use them, because they was down from time to time and bandwidth was inconsistent. Great Firewall buddy is not to charge this time. ChrisSerafin a écrit : 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 China makes VPN's difficult. From their website, I see that the majority of the country is using xDSL, or 2MB dedicated lines. Can anyone shed any light on this topic? Thanks! ch...@chrisserafin.com
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 term SLAAC who uses IPv6 in a way that I would consider normal. (Or at all.)
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 a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place.
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 anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? Regards, -drc
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 there, we opted for: - CNC MPLS for 4 sites in China - Equant MPLS between Beijing and other worldwide sites - Then replaced at high price Equant by Verizon MPLS in order to connect worldwide sites through Pacific links instead of Suez Canal - Then replaced Verizon by higher bandwidth Equant MPLS because Verizon's service was seriously bad. Not the link, but the service around it. At that time, Verizon used China Telecom as contractor, and I think Equant used CNC. Not sure about that, though. Verizon = CT: also consistent with my memory (and an easy guess since there is no alternative) Equant = CNC: Perhaps you mean China Unicom =) TV Between each site (Beijing to three others in China, and Beijing to others worldwide), there was backup IPSEC VPN set up just in case. Hopefully we didn't had to use them, because they was down from time to time and bandwidth was inconsistent. Great Firewall buddy is not to charge this time. ChrisSerafin a écrit : 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 China makes VPN's difficult. From their website, I see that the majority of the country is using xDSL, or 2MB dedicated lines. Can anyone shed any light on this topic? Thanks! ch...@chrisserafin.com
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, this interface needs IPv6 active and I don't care if there's an address bound or not. I forget the exact circumstances, but I ran into several cases where I had undesired results and needed to manually enable IPv6 on an interface. Oh, and different versions of IOS behave differently towards IPv6. Imagine that. Jack
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 packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place. You keep arguing this and you're still wrong. There are very good reasons that some people need this in their real world networks. I'm happy for you that you don't need or want to run DHCPv6 in your environment. I'm somewhat happy for me that I almost don't need it in mine. 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. Owen
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. I'm curious: are you anticipating IPv4 network operators are willing/ interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? No. Hence the low IPv6 utilization. Then again, if we remove all the improvements from IPv6 what's the point of adopting it? The problem with DHCP is that it is an old answer to an even older question. Strangely, DHCPv6 is even worse in this regard than DCHPv4. Some protocol designers were clearly sleeping on the job there, or they were to busy getting in the way of those of us who wanted a non- DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is riddled with a badly specified way to interact with manual configuration and stateless autoconfig, it lacks a prefix length option and it has two modes, where the server knows which mode should be used but the client has to guess the right one. In this day and age it doesn't make an iota worth of sense to update binary protocols on two sides whenever there is something new to discover. 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. Of course that's not going to happen but taking stuff away from IPv6 that actually works (RA fate sharing) isn't going to solve the DHCPv6 problems.
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 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 component of IPv6. SLAAC was designed to make IPv6 work out of the box for ad-hoc networks (link local scope for example). It's increasingly clear that the designers never intended for SLAAC to replace DHCPv6 or that DHCPv6 wasn't a necessary part of IPv6, especially once you deploy it in an enterprise environment. What we've seen is a community of early adopters who are so eager to deploy IPv6 that they're willing to make compromises that most would question. I think we need to get into the mindset that any implementation of IPv6 that doesn't include a DHCPv6 client is as incomplete as one that doesn't support ICMPv6. Support from vendors will eventually fall into place. If more of the so-called advocates of IPv6 would stop talking about how DHCPv6 isn't necessary it would likely happen more quickly. Both SLAAC and DHCPv6 have their roles to fill; both are required. As for the use of the term SLAAC... it's usage is pretty widespread. On Wed, Oct 21, 2009 at 3:42 PM, Iljitsch van Beijnum iljit...@muada.com 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 comes naturally? It occurs to me that I haven't met anyone who uses the term SLAAC who uses IPv6 in a way that I would consider normal. (Or at all.) -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
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 we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA.
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 component of IPv6. Didn't RFC 4339 cover most of this? http://tools.ietf.org/html/rfc4339
Re: IPv6 Deployment for the LAN
Once upon a time, Iljitsch van Beijnum iljit...@muada.com 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 management? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
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 management? Short answer: no, life is too short and I have other problems that need solving. Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form.
[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: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Just in case the URL is faulty, here is the primary content of the referenced page of NANOG list history: And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of routers to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of routers with this non-network core data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of routers.) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell bickn...@xxx Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group na...@x Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - bickn...@xxx - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-requ...@, www.tmbg.org James R. Cutler james.cut...@consultant.com
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 worked out, like RA-gaurd and DHCPv6 snooping, for example, but the core of IPv6 was generally done right. Reading this thread can get rather frustrating, what I've gotten out of the most recent exchange is that the combined suggestion is to add DNS to RA, and to add gateway information to DHCPv6. Well, DHCPv6 already handles DNS quite nicely (and DHCPv6 is about more than just DNS mind you), and RA does a perfect job handling gateway selection. I would love to understand how you feel that the roles of RA and DHCPv6 should be swapped. On Wed, Oct 21, 2009 at 4:33 PM, Iljitsch van Beijnum iljit...@muada.com wrote: 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 management? Short answer: no, life is too short and I have other problems that need solving. Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
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 this choice at the operator level. For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA. You're incorporating a lot of assertions into your statement there. The assumption that the router knows it is correct for every host on a given LAN simply does not map to reality deployed today. DHCPv4 router assignments don't end in tears for the most part today, and, I don't think that DHCPv6 router assignment would be any more broken than the RA system. In many cases, it will be less broken. The assumption that all routers of a given priority are equal for all hosts on a given LAN also doesn't quite work out. DHCPv4 allows me to have multiple sets of VRRP addresses and balance my outbound routing from large LAN segments (imagine a /22 full of 10-g servers pushing ~6G each into a set of routers... Because they're a rendering farm, and the software is somewhat brain-dead, they need to be in the same broadcast domain.) (Yes, I know that broadcast goes away in IPv6, but, this can just as easily be a link-local multicast). With DHCPv4, I can assign different VRRP groups to the systems (with different IPv4 unicast addresses) based either on mac-addresses, or whatever other criteria I choose. Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Owen
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's time for this DHC stuff to reach its final resting place. I'm curious: are you anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? No. Hence the low IPv6 utilization. Then again, if we remove all the improvements from IPv6 what's the point of adopting it? Bigger address space -- The only real improvement in IPv6. The problem with DHCP is that it is an old answer to an even older question. Strangely, DHCPv6 is even worse in this regard than DCHPv4. Some protocol designers were clearly sleeping on the job there, or they were to busy getting in the way of those of us who wanted a non-DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is riddled with a badly specified way to interact with manual configuration and stateless autoconfig, it lacks a prefix length option and it has two modes, where the server knows which mode should be used but the client has to guess the right one. I agree that DHCPv6 should be fixed, but, fixing it should include adding the ability to assign routing information. In this day and age it doesn't make an iota worth of sense to update binary protocols on two sides whenever there is something new to discover. 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. Yes and no. RA giving out DNS information and a pointer might help, but, it doesn't solve everything. There is functionality provided by DHCPv4 today that is not available in DHCPv6, RA, or SLAAC or any combination. This must get resolved. It is an impediment to IPv6 adoption in the real world. The other features and improvements are all well and good if they work and they don't prevent the protocol from being accepted and/or deployed in the real world. With less than two years of remaining IANA IPv4 free pool, I think it is far more important that we get a deployable protocol with bigger addresses than one which contains a bunch of other features that aren't universally regarded as an improvement at the cost of existing functionality that has demand from real network operators. Of course that's not going to happen but taking stuff away from IPv6 that actually works (RA fate sharing) isn't going to solve the DHCPv6 problems. Nobody is proposing taking RA away from networks that want to use it. We're proposing making it an option to assign router information in DHCPv6. So, given that the question isnt' taking away what you want, can we please now add capabilities that many people actually need? Owen
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 this requires more addresses. The requirement for organizations with thousands (or in some cases millions) of deployed customers to dramatically change how they can associate an IP address with customer ports (or provide remote configuration of said customers' devices) is not an attractive feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
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 DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place. Then don't use it. That's why it's called an Option :) However some of us actually need to use this stuff and sometimes in ways not imagined by the IETF. - Kevin
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 general feedback on IPv6 deployment to the edge. Having read the entire thread, I am surprised at how few answers and feedback there are to the actual questions you have posed. It seems people are much more interested in an opportunity to redesign your network for you or grind old hatchets... Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. Unfortunately, it's a tiny bit worse than that. The IETF adopted the DUID for client identification; it promises to be able to identify a client uniquely across interfaces and NIC swap-outs (the MAC address changes, the DUID does not). This means you can't use the MAC address portion of a DUID reliably. Unfortunately, this completely circumvents all existing typical work flows for user registration or inventory accounting. There is still some work going on to try and reintroduce MAC based accounting to DHCPv6, and there are some proofs of concept available in source form today (but nothing standardized yet). Of course there is no way RA could reliably provide this, and the 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 (these are intentionally not cryptographically predictable), or that clients may need to re-iterate their SLAAC algorithm if interfered with by a peer (not even RA-Guard can save you from that, it is a DAD exploit) and you can't necessarily reliably detect iterations of the algorithm... Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ostensibly the solution to this problem is per host RA, which has seen many drafts at recent IETF's. That is to implement RA in your switches rather than your routers such that router advertisements may be crafted in response to router solicitations on a per-switch-port basis (which might track to per-user). This is of course a completely scalable and well thought out plan showing an obvious foresight to the structure of network configuration management. Any initial assessment that this is some kind of kludge or hack is completely unfounded, and if managing RA configuration across your entire switch fabric isn't scalable for you, then you just need to rethink your network architecture and buy more tools. After all, your switches are in a better position to know more about prefix and router information than your routers are anyway, so there's no reason to force us all into top-down configuration management models. Things really have become that desperate. On the other hand, as you say, you could just use DHCPv6. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. I can think of something you may like to know beforehand; There is a problem with the Both RA and DHCPv6 Model currently proposed by IETF iconoclasts. Should RA fail, for any reason from router, system, software, network path, security, or user error, then the simplest networks imaginable (where hosts and mail/Intranet/ work servers are all co-located on the same broadcast domain) will not be able to talk to one another, despite having valid IPv6 addresses. The problem is that they no longer know that the prefix for their address is locally connected. To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band
Re: ISP customer assignments
On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart nonobvi...@gmail.com 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 endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name-IP updated? how often do the various DNS servers revalidate those records? how often do the VPN devices revalidate the names? what happens when the dns changes while the vpn is still up? I'll stick with entering IP addresses. --Ricky
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 comes naturally? Well, I would not personally disable SLAAc except perhaps on specific machines for specific reasons. If I was using exclusively DHCPv6 I might disable the appropriate RA flags, and I would then expect my hosts to not do SLAAC. Any host that did would be broken, IMHO. It occurs to me that I haven't met anyone who uses the term SLAAC who uses IPv6 in a way that I would consider normal. (Or at all.) Ah well, it's always the exception that proves the rule. Sadly the term stateless autoconfiguration got overloaded, so now we have it meaning very different things - a) generating your own address from RA information; and b) getting only ancillary information from a DHCPv6 server. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
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 purposes. As with hotels in other parts of the world, congestive interference depends a lot on the hotel and what the person you're competing with is doing. I can tell you a few horror stories if you're amused by them, but in recent years things have been improving. I use the Cisco WebVPN (AnyConnect) client and I have yet to find a place in China where it doesn't work perfectly - even in rural areas, but not so rural that they don't have Internet access. However, if you try to do many normal things outside of the VPN connection - check certain news sites, logon to facebook or watch a video on YouTube, you won't be able to do so. -Robert Tellurian Networks - A Perot Systems Company http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin
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 Internet. The default port is UDP 1194, but can easily be changed. Anyone who wants to block it risks blocking any applications that use UDP in general, such as online games, Skype, etc. It is precisely because the traffic has no signature distinguishable from normal application traffic - aside from the fact that the payload is encrypted - that it makes a good fit. It's also open-source and free. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: equinix is acquiring switch data
I had a SD 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 cordmacl...@gmail.com wrote: http://www.equinix.com/news/press/na/2009/news-5109/ Thought this was relevant. -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
Re: equinix is acquiring switch data
On 2009-10-21, at 19:44, Jeffrey Lyon wrote:
I had a SD 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 prices are much better than ${vendor2}'s will
persist, however.
Joe
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 determined to prevent this choice at the operator level. For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA. so your not a fan of the smart edge and the stupid network. --bill
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 headers themselves, and aside from the port number. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
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 (these are intentionally not cryptographically predictable), or that clients may need to re-iterate their SLAAC algorithm if interfered with by a peer[...] That was me. My suggestion was to use MAC information from switches to build candidate addresses and ping6 them; rogue SLAAC-using hosts would respond, allowing them to be located and fixed. The OP I was replying to was concerned about clients that would do SLAAC even when the RA told them not to. It seems to me that hosts advanced enough to be able to do CGA or use temporary addresses (not necessarily the same thing) are unlikely to be hosts that would fail to interpret an RA correctly. This approach would probably not be 100% successful - maybe the pings don't get through, maybe the rogue doesn't answer pings, whatever. But it would at least be a start. A host that doesn't answer *may* still be a problem, but a host that does answer is *definitely* a problem. IMHO, automatically locating even some of your dud hosts is better than having to locate all of them the hard way. Ostensibly the solution to this problem is per host RA, which has [...] This is of course a completely scalable and well thought out plan Er - tap, tap - is this thing working? (Just testing my sarcasm detector :-) To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. This does neatly work around the problem; the hosts may now speak to one another. I don't understand this. Could you elaborate? It seems to me that the simplest network imaginable should still operate on link local addresses. Dibbler is a solid software package. Yes - and your note above tickles some vague memory that Dibbler has implemented something along those lines... I am extremely skeptical that we'll ever reach where we're going if we get there one millimeter at a time all the while redrafting our plans over and over. True - but that *is* pretty much how we got to where we are with IPv4 :-) Someone has forgotten that the reason IPv4 deployed so pervasively is because it was so very trivially simple. And some of its biggest disadvantages are there for the same reason. As Einstein said, things should be made a simple as possible - but no simpler. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
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 problematic and costly enough. The WAND Networking Research group did some measurements on the number of clients that accepted at least one incoming TCP connection from external to their network and presented their results at NZNOG 2009 ( http://www.wand.net.nz/~salcock/nznog09/spnat-nznog.pdf ). The number of people that successfully accepted at least one incoming TCP connection was somewhere from 30% to 44%. Most of it seemed to be from people using bittorrent, but about half was from other protocols. I'm not so sure it's entirely obvious that people aren't accepting incoming TCP connections.
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 traffic wouldn't identify it as a likely tunnel? :) Adrian
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 seeing one-way latency mirror the opposite direction. As source-destination latency goes up, destination-source latency goes down and vice versa. Myself and the monitoring team have ripped apart the OIDs, IP SLA configuration, and monitoring system. We've also built an ad-hoc system to compare the results. It's still consistent behavior. It's not a true mirror; there is definitely variation between the data collection, but at the 10,000 foot level, there is an obvious and consistent mirror to the data. The network topology is independant service providers all providing backhaul to a local ethernet exchange. 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 SLA mechanism. Any ideas? Having never used cisco's IP SLA (or even read about it), take this with a sack of salt. 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 timestamps gives you the latency in that direction. Now, how are your clocks syncronised? are they synchronised using NTP? or something better (GPS?) If one of your clocks is drifting with respect to the other then you'll see this effect. Does your clock drift because NTP is failing to keep the clock well syncronised when it's connection to it's parent NTP server is saturated?
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 timestamps gives you the latency in that direction. I believe a packet is sent, and the target router responds with a timestamp. But yeah, timestamps are being compared. I'm with Perry though - sounds like your clocks are drifting. -- Nathan Ward
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 adr...@creative.net.au wrote: 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 traffic wouldn't identify it as a likely tunnel? :) Adrian
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 with this for fun, but a quick abuse of google gives one relatively useful starting paper: http://ccr.sigcomm.org/online/files/p7-v37n1b-crotti.pdf Now, if you were getting multiple overlapping fingerprints inside a UDP packet stream you may conclude that it is a VPN tunnel of some sort. Just randomly padding the tunnel with a few bytes either side will probably just fuzz the classifier somewhat. Aggregating the packets up into larger packets may fuzz the classification methods but it certainly won't make the traffic look like something else. It'll likely still stick out as being different. :) Adrian
Re: ISP customer assignments
In message op.u156b0mztfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart nonobvi...@gmail.com 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 endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name-IP updated? It should be automatically updated by the end point. We do have the technology to do that. how often do the various DNS servers revalidate those records? If you are talking about caching servers then they will honour the TTL in the records. how often do the VPN devices revalidate the names? At startup. A well designed VPN protocol will support end point address mobility. what happens when the dns changes while the vpn is still up? This should be transparent to everything other than the vpn end points. I'll stick with entering IP addresses. --Ricky -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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 walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wed, Oct 21, 2009 at 8:01 PM, Rick Ernst er...@shreddedmail.com 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. I had to do a mental walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wed, Oct 21, 2009 at 7:55 PM, Rick Ernst er...@shreddedmail.comwrote: 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 walk-through, but I think I see how drift can cause this. I'm going to generate some artificial data, graph it, and see if it matches the general waveshape I'm seeing. I purposefully have the traffic generators ntp syncing against the responders. I thought that would keep the clocks more closely in sync. I don't necessarily care if the time is 'right', just that it's the same. What kind of difference should I expect if I sync both generators and responders against the same source, or not sync the responder? I'm thinking that having one source with constant drift may be better than both devices trying to walk/correct the time. Thanks for the input! On Wednesday, October 21, 2009, Nathan Ward na...@daork.net wrote: 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 timestamps gives you the latency in that direction. I believe a packet is sent, and the target router responds with a timestamp. But yeah, timestamps are being compared. I'm with Perry though - sounds like your clocks are drifting. -- Nathan Ward
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 from more than 100Mbps, so I would say it can handle a bit more than typical SMB traffic. I don't know if anyone mentioned it, but a good commercial product a former customer of mine used to use was Solarwinds Orion. A bout of research a few years back turned up IBM Aurora (http://www.zurich.ibm.com/aurora/), now sold as Tivoli/Netcool (http://www-01.ibm.com/software/tivoli/products/netcool-performance-flow/) as a potential solution for high performance analysis, but IIRC, a fairly hefty price tag applied based on traffic volume. Looking at the second URL, it is not clear, but looks like $10K + $200 per resource unit, whatever that maps out to be. Definitely not on the same level as the typical solutions. Mark -- Mark D. Nagel, CCIE #3177 mna...@willingminds.com Principal Consultant, Willing Minds LLC (http://www.willingminds.com) cell: 949-279-5817, desk: 714-630-4772, fax: 949-623-9854 *** Please send support requests to supp...@willingminds.com! ***
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 SLA mechanism. I've been using IP SLA for years (right now under 12.4) and I have not seen behaviour that mirrors what you see. I often see one-way latency go up without the other way doing so. You should start by looking in show ip sla (monitor) op and see what values you see in the router, that might give you more information regarding where the problem might be (your polling system or if the IP SLA agent is actually reporting what you see). -- Mikael Abrahamssonemail: swm...@swm.pp.se
