May 2012 - Test - lists.nanog.org

the report from the spambox front
by Randy Bush 29 May '12

29 May '12

as part of daily maint, where i read midnight logs from 20+ systems etc, i scan my spambox to make sure nothing falls through, and indeed catch one or two daily. but the spam is a source of great amusement. the internet is an wondrous place. the number of messages offering help for the serious bedbug problem has been dropping off recently. so there really is hope we are winning the war on the bedbug front. whew! fedex has so many dell xps laptops in transit to me that storing them looks to become a serious problem. anyone with some space in a storage locker near jimbocho? zita would really like to take advantage of all the free lobsters, but there is no red lobster we know of in tokyo [0]. as tokyo has everything, i am sure i could find one. but will they take an american coupon? a lot of russians are still trying to draw my attention to something which is obviously important. anyone out there read russian? i hope it is not something critical, like news on the bedbugs in moscow. we would love to take advantage of all the great clearance sales on fords, but the cost of garaging a car, especially a large one, in tokyo is a bit steep. randy, who has to run out to the accountant to keep up with all the fraud monitoring reports on my bank accounts and credit cards in the caymans.

3 2

Re: NANOG Digest, Vol 52, Issue 67
by carl gough [mobsource] 29 May '12

29 May '12

Does anyone have any intel on bandwidth trading in the usa? [carl gough] founder and CEO +61 425 266 764 mobsource .com defined by benefits not by technology Skype mobsource Follow @mobsource Facebook mobsource On 29/05/12 7:52 PM, "nanog-request(a)nanog.org" <nanog-request(a)nanog.org> wrote: >Send NANOG mailing list submissions to > nanog(a)nanog.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog >or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > >You can reach the person managing the list at > nanog-owner(a)nanog.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of NANOG digest..." > > >Today's Topics: > > 1. IPv6 security: New IETF I-Ds, slideware and videos of recent > presentations, trainings, etc... (Fernando Gont) > 2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 4. Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies (Jimmy Hess) > 5. Re: NXDomain remapping, DNSSEC, Layer 9, and you. > (bmanning(a)vacation.karoshi.com) > 6. Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies (Randy Bush) > 7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert) > 9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 28 May 2012 22:17:33 -0300 >From: Fernando Gont <fernando(a)gont.com.ar> >To: NANOG <nanog(a)nanog.org> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent > presentations, trainings, etc... >Message-ID: <4FC423AD.5000703(a)gont.com.ar> >Content-Type: text/plain; charset=ISO-8859-1 > >Folks, > >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting >Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like >protection against rogue DHCPv6 servers. The I-D is available at: ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> >Other IPv6 security I-Ds (such as, >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please >check them out at: ><http://www.si6networks.com/publications/ietf.html> > >* The slideware (and some videos!) of some of our recent presentations >about IPv6 security are now available online. You can find them at: ><http://www.si6networks.com/presentations/index.html> > >* We have also scheduled IPv6 hacking trainings in Paris (France) and >Ghent (Belgium). You can find more details at: ><http://www.si6networks.com/index.html#conferences> > >Our Twitter: @SI6Networks >ipv6hackers mailing-list: ><http://lists.si6networks.com/listinfo/ipv6hackers/> > >Thanks! > >Best regards, >-- >Fernando Gont >SI6 Networks >e-mail: fgont(a)si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > >-- >Fernando Gont >e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > >------------------------------ > >Message: 2 >Date: Tue, 29 May 2012 12:38:23 +1000 >From: Mark Andrews <marka(a)isc.org> >To: Jay Ashworth <jra(a)baylink.com> >Cc: NANOG <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529023823.C2B5220FE5A8(a)drugs.dv.isc.org> > > >In message ><23491623.6382.1338256344974.JavaMail.root(a)benjamin.baylink.com>, Jay >Ashworth writ >es: >> ----- Original Message ----- >> > From: "Mark Andrews" <marka(a)isc.org> >> >> [ vix: ] >> > > > meanwhile isc continues to push for ubiquitous dnssec, through to >> > > > the stub, >> > > > to take this issue off the table for all people and all time. >> > > > (that's "the >> > > > real fix" for nxdomain remapping.) >> > > >> > > You really believe that the outcome of that will be "we can't make >> > > some >> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the >> > > hell >> > > with DNSSEC, then"? >> > >> > People will route around ISP that do stupid things. They do so >> > today. When your browers supports DANE there will be more incentive >> > to ensure that DNSSEC does not break and more incentive to route >> > around ISP's that do break DNSSEC. >> >> My personal reaction to that, Mark, is to say that you *badly* >>overestimate >> the average Internet end-user (who make up, roughly, 80% of the >>endpoints, >> in my jackleg estimation). > >Google's recursive nameservers see plenty of traffic. > >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that >> > it is a real NXDOMAIN not one that is spoofed do the path to the >> > ISP's resolver will be DNSSEC clean and they will be validating. >> >> I'm not sure I understood that... > > Authoritative server > ^ > secure > (DO=1 queries) > v > ISP's validating recursive server > ^ > insecure, redirect possible > (DO=0 queries) > v > Stub clients. > >Putting it another way, the ISP doesn't want to be fooled even if >it is fooling its customers. The ISP can't allow it's recursive >servers to get the wrong answers for irs.gov, picking a signed >domain, as they would look silly for not validating when there is >a simple way for them to be sure that they are not being spoofed. > >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't >> > be a problem for ISP's that want to do nxdomain redirection. There >> > still plenty of crappy DNS proxies in CPE routers to be replaced >> > before you can just set DO=1 as a default without worrying about >> > breaking DNS lookups. Even setting EDNS as a default is a issue. >> >> ...but that's probably because I don't understand DNSSEC well enough. > >The ISP <-> stub client path often has a additional piece in the >path that is often a heap of steaming !@$! that doesn't do basic >DNS let alone EDNS and DNSSEC. For example the Netgear router at >home doesn't support DNS over TCP which is basic DNS (I'm using it >as a access point not a router because of this). It's this sort >of breakage that is stopping OS vendors changing defaults. This >can often be bypassed by forcing the resolver to use the ISP's >nameservers directly but you need to know to do that. > > ISP's validating recursive server > ^ > v > CPE Router (broken DNS proxy code) > ^ > v > Stub clients. > >You can also replace CPE Router with a broken firewall that is a >steaming heap of !@#% when it comes to DNS packet inspection. These >are harder to bypass and require someone to fix the configuration >to replace/upgrade the box. > >> > That said we are starting down the long path to making it EDNS a >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace" >> > turns set DO=1 as well. You don't get things fixed if the breakage >> > is not visible. >> >> We may be talking about different breakage here... >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >>jra(a)baylink.com >> Designer The Things I Think >>RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >>Rover DII >> St Petersburg FL USA http://photo.imageinc.us +1 727 >>647 1274 >> >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org > > > >------------------------------ > >Message: 3 >Date: Tue, 29 May 2012 12:47:10 +1000 >From: Mark Andrews <marka(a)isc.org> >To: Jimmy Hess <mysidia(a)gmail.com> >Cc: NANOG <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529024710.8971D20FE6A0(a)drugs.dv.isc.org> > > >In message ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg(a)mail.gmail.com> >, Jimmy Hess writes: >> On 5/28/12, Mark Andrews <marka(a)isc.org> wrote: >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't >> > be a problem for ISP's that want to do nxdomain redirection. There >> >> Yeah............. >> Right now current _server_ implementations don't even have it right, >> for properly implementing DNSSEC validation down to that level, let >> alone the stubs below the server. >> >> Many SME LANs utilize Windows-based endpoints, and commonly have >> Windows-based DNS servers on the LAN, used by endpoints, where the >> Windows DNS servers are set to forward queries to ISP recursive >> servers. Current Windows' DNS server in 2008 "supports" DNSSEC. >> When Windows DNS server is configured to forward DNS queries to a >> list of reasonable recursive DNS servers, the server sets CD (Check >> disabled) bit set, and the DO bit set for all queries it sends; >> there is no option to "support dnssec queries from smart stubs but >> don't send queries from dumb stubs with CD". > >Well I'm trying to get this fixed at the protocol level for other >reasons as explained in >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html > >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last >call and if you think always setting CD=1 when forwarding is bad for >whatever reason I could do with some support. > >> Also, there are by default no trust anchors, and _Every_ response is >> treated as valid. (In other words, CD bit and DO bits are set in >> forwarded queries, but no validation occurs). >> It's kind of like having a SSL implementation that treats ALL SSL >> certificates as valid, until and unless you take manual steps to >> configure a CA list. >> >> If you don't like this default and want to configure Windows DNS with >> the root trust anchor.... Sorry, Algorithm #5 RSA/SHA-1 is the only >> supported key type, and the current root signing key is not of a >> compatible format. >> >> Your "smart" stub can send a query to this broken DNSSEC >> implementation with the DO bit set, for sure. >> >> >> >> >> > still plenty of crappy DNS proxies in CPE routers to be replaced >> > before you can just set DO=1 as a default without worrying about >> > breaking DNS lookups. Even setting EDNS as a default is a issue. >> [snip] >> >> I'm all for smart stubs as long as (1) They can get the data to them >> (2) They can get the proper logging/reporting to them, E.g. No >> "silent" upstream validate/discard; No upstream silent "ignore >> the stub's requested CD bit and validate/discard anyways" >> and >> >> (3) The validation path is intact for _dumb_ non-validating stubs too. >> >> -- >> -JH >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org > > > >------------------------------ > >Message: 4 >Date: Mon, 28 May 2012 23:58:00 -0500 >From: Jimmy Hess <mysidia(a)gmail.com> >To: David Conrad <drc(a)virtualized.org> >Cc: NANOG Mailing List <nanog(a)nanog.org> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies >Message-ID: > <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On 5/28/12, David Conrad <drc(a)virtualized.org> wrote: >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote: >>> I know few registry/registrars >>> which do not accept both (or all) name servers of domain name on same >>> subnet. They demand at least 1 DNS server should be on different >>>subnet for >>> failover reasons (old thoughts). >> IMHO appropriately so. The fact that anycast allows for multiple >> (potentially) geographically distributed machines to respond to DNS >>queries >> does not remove the value of having multiple prefixes for DNS servers. >[snip] >It dramatically reduces the value, and meets the basic RFC requirement >for geographically distributed DNS servers, although there are still >routing issues that will impact all DNS servers to share a prefix >It is more important that a domain registrar not refuse to register a >domain, or erroneously declare a valid listing invalid. > >The purpose of using a registrar is to establish DNS delegation, not >to validate your site's redundancy meets the absolute best possible >practices for fault tolerance. > >Ideally certainly should have DNS servers under multiple prefixes -- >and it seems a little bit silly to go through all the trouble of >implementing a complicated anycast geo. dist scheme, while ignoring >a simpler failure mode. It's your choice. > >It's not appropriately so for a registrar to say anything your choice; >thats your network >not theirs. By the same token the registrar can't tell you not to >alias all 3 IP addresses on >different subnets to the same physical server. > >Again, it's ill-advised, but a "mistake" that has nothing to do with >the registrar's network or the registration service. > >-- >-JH > > > >------------------------------ > >Message: 5 >Date: Tue, 29 May 2012 05:59:19 +0000 >From: bmanning(a)vacation.karoshi.com >To: Mark Andrews <marka(a)isc.org> >Cc: NANOG <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529055919.GA23179(a)vacation.karoshi.com.> >Content-Type: text/plain; charset=us-ascii > >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >> >> Putting it another way, the ISP doesn't want to be fooled even if >> it is fooling its customers. > > don't lie to us, but we lie to our customers. > > and you don't see a problem with this? > >/bill > > > >------------------------------ > >Message: 6 >Date: Tue, 29 May 2012 15:13:33 +0900 >From: Randy Bush <randy(a)psg.com> >To: Jimmy Hess <mysidia(a)gmail.com> >Cc: North American Network Operators' Group <nanog(a)nanog.org> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies >Message-ID: <m2txyzikfm.wl%randy(a)psg.com> >Content-Type: text/plain; charset=US-ASCII > >> It is more important that a domain registrar not refuse to register a >> domain, or erroneously declare a valid listing invalid. >> >> The purpose of using a registrar is to establish DNS delegation, not >> to validate your site's redundancy meets the absolute best possible >> practices for fault tolerance. > >just for my curiosity, where do you draw the line for technical >compliance? do the servers need to serve the zone? does the served >zone need to have the same NS RRset as the request and hence parent? >do the servers need to be able to answer compliant dns queries? over >tcp too? > >your first paragraph quoted above would seem to say that none of this is >needed. the registrar's job is to stick the delegation in the parent >zone and actually functioning name service be damned. > >randy, a naggumite > > > >------------------------------ > >Message: 7 >Date: Tue, 29 May 2012 16:37:29 +1000 >From: Mark Andrews <marka(a)isc.org> >To: bmanning(a)vacation.karoshi.com >Cc: NANOG <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529063731.686622106AEB(a)drugs.dv.isc.org> > > >In message <20120529055919.GA23179(a)vacation.karoshi.com.>, >bmanning(a)vacation.ka >roshi.com writes: >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >> > >> > Putting it another way, the ISP doesn't want to be fooled even if >> > it is fooling its customers. >> >> don't lie to us, but we lie to our customers. >> >> and you don't see a problem with this? > >I didn't say I like it. It may even be illegal in some juristictions >for a ISP to do it without properly informing the customer and >allowing them to opt in/out. Doing it to yourself however can't >be illegal. In the end it is a tool and the method of deployment >is often as important as whether you deploy it or not. > >It's a little like direct marketing via email. If you have consent >of the party being emailed it isn't spam. If you don't have consent >it is spam at least here in Australia. Other juristictions have >looser guidelines. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org > > > >------------------------------ > >Message: 8 >Date: Mon, 28 May 2012 23:42:14 -0700 >From: George Herbert <george.herbert(a)gmail.com> >To: "bmanning(a)vacation.karoshi.com" <bmanning(a)vacation.karoshi.com> >Cc: NANOG <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7(a)gmail.com> >Content-Type: text/plain; charset=us-ascii > > > > > >On May 28, 2012, at 22:59, bmanning(a)vacation.karoshi.com wrote: > >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >>> >>> Putting it another way, the ISP doesn't want to be fooled even if >>> it is fooling its customers. >> >> don't lie to us, but we lie to our customers. >> >> and you don't see a problem with this? >> >> /bill > >We tried saying no, we tried walking customers away, we tried not adding >the feature, we tried shame, someone reputedly had dolls with pins in >them. > >We lost. > >There is an endgame around that; when it's ready.... > > >George William Herbert >Sent from my iPhone > > >------------------------------ > >Message: 9 >Date: Tue, 29 May 2012 10:51:54 +0100 >From: Tony Finch <dot(a)dotat.at> >To: Randy Bush <randy(a)psg.com> >Cc: North American Network Operators' Group <nanog(a)nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: > <alpine.LSU.2.00.1205291050540.5807(a)hermes-2.csi.cam.ac.uk> >Content-Type: TEXT/PLAIN; charset=US-ASCII > >Randy Bush <randy(a)psg.com> wrote: >> >> > When your browers supports DANE >> >> and a billion home nats support dnssec :( > >I expect there will be a depressingly large amount of DNS-over-TLS in the >future in order to bypass broken ALGs. > >Tony. >-- >f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate, >occasionally very poor. > > > >End of NANOG Digest, Vol 52, Issue 67 >*************************************

8 8

Re: ISPs and full packet inspection
by Keith McCallion 29 May '12

29 May '12

On Thu, May 24, 2012 7:36 pm, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Justin M. Streiner" <streiner(a)cluebyfour.org> >> Aside from all of the business and legal sticking points that others have >> mentioned, there are also the technical aspects of capturing, storing, transporting, analyzing, and managing those packets, and the appliances that do the heavy lifting. As your traffic grows, that problem scales 1:1 linearly, at best, and more likely n:1 linearly, or worse. The added overhead of the infrastructure needed to support this will also make >> it more difficult to be price-competitive with your peers. > TL:DR; The reasons for doing this on any kind of general basis have to be *EXCEPTIONALLY* compelling to make a business case for it, apart from any possible legal ramifications. > I used asterisks *and* capital letters; that's about an order of magnitude. > Don't forget staffing. I am a little surprised no one has referenced Wired's recent article about Libya's Internet Surveillance systems: http://www.wired.com/threatlevel/2012/05/ff_libya/all/1 It's good reading and I think does a good job of summarizing both the technical challenges but also the political implications of such a system. -Keith

2 1

Bogon list update for prefix for 5.1.0.0/19
by Evgeniy Aikashev 29 May '12

29 May '12

Dear all, We are AS21219 - PJSC Datagroup and owner of 5.1.0.0/19 block. Our customers have no access to some part of Internet if they use these IPs. Could you please update your bogon filters to permit this range. Thanks. -- Best regards, Evgeniy Aikashev network engineer PJSC DATAGROUP

8 7

Video streaming over IPv6
by Carlos Martinez-Cagnazzo 29 May '12

29 May '12

Hello, Can anyone comment on the availability of IPv6 video streaming services? I'm thinking about commercial, 'cloud'-based services a la U-Stream or Make.TV. I can roll my own, and will eventually do so, but having a commercial service that I could use would make my life so much easier :-) Any such service who is thinking about jumping on the World IPv6 Launch Day bandwagon and could use some (I'd like to think clueful) debugging can also contact me, we might be able to work something out. regards, Carlos

4 4

DNS anycasting - multiple DNS servers on same subnet Vs registrar/registry policies
by Anurag Bhatia 29 May '12

29 May '12

Greetings everyone! One small concern I wanted to discuss here. I know few registry/registrars which do not accept both (or all) name servers of domain name on same subnet. They demand at least 1 DNS server should be on different subnet for failover reasons (old thoughts). How one can deal with such case in case of anycasting setup which using one single subnet everywhere? Anyone else in community got similar issues? Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia>| Google+ <https://plus.google.com/118280168625121532854>

6 9

Search Link between changzhou (china) and Singapore
by Olivier CALVANO 29 May '12

29 May '12

Hi I am search a operator for a Layer 2 Link (if possible) between: Changzhou (china) Equinix Singapore anyone know operators for this ? thanks olivier

1 0

Re: DNS anycasting - multiple DNS servers on same subnet Vs registrar/registry policies
by Stephane Bortzmeyer 29 May '12

29 May '12

On Tue, May 29, 2012 at 12:21:10AM +0530, Anurag Bhatia <me(a)anuragbhatia.com> wrote a message of 28 lines which said: > I know few registry/registrars which do not accept both (or all) > name servers of domain name on same subnet. Since my employer is one of these registries, let me mention that I fully agree with David Conrad here. On Tue, May 29, 2012 at 12:54:01AM +0530, Anurag Bhatia <me(a)anuragbhatia.com> wrote a message of 42 lines which said: > I am building redundancy within that setup. I mean it will be > software based BGP so if hardware if fried up, it will break BGP > session and pull off routes anyway and for cases like DNS server > (software) failure, I will monitor it via simple bash script which > can turn bgp daemon down. You will address *some* failure modes with this setup but not all. Again, see David Conrad's examples of a fat finger adding your prefix in a route-map.

4 4

Re: NXDomain remapping, DNSSEC, Layer 9, and you.
by George Herbert 29 May '12

29 May '12

On May 28, 2012, at 22:59, bmanning(a)vacation.karoshi.com wrote: > On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >> >> Putting it another way, the ISP doesn't want to be fooled even if >> it is fooling its customers. > > don't lie to us, but we lie to our customers. > > and you don't see a problem with this? > > /bill We tried saying no, we tried walking customers away, we tried not adding the feature, we tried shame, someone reputedly had dolls with pins in them. We lost. There is an endgame around that; when it's ready.... George William Herbert Sent from my iPhone

1 0

IPv6 security: New IETF I-Ds, slideware and videos of recent presentations, trainings, etc...
by Fernando Gont 28 May '12

28 May '12

Folks, * We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like protection against rogue DHCPv6 servers. The I-D is available at: <http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> Other IPv6 security I-Ds (such as, draft-ietf-v6ops-ra-guard-implementation) have been revised. Please check them out at: <http://www.si6networks.com/publications/ietf.html> * The slideware (and some videos!) of some of our recent presentations about IPv6 security are now available online. You can find them at: <http://www.si6networks.com/presentations/index.html> * We have also scheduled IPv6 hacking trainings in Paris (France) and Ghent (Belgium). You can find more details at: <http://www.si6networks.com/index.html#conferences> Our Twitter: @SI6Networks ipv6hackers mailing-list: <http://lists.si6networks.com/listinfo/ipv6hackers/> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0