Re: [dns-wg] Global Vs local node data in www.root-servers.org
On 17 Mar 2014, at 7:39, John Bond john.b...@icann.org wrote: Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global. I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. in such a way, potentially): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe signature.asc Description: Message signed with OpenPGP using GPGMail
Re: How to catch a cracker in the US?
On 3/13/14, 7:35 PM, Larry Sheldon larryshel...@cox.net wrote: Not sure I can agree with that. I have been in this game for a very long time, but for most of it in places where the world's population cleaved neatly into two parts: Authorized Users who could be identified by the facts that they had ID cards, Badges, and knew the door code; and trespassers who were all others. Then you new kids came along and (pointlessly, in my opinion) divided the later group into the two described above. See, the way *I* learned it was that part of the creed of the hacker involved why would I want to play with your systems, mine are much cooler.; that is, by definition a hacker is in the first group. --Josh
Re: [dns-wg] Global Vs local node data in www.root-servers.org
alas, our service predates Joe’s marvelous text. “B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement. /bill Neca eos omnes. Deus suos agnoscet. On 17March2014Monday, at 7:17, Joe Abley jab...@hopcount.ca wrote: On 17 Mar 2014, at 7:39, John Bond john.b...@icann.org wrote: Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global. I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. in such a way, potentially): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe
Re: [dns-wg] Global Vs local node data in www.root-servers.org
On 17 Mar 2014, at 10:27, manning bill bmann...@isi.edu wrote: alas, our service predates Joe’s marvelous text. “B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement. In the taxonomy I just shared, that makes the origin nodes of B all global nodes. To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms local and global in a DNS anycast context that I was apologising for :-) Joe
Re: [dns-wg] Global Vs local node data in www.root-servers.org
On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote: On 17 Mar 2014, at 10:27, manning bill bmann...@isi.edu wrote: alas, our service predates Joe’s marvelous text. “B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement. In the taxonomy I just shared, that makes the origin nodes of B all global nodes. To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms local and global in a DNS anycast context that I was apologising for :-) Joe No apology needed. I was clarifying why B is listed as a local node. That it doesn't fit you taxonomy is fine - but it does need an explaination. /bill
Last Call and Draft program for RIPE 68
Dear Colleagues, A list of currently accepted RIPE 68 presentations is now published at: https://ripe68.ripe.net/programme/meeting-plan/draft/ There are still few slots remaining for a final RIPE 68 programme and RIPE Programme Committee will accept new proposals until 6 April 2014. This is our last call for you to submit your proposals. Kind regards Filiz Yilmaz Chair, RIPE Programme Committee Begin forwarded message: From: Filiz Yilmaz koala...@gmail.com Subject: Call for Presentations RIPE 68 Date: 19 Nov 2013 19:04:34 GMT+1 To: ripe-l...@ripe.net, nanog@nanog.org nanog@nanog.org Cc: p...@ripe.net Committee p...@ripe.net Dear colleagues, Please find the CFP for RIPE 68 below or at https://ripe68.ripe.net/submit-topic/cfp/. The deadline for submissions is 2 March 2014. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards Filiz Yilmaz RIPE PC Chair http://www.ripe.net/ripe/meetings/ripe-meetings/pc - Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 68 will take place from 12 – 16 May 2014 in Warsaw, Poland. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 68. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: • IPv6 deployment • Managing IPv4 scarcity in operations • Commercial transactions of IPv4 addresses • Data centre technologies • Network and DNS operations • Internet governance and regulatory practices • Network and routing security • Content delivery • Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe68.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for “lightning talks”, which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 2 March 2014, using the meeting submission system at https://ripe68.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe68.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe68.ripe.net/submit-topic/presentation-formats/ - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -
pay.gov and IPv6
Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.atwrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at mailto:matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov http://pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
No issues for me over IPv6 on Comcast. Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? - Jared On Mar 17, 2014, at 2:55 PM, Matthew Kaufman matt...@matthew.at wrote: Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at mailto:matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov http://pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
Hi Matthew, in Italy I see the site pay.gov in IPv6, as you can see: [image: Immagine in linea 1] Regards, Marco 2014-03-17 19:43 GMT+01:00 Matthew Kaufman matt...@matthew.at: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman inline: image.png
Re: pay.gov and IPv6
One more (498?) set(s) of data points: I used RIPE ATLAS probes to check the SSL certificate over IPv6 (a nice way to check reachability).. Measurement# 1584700 You can look through the data to determine where it's not reachable from, but it seems to be generally reachable without issue from nearly all the probes. JSON link as well: https://atlas.ripe.net/api/v1/measurement/1584700/result/ - Jared On Mar 17, 2014, at 3:35 PM, Jared Mauch ja...@puck.nether.net wrote: No issues for me over IPv6 on Comcast. Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? - Jared On Mar 17, 2014, at 2:55 PM, Matthew Kaufman matt...@matthew.at wrote: Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at mailto:matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov http://pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
It was reachable by hand-typed URL, but the machines trying to follow a redirect from the FCC site during payment flow failed. Had to be brought back online, so once it was determined that turning v6 off was sufficient, that was the end if the debugging. Matthew Kaufman (Sent from my iPhone) On Mar 17, 2014, at 1:02 PM, Jared Mauch ja...@puck.nether.net wrote: One more (498?) set(s) of data points: I used RIPE ATLAS probes to check the SSL certificate over IPv6 (a nice way to check reachability).. Measurement# 1584700 You can look through the data to determine where it's not reachable from, but it seems to be generally reachable without issue from nearly all the probes. JSON link as well: https://atlas.ripe.net/api/v1/measurement/1584700/result/ - Jared On Mar 17, 2014, at 3:35 PM, Jared Mauch ja...@puck.nether.net wrote: No issues for me over IPv6 on Comcast. Perhaps some local network issue? Any reported issues if you try to visit http://www.test-ipv6.com/ ? - Jared On Mar 17, 2014, at 2:55 PM, Matthew Kaufman matt...@matthew.at wrote: Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.at mailto:matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov http://pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: pay.gov and IPv6
HE should work then, perhaps another problem + IPv6. -as On Mon, Mar 17, 2014 at 11:55 AM, Matthew Kaufman matt...@matthew.atwrote: Windows 8 running Google Chrome as the browser. Matthew Kaufman On 3/17/2014 11:46 AM, Arturo Servin wrote: No Happy Eyeballs? Perhaps also time to ditch XP and IE for something new as well. -as On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman matt...@matthew.atwrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of client computers that should be dual-stacked are now relegated to IPv4-only until someone remembers to turn it back on for each of them... sigh. Matthew Kaufman
Re: How to catch a cracker in the US?
On Mon, Mar 17, 2014 at 10:21 AM, Sholes, Joshua joshua_sho...@cable.comcast.com wrote: On 3/13/14, 7:35 PM, Larry Sheldon larryshel...@cox.net wrote: Not sure I can agree with that. I have been in this game for a very long time, but for most of it in places where the world's population cleaved neatly into two parts: Authorized Users who could be identified by the facts that they had ID cards, Badges, and knew the door code; and trespassers who were all others. Then you new kids came along and (pointlessly, in my opinion) divided the later group into the two described above. See, the way *I* learned it was that part of the creed of the hacker involved why would I want to play with your systems, mine are much cooler.; that is, by definition a hacker is in the first group. The point is that 'computer security' involves innovation as much as is done at hacker spaces (which can be geared to hardware or computer security or whatever). I think the difference you're trying to argue is the legality and not the task or process. I think calling the illegal form of the study of computer security cracking, the legal form hacking and people who are cracking who don't know what they're doing script kiddies is irrelevant, useless, and causes useless debates (that I started) like this.
Re: How to catch a cracker in the US?
On 3/17/2014 9:10 PM, shawn wilson wrote: The point is that 'computer security' involves innovation as much as is done at hacker spaces (which can be geared to hardware or computer security or whatever). I think the difference you're trying to argue is the legality and not the task or process. I think calling the illegal form of the study of computer security cracking, the legal form hacking and people who are cracking who don't know what they're doing script kiddies is irrelevant, useless, and causes useless debates (that I started) like this. CORRE! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
