NANOG transition update
A lot of progress has been made since NANOG 51, so I'd like to share this update with the community. * Association management contract We recently completed our RFP and selection process, and have contracted with Association Management Solutions (http://www.amsl.com) to provide association management and meeting support services for NANOG. We are excited to be working with AMS, as they have an excellent set of management and IT services which are very good fits to our needs. AMS might already be familiar to some of our community, as they have providing IETF secretariat services for the past several years. Representatives from AMS will be with us in Denver to observe the conference and meet the community. Over the next couple of months our meeting registration, membership, mailing list and finance systems will be migrated to AMS infrastructure. The transition has already started, and will be completed in time for the start of registration for the NANOG53 meeting. We'll share more details of the transition process as they become available. * NANOG Intellectual Property All of the NANOG intellectual property originated by Merit Network, including the name, domain, logos, mailing lists and archives, have been transferred to NewNOG. This means that we _are_ NANOG! We expect that the interim name "NewNOG" will eventually go away. * Non-profit status NewNOG, Inc. has been recognized by the IRS as a 501(c)(3) charitable organization. (See http://www.newnog.org/docs/IRSletter.pdf for the IRS determination letter.) This means that individual donations might be tax-deductible. * Future conferences Work continues on securing hosts and venues for future NANOG conferences. The current list of future events is at http://www.nanog.org/meetings/future/, and we expect to have the October 2012 meeting ready to announce in the next few weeks. And if you haven't already registered, please plan to join us at NANOG52 in Denver next month! The Program Committee has published a great agenda, and the hotel block is filling fast. The hotel group rate expires on May 29, and the conference registration fee goes up on June 4, so please register soon! More information is at http://www.nanog.org/meetings/nanog52/. We welcome any questions or comments, and we'll give another update at the community meeting in Denver. For the board, Steve Feldman, chair
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 11:42 PM, Patrick W. Gilmore wrote: > However, many networks take active steps to assure that external parties > cannot disrupt their internal network. Anyone on this list with And many networks have implemented BCP38 and appropriate prefix filters + as path filters with their peers, including upstreams. Some networks take active steps. I think as a group you give them a little too much credit. I don't mean to speculate about what exactly Rogers is doing. Only that: if they just spontaneously decided to start using "7/8" on their internal network as unofficial space, they could be putting themselves at risk in unanticipated ways. Even with active protection against that particular risk, it is still possible the unofficial use will be harmful to the DoD some day, in some way, resulting in repercussions against the unofficial user If you want to use some other organization's IP addresses without their permission, for any purpose (internal or not); It seems like the DoD, military commands of other large countries, along with local law enforcement organizations should be at the very _bottom_ of the list; they have more extreme retaliation/investigative powers than any private company does. > internal prefixes shorter than /24 likely have filters or other mechanisms in > place to ensure they do not hear a /24 of their own space from peers & > transit providers. > If they do not, then they are at risk, whether they use highjacked space or > not. -- -JH
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 23, 2011, at 9:09 PM, David Conrad wrote: > Owen, > > On May 23, 2011, at 8:34 PM, Owen DeLong wrote: >> I think there are a number of other options available to them. > > > Out of curiosity, what would these options be? > As previously mentioned: 1. Obtain RIR space 2. Use multiple partitioned copies of RFC-1918 3. Free addresses among existing customers through LSN implementation. There may be others. Yes, each of these comes with its own tradeoffs and costs. Obviously, option 1 is of a limited duration. Owen
Re: Rogers Canada using 7.0.0.0/8 for internal address space
>Which they should be ready to do already, since didn't the US Govt. >mandate IPv6 support sometime last century? ;) Yeah, it runs over GOSIP. R's, John
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 23, 2011 9:37 PM, "Jimmy Hess" wrote: > > On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore wrote: > > If they do, any Rogers customer who wants to talk to it is screwed. Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders. > > That could depend on whether Rogers' border routers are adequately configured > to block/filter the announcement, and whether whatever the DoD chose to > announce was a longer prefix than what Rogers' equipment had > routes/controls for. > > In theory; there exists a possibility that the DoD could announce a > /24 of something > Rogers' was internally routing as a /16, then if unfiltered the DoD > announce could win, > causing internal (self-inflicted) issues for Rogers. > > The DoD could also eventually use the 7 range for something, resulting > in complaints to Rogers > from users who seem unable to reach (some web site placed in 7/8). > > > Unofficial use of other organization's IP address space is playing with fire. > > > It may mark the symbolic start of a new IPv4, where eventually > many /8s will have tons of unofficial claimaints, and whoever > threatens more, pays the major providers more, or has more lawyers > (take your pick), gets their announcement more widely propagated. > > Sometimes if enough players start playing with fire, a really bad, > uncontrollable inferno eventually gets ignited. > Or, ipv6 gets deployed and supported since it will be the effective network of networks Cb > > TTFN, > > patrick > -- > -JH >
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 24, 2011, at 12:36 AM, Jimmy Hess wrote: > On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore > wrote: >> If they do, any Rogers customer who wants to talk to it is screwed. Whether >> they have a 7 addy or not, Rogers' routers will not let the packet leave >> Rogers' borders. > > That could depend on whether Rogers' border routers are adequately configured > to block/filter the announcement, and whether whatever the DoD chose to > announce was a longer prefix than what Rogers' equipment had > routes/controls for. > > In theory; there exists a possibility that the DoD could announce a > /24 of something > Rogers' was internally routing as a /16, then if unfiltered the DoD > announce could win, > causing internal (self-inflicted) issues for Rogers. We're all just guessing here, until some Rogers engineer speaks up. However, many networks take active steps to assure that external parties cannot disrupt their internal network. Anyone on this list with internal prefixes shorter than /24 likely have filters or other mechanisms in place to ensure they do not hear a /24 of their own space from peers & transit providers. If they do not, then they are at risk, whether they use highjacked space or not. As a result, while it is possible the DoD could announce a /24 that Rogers routes internally as a /16 and cause Rogers problems; I suspect Rogers ensured the DoD - or anyone else - cannot cause them problems. Other than putting a web server in 7/8 that Rogers customers want to visit. :) -- TTFN, patrick > The DoD could also eventually use the 7 range for something, resulting > in complaints to Rogers > from users who seem unable to reach (some web site placed in 7/8). > > > Unofficial use of other organization's IP address space is playing with fire. > > > It may mark the symbolic start of a new IPv4, where eventually > many /8s will have tons of unofficial claimaints, and whoever > threatens more, pays the major providers more, or has more lawyers > (take your pick), gets their announcement more widely propagated. > > Sometimes if enough players start playing with fire, a really bad, > uncontrollable inferno eventually gets ignited. > >> TTFN, >> patrick > -- > -JH >
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 11:09 PM, Patrick W. Gilmore wrote: > If they do, any Rogers customer who wants to talk to it is screwed. Whether > they have a 7 addy or not, Rogers' routers will not let the packet leave > Rogers' borders. That could depend on whether Rogers' border routers are adequately configured to block/filter the announcement, and whether whatever the DoD chose to announce was a longer prefix than what Rogers' equipment had routes/controls for. In theory; there exists a possibility that the DoD could announce a /24 of something Rogers' was internally routing as a /16, then if unfiltered the DoD announce could win, causing internal (self-inflicted) issues for Rogers. The DoD could also eventually use the 7 range for something, resulting in complaints to Rogers from users who seem unable to reach (some web site placed in 7/8). Unofficial use of other organization's IP address space is playing with fire. It may mark the symbolic start of a new IPv4, where eventually many /8s will have tons of unofficial claimaints, and whoever threatens more, pays the major providers more, or has more lawyers (take your pick), gets their announcement more widely propagated. Sometimes if enough players start playing with fire, a really bad, uncontrollable inferno eventually gets ignited. > TTFN, > patrick -- -JH
Re: Rogers Canada using 7.0.0.0/8 for internal address space
In message <17520.1306210956@localhost>, valdis.kletni...@vt.edu writes: > On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said: > > > Now, the onus is on the DoD to make its content available over unique > > IPv6 space so that the Roger's customers can get to it using the > > 6to4-PMT solution. There is always a solution. > > Which they should be ready to do already, since didn't the US Govt. > mandate IPv6 support sometime last century? ;) Which isn't yet a practical solution because it takes two to play. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Rogers Canada using 7.0.0.0/8 for internal address space
In message , Cameron Byrne writes: > On Mon, May 23, 2011 at 9:09 PM, Patrick W. Gilmore wro= > te: > > On May 24, 2011, at 12:02 AM, Christopher Morrow wrote: > >> On Mon, May 23, 2011 at 11:34 PM, Owen DeLong wrote: > >>> > >>> I don't think they have to hijack space from DoD. I think there are a > >>> number of other options available to them. They might cost more, but, > >>> they also come with somewhat lower risks > >> > >> the good thing is 7 exists on networks that will never see the light > >> of day... so it's just like 10! only lower and cooler! (and lucky, if > >> you believe the movies and all) > > > > It's not just whether those networks will ever leak 7. =A0It's whether th= > e DoD will ever announce anything in 7. > > > > If they do, any Rogers customer who wants to talk to it is screwed. =A0Wh= > ether they have a 7 addy or not, Rogers' routers will not let the packet le= > ave Rogers' borders. > > > > Now, the onus is on the DoD to make its content available over unique > IPv6 space so that the Roger's customers can get to it using the > 6to4-PMT solution. There is always a solution. There is also the option of having customers that need 6to4, etc. just register on the web site like customers that need port 25/TCP open register with many ISPs. Those customers then get addresses from different pools for which 6to4 works. > Cameron > > > -- > > TTFN, > > patrick > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 9:22 PM, wrote: > On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said: > >> Now, the onus is on the DoD to make its content available over unique >> IPv6 space so that the Roger's customers can get to it using the >> 6to4-PMT solution. There is always a solution. > > Which they should be ready to do already, since didn't the US Govt. > mandate IPv6 support sometime last century? ;) > The US Govt does actually have a respectable showing for World IPv6 Day including treasury.gov, edu.gov, census.gov and others. CB
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said: > Now, the onus is on the DoD to make its content available over unique > IPv6 space so that the Roger's customers can get to it using the > 6to4-PMT solution. There is always a solution. Which they should be ready to do already, since didn't the US Govt. mandate IPv6 support sometime last century? ;) pgpXBOXb65w0B.pgp Description: PGP signature
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 9:09 PM, Patrick W. Gilmore wrote: > On May 24, 2011, at 12:02 AM, Christopher Morrow wrote: >> On Mon, May 23, 2011 at 11:34 PM, Owen DeLong wrote: >>> >>> I don't think they have to hijack space from DoD. I think there are a >>> number of other options available to them. They might cost more, but, >>> they also come with somewhat lower risks >> >> the good thing is 7 exists on networks that will never see the light >> of day... so it's just like 10! only lower and cooler! (and lucky, if >> you believe the movies and all) > > It's not just whether those networks will ever leak 7. It's whether the DoD > will ever announce anything in 7. > > If they do, any Rogers customer who wants to talk to it is screwed. Whether > they have a 7 addy or not, Rogers' routers will not let the packet leave > Rogers' borders. > Now, the onus is on the DoD to make its content available over unique IPv6 space so that the Roger's customers can get to it using the 6to4-PMT solution. There is always a solution. Cameron > -- > TTFN, > patrick > > >
Re: Rogers Canada using 7.0.0.0/8 for internal address space
Owen, On May 23, 2011, at 8:34 PM, Owen DeLong wrote: > I think there are a number of other options available to them. Out of curiosity, what would these options be? Regards, -drc
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 24, 2011, at 12:02 AM, Christopher Morrow wrote: > On Mon, May 23, 2011 at 11:34 PM, Owen DeLong wrote: >> >> I don't think they have to hijack space from DoD. I think there are a >> number of other options available to them. They might cost more, but, >> they also come with somewhat lower risks > > the good thing is 7 exists on networks that will never see the light > of day... so it's just like 10! only lower and cooler! (and lucky, if > you believe the movies and all) It's not just whether those networks will ever leak 7. It's whether the DoD will ever announce anything in 7. If they do, any Rogers customer who wants to talk to it is screwed. Whether they have a 7 addy or not, Rogers' routers will not let the packet leave Rogers' borders. -- TTFN, patrick
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 11:34 PM, Owen DeLong wrote: > > I don't think they have to hijack space from DoD. I think there are a > number of other options available to them. They might cost more, but, > they also come with somewhat lower risks the good thing is 7 exists on networks that will never see the light of day... so it's just like 10! only lower and cooler! (and lucky, if you believe the movies and all)
Re: Rogers Canada using 7.0.0.0/8 for internal address space
> > This is the business reality of the IPv4-scarce era. Diluted IPv4 is > not new to many places and will become common in many more places. > Furthermore, it is a calculated business risk. IPv4 services > will/have become the 2nd class (NAT444...) services as IPv6 ascends > to first class status with e2e restored and more and more services > supporting IPv6 (World IPv6 day in a little over 2 week!...). > Diluted IPv4 is one thing. Hijacking space allocated to another entity is another. As long as they keep it contained within their network, it's pretty much up to them to break their own environment however they see fit, but, if they start leaking 7.0.0.0/8 or subset announcements on to the internet in general, I wouldn't want to be them or one of the companies that was accepting their routes. > Don't get me wrong, IPv6 has a long way to go in terms of > availability, peering, and application support. But make no mistake, > the tide is turning. Rogers is doing what they have to do proactively > to stay ahead of the curve of complete exhaustion. > I don't think they have to hijack space from DoD. I think there are a number of other options available to them. They might cost more, but, they also come with somewhat lower risks. Owen
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On Mon, May 23, 2011 at 7:00 PM, Mark Andrews wrote: > > In message , Joel Jaeggli > write > s: >> >> On May 23, 2011, at 10:36 AM, Owen DeLong wrote: >> >> >=20 >> >=20 >> > Sent from my iPad >> >=20 >> > On May 23, 2011, at 11:32, David Conrad wrote: >> >=20 >> >> On May 23, 2011, at 8:28 AM, Mark Farina wrote: >> >>> Is the DoD releasing this range to Rogers? >> >>=20 >> >> Unlikely, although it might be an interesting case of testing ARIN's = >> transfer policy if it was the case :-). >> >>=20 >> >>> Or has Rogers squatted on this space due to exhaustion of their 10/8 = >> use? >> >>=20 >> >=20 >> > More likely they are making the assumption that their private internal = >> use of the address >> > space won't conflict with DoD's (apparently) private internal use of = >> the address space. >> >> if they're numbering cpe out of it they've also decided that breaking = >> 6to4 is no problem either, if they aren't then hey it's just more ipv4 = >> ugliness, and there's alot more where that came from... >> >> joel= > > and other stuff which doesn't work in a double nat environment. > This is the business reality of the IPv4-scarce era. Diluted IPv4 is not new to many places and will become common in many more places. Furthermore, it is a calculated business risk. IPv4 services will/have become the 2nd class (NAT444...) services as IPv6 ascends to first class status with e2e restored and more and more services supporting IPv6 (World IPv6 day in a little over 2 week!...). Don't get me wrong, IPv6 has a long way to go in terms of availability, peering, and application support. But make no mistake, the tide is turning. Rogers is doing what they have to do proactively to stay ahead of the curve of complete exhaustion. As for 6to4, the good folks at Rogers have found a way to make it work for you ... with yet another NAT :) http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 Cameron -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
Re: Rogers Canada using 7.0.0.0/8 for internal address space
In message , Joel Jaeggli write s: > > On May 23, 2011, at 10:36 AM, Owen DeLong wrote: > > >=20 > >=20 > > Sent from my iPad > >=20 > > On May 23, 2011, at 11:32, David Conrad wrote: > >=20 > >> On May 23, 2011, at 8:28 AM, Mark Farina wrote: > >>> Is the DoD releasing this range to Rogers? > >>=20 > >> Unlikely, although it might be an interesting case of testing ARIN's = > transfer policy if it was the case :-). > >>=20 > >>> Or has Rogers squatted on this space due to exhaustion of their 10/8 = > use? > >>=20 > >=20 > > More likely they are making the assumption that their private internal = > use of the address > > space won't conflict with DoD's (apparently) private internal use of = > the address space. > > if they're numbering cpe out of it they've also decided that breaking = > 6to4 is no problem either, if they aren't then hey it's just more ipv4 = > ugliness, and there's alot more where that came from... > > joel= and other stuff which doesn't work in a double nat environment. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Experiences with "advanced" network taps.
Look at NetOptics Directors or the VSS 4x24. I've deployed several. On Mon, May 23, 2011 at 8:34 PM, Darren Bolding wrote: > We are planning on purchasing some network taps for a couple of locations > in > our network, and we expect to make significantly greater use of them in the > next year or two. > > Something that is new since I last investigated taps (it has been a while) > is that many of them now allow for functionality I would typically think of > as far outside what a simple tap does. > > For example: > > Selective forwarding of packets based on MAC address, TCP/UDP port, IP > address range etc. > Selective forwarding/load balancing based on flow, so that you can > distribute traffic across a cluster of devices (e.g. IDS or netflow probes) > Ability to insert a device (firewall, IDS, etc) into the network flow and > via software configuration bypass traffic around the device- e.g. able to > quickly drop a device out of the network path. > - Some have the ability to send network probes, or monitor traffic > downstream of an inline device so they can automatically take the device > out > of line if it fails to pass traffic. > - Some can filter which traffic goes through the inline device and merge it > back with the traffic that was not sent to the inline device for downstream > consumption. > Some can be connected and automatically be managed as if one device, > allowing monitor and replication ports to be used across the stack/mesh of > devices. > > All of this is very interesting. Of course these taps cost more than your > basic dumb tap. > > More interestingly to me is that these taps are no longer dumb, and that > makes them a bit of a riskier proposition. In evaluating some we have run > into issues ranging from misconfiguration/user error to what appear to be > crashes (with associated loss of forwarding). > > I'm wondering if anyone has had significant experience deploying these more > advanced taps, whether it was good or bad, general comments you might like > to share regarding them, and whether you would recommend particular > vendors. > > If people reply off-list, I will make a point of summarizing back if I get > any feedback. > > Thanks! > > --D > > -- > -- Darren Bolding -- > -- dar...@bolding.org -- > -- Jason
Experiences with "advanced" network taps.
We are planning on purchasing some network taps for a couple of locations in our network, and we expect to make significantly greater use of them in the next year or two. Something that is new since I last investigated taps (it has been a while) is that many of them now allow for functionality I would typically think of as far outside what a simple tap does. For example: Selective forwarding of packets based on MAC address, TCP/UDP port, IP address range etc. Selective forwarding/load balancing based on flow, so that you can distribute traffic across a cluster of devices (e.g. IDS or netflow probes) Ability to insert a device (firewall, IDS, etc) into the network flow and via software configuration bypass traffic around the device- e.g. able to quickly drop a device out of the network path. - Some have the ability to send network probes, or monitor traffic downstream of an inline device so they can automatically take the device out of line if it fails to pass traffic. - Some can filter which traffic goes through the inline device and merge it back with the traffic that was not sent to the inline device for downstream consumption. Some can be connected and automatically be managed as if one device, allowing monitor and replication ports to be used across the stack/mesh of devices. All of this is very interesting. Of course these taps cost more than your basic dumb tap. More interestingly to me is that these taps are no longer dumb, and that makes them a bit of a riskier proposition. In evaluating some we have run into issues ranging from misconfiguration/user error to what appear to be crashes (with associated loss of forwarding). I'm wondering if anyone has had significant experience deploying these more advanced taps, whether it was good or bad, general comments you might like to share regarding them, and whether you would recommend particular vendors. If people reply off-list, I will make a point of summarizing back if I get any feedback. Thanks! --D -- -- Darren Bolding -- -- dar...@bolding.org --
IPv6 Availability on XO
I've heard some mixed reports of XO's IPv6 availability - some that they have full deployment/availability, but others like the answer back from our XO reseller that XO does not offer IPv6 on circuits under 45mbit/s. What is the experience of NANOG on this matter, particularly with XO connectivity under 45mbit/s?
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 23, 2011, at 10:36 AM, Owen DeLong wrote: > > > Sent from my iPad > > On May 23, 2011, at 11:32, David Conrad wrote: > >> On May 23, 2011, at 8:28 AM, Mark Farina wrote: >>> Is the DoD releasing this range to Rogers? >> >> Unlikely, although it might be an interesting case of testing ARIN's >> transfer policy if it was the case :-). >> >>> Or has Rogers squatted on this space due to exhaustion of their 10/8 use? >> > > More likely they are making the assumption that their private internal use of > the address > space won't conflict with DoD's (apparently) private internal use of the > address space. if they're numbering cpe out of it they've also decided that breaking 6to4 is no problem either, if they aren't then hey it's just more ipv4 ugliness, and there's alot more where that came from... joel
Re: Rogers Canada using 7.0.0.0/8 for internal address space
Sent from my iPad On May 23, 2011, at 11:32, David Conrad wrote: > On May 23, 2011, at 8:28 AM, Mark Farina wrote: >> Is the DoD releasing this range to Rogers? > > Unlikely, although it might be an interesting case of testing ARIN's transfer > policy if it was the case :-). > >> Or has Rogers squatted on this space due to exhaustion of their 10/8 use? > > Probably. I've heard other large providers having similar issues (resulting > in several attempts to designate more RFC 1918, all of which were all shot > down). > Really? All of them? Are you sure about that? I believe there is a policy proposal in the ARIN region which, I have it on good authority is still active. True, it doesn't technically designate more RFC-1918, but, it does create a /10 of space for shared use for the purpose of LSN intermediate space or other carrier-level private network usage. >> We've seen other vendors and ISP squat on previously unused ranges (the 1/8 >> or 5/8s). > > Yes, however at the time those ISPs squatted on those addresses (and others), > they had not yet been allocated by IANA pretty much guaranteeing there would > be collisions when the IPv4 free pool was exhausted. In this case, the block > has been allocated yet doesn't appear to be in the routing system and I'm not > sure it ever has been (at least authorized to be). I'm guessing Rogers is > making the assumption that the chances are probably small that one of their > customers will need to communicate with a non-announced US DoD network. I > suspect they aren't the first to make this assumption. > More likely they are making the assumption that their private internal use of the address space won't conflict with DoD's (apparently) private internal use of the address space. Owen
Re: Rogers Canada using 7.0.0.0/8 for internal address space
On May 23, 2011, at 8:28 AM, Mark Farina wrote: > Is the DoD releasing this range to Rogers? Unlikely, although it might be an interesting case of testing ARIN's transfer policy if it was the case :-). > Or has Rogers squatted on this space due to exhaustion of their 10/8 use? Probably. I've heard other large providers having similar issues (resulting in several attempts to designate more RFC 1918, all of which were all shot down). > We've seen other vendors and ISP squat on previously unused ranges (the 1/8 > or 5/8s). Yes, however at the time those ISPs squatted on those addresses (and others), they had not yet been allocated by IANA pretty much guaranteeing there would be collisions when the IPv4 free pool was exhausted. In this case, the block has been allocated yet doesn't appear to be in the routing system and I'm not sure it ever has been (at least authorized to be). I'm guessing Rogers is making the assumption that the chances are probably small that one of their customers will need to communicate with a non-announced US DoD network. I suspect they aren't the first to make this assumption. > Could they not wrap their internal cable modem to node chatter in IPv6, > instead of using assigned address space? This would assume their deployed systems can support IPv6. I suspect they have a few non-upgradeable systems/devices in their network and have chosen to squat on 7/8 rather than raise their rates to cover short-term upgrade costs (or deal with additional operational costs if they used multiple instances of 10/8). But I'm just guessing... Regards, -drc
RE: NANOG 52 - Room block filling up!
Already booked and ready to go! --- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: May 23, 2011 11:01 AM To: Brandon Ross Cc: nanog@nanog.org Subject: Re: NANOG 52 - Room block filling up! > Date: Mon, 23 May 2011 11:08:10 -0400 (EDT) > From: Brandon Ross > > I take that back, it shows as booked if you go through normal booking > channels, if you use the starwoodmeetings URL in the NANOG meeting > information page it shows availability. Which means our block is not full, but, outside the block, the hotel is fully booked. If we don't use all of the NANOG block by the 30th, those rooms will probably be released for general use but it is very likely that if you don't reserve soon either the block will fill or the few rooms left will be booked shortly after they are released. Don't wait too long! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: NANOG 52 - Room block filling up!
> Date: Mon, 23 May 2011 11:08:10 -0400 (EDT) > From: Brandon Ross > > I take that back, it shows as booked if you go through normal booking > channels, if you use the starwoodmeetings URL in the NANOG meeting > information page it shows availability. Which means our block is not full, but, outside the block, the hotel is fully booked. If we don't use all of the NANOG block by the 30th, those rooms will probably be released for general use but it is very likely that if you don't reserve soon either the block will fill or the few rooms left will be booked shortly after they are released. Don't wait too long! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Rogers Canada using 7.0.0.0/8 for internal address space
As of April 27th I have started to receive dhcp broadcast requests originating from the 7.0.0.0/8 network. Based on MAC addresses, it seems that this is communication between the Rogers border/node hardware (MAC assigned to Cisco) and my Motorola cable modem. Is the DoD releasing this range to Rogers? Or has Rogers squatted on this space due to exhaustion of their 10/8 use? We've seen other vendors and ISP squat on previously unused ranges (the 1/8 or 5/8s). Could they not wrap their internal cable modem to node chatter in IPv6, instead of using assigned address space? sample chatter .. MAC=00:14:f1:eb:57:de:08:00 SRC=7.8.12.1 DST=255.255.255.255 LEN=347 TOS=00 PREC=0x00 TTL=255 ID=16 PROTO=UDP SPT=67 DPT=68 LEN=327 IP (tos 0x0, ttl 255, id 15, offset 0, flags [none], proto UDP (17), length 355) 7.8.12.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 327, xid 0x4, Flags [Broadcast] (0x8000) Your-IP 7.8.x.x Server-IP 7.8.x.1 Gateway-IP 7.8.x.1 Client-Ethernet-Address 00:0e:5c:xx:xx:xx file "xxx" Vendor-rfc1048 Extensions Magic Cookie 0xXX DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 64.71.246.x Lease-Time Option 51, length 4: 548020 Subnet-Mask Option 1, length 4: 255.255.252.0 RN Option 58, length 4: 40 Time-Zone Option 2, length 4: 0 Default-Gateway Option 3, length 4: 7.8.x.1 Time-Server Option 4, length 4: 64.71.x.x END Option 255, length 0 PAD Option 0, length 0, occurs 41 -- MF gbtel.ca
Re: NANOG 52 - Room block filling up!
I take that back, it shows as booked if you go through normal booking channels, if you use the starwoodmeetings URL in the NANOG meeting information page it shows availability. On Mon, 23 May 2011, Brandon Ross wrote: For what it's worth, the hotel appears to be completely booked the nights of the 14th and 15th. On Mon, 23 May 2011, Michael K. Smith - Adhost wrote: Hello All: NANOG 52 in Denver is fast approaching. If you're planning on attending and want to get the benefits of the NANOG room rate, you should consider signing up as soon as possible. We're at 85% of our room block capacity and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time (GMT -6). For more information please see http://www.nanog.org/meetings/nanog52/index.php. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
Re: NANOG 52 - Room block filling up!
For what it's worth, the hotel appears to be completely booked the nights of the 14th and 15th. On Mon, 23 May 2011, Michael K. Smith - Adhost wrote: Hello All: NANOG 52 in Denver is fast approaching. If you're planning on attending and want to get the benefits of the NANOG room rate, you should consider signing up as soon as possible. We're at 85% of our room block capacity and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time (GMT -6). For more information please see http://www.nanog.org/meetings/nanog52/index.php. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
NANOG 52 - Room block filling up!
Hello All: NANOG 52 in Denver is fast approaching. If you're planning on attending and want to get the benefits of the NANOG room rate, you should consider signing up as soon as possible. We're at 85% of our room block capacity and the cutoff date for the NANOG rate is May 29th at 5:00 PM Denver time (GMT -6). For more information please see http://www.nanog.org/meetings/nanog52/index.php. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)
IPv6 CPE Survey - Initial Results on RIPE Labs
[apologies for duplicates] Dear colleagues, Since we published the IPv6 customer premise equipment (CPE) survey during the RIPE 62 meeting, we received more than 100 responses. This new article on RIPE Labs shows some interesting initial results: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-results-may-2011 The survey is still open. If you are using an IPv6 capable CPE and have not yet filled in the survey, we would like to encourage you to do so. The survey can be found here: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate Kind Regards, Marco Hogewoning & Mirjam Kuehne RIPE NCC
Fwd: Service Provider Route Flap Damping Deployment Status Survey
Dear NANOG Thanks for a lot of answer and comments to the survey. We will close this survey in 25th May 17:30 of the UTC time. If you could answer the survey,could you open url. https://www.surveymonkey.com/s/rfd-survey We will update our draft,and let you know. Regards, -Shishio Original Message Subject: Service Provider Route Flap Damping Deployment Status Survey Date: Fri, 18 Mar 2011 01:56:35 +0900 From: Shishio Tsuchiya To: nanog@nanog.org CC: shtsu...@cisco.com, kawamu...@mesh.ad.jp, ra...@psg.com, cris...@iij.ad.jp Dear NANOG, I'm Shishio,Cisco Systems Japan. I,Seiichi and Randy did presentation about "BGP topic" on JANOG27 which held 20th & 21st January 2011 in Kanazawa. http://www.janog.gr.jp/en/index.php?JANOG27%20Programs#qe7ec71d Randy explained "Route Flap Damping Considered Useable". http://ripe61.ripe.net/presentations/222-101117.ripe-rfd.pdf This report explains how to improve today's harmful RFD. We heard various opinion from bgp operators about RFD. So we took survey about "Service Provider Route Flap Damping Deployment Status" on ja...@janog.gr.jp. We would like to hear more opinions to analyze current RFD operation,problem and so on. Could you please open the following url and answer the questionaire? https://www.surveymonkey.com/s/rfd-survey The JAPAN result summary is below. --- Q1.Do you use Route Flap Damping ? Yes: 5 No: 13 Q2.If you select No on Q1,why? Do not have the need: 3 Did not know about the feature: 2 No benefits expected: 3 Customers would complain:1 Because I read RIPE-378 :2 Other: 3 Q3.If you select Yes on Q1,what parameter do you use? Default parameters: 3 RIPE-178 : 0 RIPE-210 : 0 RIPE-229 : 0 Other: 3 Q4.Do you know Randy Bush et. al's report ''Route Flap Damping Considered Usable?'' Yes: 12 No: 7 Q5.IOS's max-penalty is currently limited to 20K. Do you need this limitation to be relaxed to over 50K? Yes: 10 No: 9 Q6.If you have any comments, please fill this box. -Our peer seems to have damping enabled, and our prefix gets damped sometimes. -We do not enable damping because we think that customers want a non-damped route. -From the perspective of a downstream ISP, if our upstream told us that an outage occurred because a route was damped, I may call and ask "is it written in the agreement that you will do this?" -We use damping pretty heavily -I had RFD turned on until this morning when I discovered our router has CSCtd26215 issues. I would like to turn on a "useful" RFD. --- other reference: https://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-01 https://tools.ietf.org/html/draft-ymbk-rfd-usable-00 Best Regards,
Re: Had an idea - looking for a math buff to tell me if it's possible with today's technology.
On Wed, 18 May 2011 13:07:32 -0700 Landon Stewart wrote: > Lets say you had a file that was 1,000,000,000 characters consisting > of 8,000,000,000bits. What if instead of transferring that file > through the interwebs you transmitted a mathematical equation to tell > a computer on the other end how to *construct* that file. First > you'd feed the file into a cruncher of some type to reduce the > pattern of 8,000,000,000 bits into an equation somehow. Sure this > would take time, I realize that. The equation would then be > transmitted to the other computer where it would use its > mad-math-skillz to *figure out the answer* which would theoretically > be the same pattern of bits. Thus the same file would emerge on the > other end. > > The real question here is how long would it take for a regular > computer to do this kind of math? > > Just a weird idea I had. If it's a good idea then please consider > this intellectual property. LOL 42 :-)
