Android and DHCPv6 again Yes but Android refuses to do IPv6 if there is any DHCPv6 on the network. It is a bug. SLAAC by default provides the address and default gateway (RA) If SLAAC managed flag is set, then DHCPv6 is used get the address and other configs (DNS, etc..) If SLAAC other flag is set, then SLAAC provides the address, and uses DHCPv6 to get the other configs (DNS, etc..) With SLAAC and without DHCPv6 the device has no way of knowing the DNS server and other configs such as search domain, etc... RFC 6106 provides a new feature that allows devices to obtain DNS from RA, but not all devices and network equipment support it yet. For devices that don't support RFC 6106 or DHCPv6, then it has to use IPv4 (DHCPv4) to get the IPv4 DNS address. Many Thanks =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dan Turner System Engineer | danturne@cisco.com Cisco Systems, Inc. | 2375 E. Camelback Rd. | Phoenix, AZ 85016 O. 602.778.2069 | C. 480.262.6017 | P. 800.365.4578 | TAC 800.553.2447 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From: NANOG <nanog-bounces@nanog.org<mailto:nanog-bounces@nanog.org>> on behalf of "nanog-request@nanog.org<mailto:nanog-request@nanog.org>" <nanog-request@nanog.org<mailto:nanog-request@nanog.org>> Reply-To: "nanog@nanog.org<mailto:nanog@nanog.org>" <nanog@nanog.org<mailto:nanog@nanog.org>> Date: Friday, October 16, 2015 at 5:00 AM To: "nanog@nanog.org<mailto:nanog@nanog.org>" <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: NANOG Digest, Vol 93, Issue 16 Send NANOG mailing list submissions to nanog@nanog.org<mailto:nanog@nanog.org> To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org<mailto:nanog-request@nanog.org> You can reach the person managing the list at nanog-owner@nanog.org<mailto:nanog-owner@nanog.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Android and DHCPv6 again (Ray Soucy) 2. Re: Microsoft / Outlook.com contact??? (Arnaud de Prelle) 3. Re: Microsoft blocking mail (Tei) 4. Google's peering, GGC, and congestion management (Baptiste Jonglez) 5. Re: Google's peering, GGC, and congestion management (Patrick W. Gilmore) 6. Re: geek whois (Randy Bush) 7. Re: Android and DHCPv6 again (Dave Bell) 8. Re: Android and DHCPv6 again (A.L.M.Buxey@lboro.ac.uk<mailto:A.L.M.Buxey@lboro.ac.uk>) 9. RE: Android and DHCPv6 again (Nicholas Warren) 10. Re: Packetfront/Waystream gear (Anders L?winger) 11. RE: Android and DHCPv6 again (Matthew Huff) 12. RE: Android and DHCPv6 again (Baldur Norddahl) 13. Re: Android and DHCPv6 again (Sander Steffann) 14. Re: Spamhaus contact needed (Larry Sheldon) 15. Re: Spamhaus contact needed (Jason Baugher) 16. Re: Spamhaus contact needed (Larry Sheldon) 17. Re: Spamhaus contact needed (Larry Sheldon) 18. Cogent BGP Woes (Justin Wilson - MTIN) 19. Re: Cogent BGP Woes (Josh Luthman) 20. AW: Cogent BGP Woes (J?rgen Jaritsch) 21. Re: Cogent BGP Woes (james machado) 22. RE: Cogent BGP Woes (Damien Burke) 23. Re: IPv6 Irony. (Owen DeLong) 24. Re: Google's peering, GGC, and congestion management (Baldur Norddahl) 25. Re: Google's peering, GGC, and congestion management (Patrick W. Gilmore) 26. ultradns / neustar outage? (Jim Mercer) 27. Re: ultradns / neustar outage? (N M) 28. Re: Google's peering, GGC, and congestion management (Baldur Norddahl) 29. Re: Google's peering, GGC, and congestion management (Patrick W. Gilmore) 30. Re: ultradns / neustar outage? (Curtis Generous) 31. Re: ultradns / neustar outage? (Hugo Slabbert) 32. Re: Android and DHCPv6 again (Lorenzo Colitti) 33. the fcc vs wifi lockdown issue (Dave Taht) 34. sfp "computer"? (Baldur Norddahl) 35. RE: sfp "computer"? (Jameson, Daniel) 36. Re: sfp "computer"? (Baldur Norddahl) 37. Re: Cogent BGP Woes (Justin Wilson - MTIN) 38. Re: Cogent BGP Woes (Justin Wilson - MTIN) 39. Re: Cogent BGP Woes (Carlos Alcantar) 40. Re: sfp "computer"? (joel jaeggli) 41. Re: the fcc vs wifi lockdown issue (Alejandro Acosta) 42. Re: Google's peering, GGC, and congestion management (Mark Tinka) 43. Re: Google's peering, GGC, and congestion management (Mark Tinka) 44. Re: sfp "computer"? (Ray Wong) 45. Re: Cogent BGP Woes (Mike Hammett) 46. inexpensive url-filtering db (MKS) 47. Re: IPv6 and Android auto conf (Anurag Bhatia) 48. Re: sfp "computer"? (Jerry Jones) 49. i hate october (Randy Bush) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Oct 2015 08:22:21 -0400 From: Ray Soucy <rps@maine.edu<mailto:rps@maine.edu>> To: Baldur Norddahl <baldur.norddahl@gmail.com<mailto:baldur.norddahl@gmail.com>> Cc: "nanog@nanog.org<mailto:nanog@nanog.org>" <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Android and DHCPv6 again Message-ID: <CALFTrnNT+jkXOBU4fwOWaCNkYxT3gN2ZqCHxJEcjrEyn2Q9Ddg@mail.gmail.com<mailto:CALFTrnNT+jkXOBU4fwOWaCNkYxT3gN2ZqCHxJEcjrEyn2Q9Ddg@mail.gmail.com>> Content-Type: text/plain; charset=UTF-8 Android does not have a complete IPv6 implementation and should not be IPv6 enabled. Please do your part and complain to Google that Android does not support DHCPv6 for address assignment. On Sat, Oct 3, 2015 at 9:52 PM, Baldur Norddahl <baldur.norddahl@gmail.com<mailto:baldur.norddahl@gmail.com>> wrote: Hi I noticed that my Nexus 9 tablet did not have any IPv6 although everything else in my house is IPv6 enabled. Then I noticed that my Samsung S6 was also without IPv6. Hmm. A little work with tcpdump and I got this: 03:27:15.978826 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::222:7ff:fe49:ffad > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 120 hop limit 0, Flags [*managed*, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s source link-address option (1), length 8 (1): 00:22:07:49:ff:ad mtu option (5), length 8 (1): 1500 prefix info option (3), length 32 (4): 2a00:7660:5c6::/64, Flags [onlink, *auto*], valid time 7040s, pref. time 1800s unknown option (24), length 16 (2): 0x0000: 3000 0000 1b80 2a00 7660 05c6 0000 So my CPE is actually doing DHCPv6 and some nice people at Google decided that it will be better for me to be without IPv6 in that case :-(. But it also has the auto flag, so Android should be able to do SLAAC yes? My Macbook Pro currently has the following set of addresses: en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 3c:15:c2:ba:76:d4 inet6 fe80::3e15:c2ff:feba:76d4%en0 prefixlen 64 scopeid 0x4 inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2a00:7660:5c6::3e15:c2ff:feba:76d4 prefixlen 64 autoconf inet6 2a00:7660:5c6::b5a5:5839:ca0f:267e prefixlen 64 autoconf temporary inet6 2a00:7660:5c6::899 prefixlen 64 dynamic nd6 options=1<PERFORMNUD> media: autoselect status: active To me it seems that the Macbook has one SLAAC address, one privacy extension address and one DHCPv6 managed address. In fact the CPE manufacturer is a little clever here. They gave me an easy address that I can use to access my computer ("899") while still allowing SLAAC and privacy extensions. If I want to open ports in my firewall I could do that to the "899" address. But why is my Android devices without IPv6 in this setup? Regards, Baldur -- *Ray Patrick Soucy* Network Engineer I Networkmaine, University of Maine System US:IT 207-561-3526 ------------------------------ Message: 2 Date: Thu, 15 Oct 2015 15:05:40 +0200 From: Arnaud de Prelle <arnaud@pnzone.net<mailto:arnaud@pnzone.net>> To: Robert Glover <robertg@garlic.com<mailto:robertg@garlic.com>> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Microsoft / Outlook.com contact??? Message-ID: <81a7288bfe53fc51ba63b757179c6806@icecube.pnzone.net<mailto:81a7288bfe53fc51ba63b757179c6806@icecube.pnzone.net>> Content-Type: text/plain; charset=US-ASCII; format=flowed On 2015-10-15 01:58, Robert Glover wrote: On 10/13/2015 10:49 PM, Michael J Wise wrote: Unfortunately, that's not going to work if the refusal reason was FBLW15 (or TBLW15). You're not dealing with an issue on the Outlook/Hotmail side of the house. If you had provided the last two octets, I might have been able to give some advice earlier, but alas, everyone seems loathe to actually say which IP is having issues. IP in question: 65.111.224.51 Not trying to hide anything, but seeing the posts with obfuscated IPs has rubbed off on me I suppose (for better or for worse. I appreciate if you can help us out here. -Bobby Hi Robert, I just experienced the same problem. It took 10 days before I got delisted without explanation. My IP is clean, never blacklisted, SPF+DKIM+DMARC, present in DNSWL.org, etc. Note that I had no issues for sending emails to @outlook.com. I only had issues (#FBLW15) when sending emails to Office365/ExchangeOnline users (i.e. @dowcorning.com in this case). Best Regards, Arnaud. ------------------------------ Message: 3 Date: Thu, 15 Oct 2015 15:50:14 +0200 From: Tei <oscar.vives@gmail.com<mailto:oscar.vives@gmail.com>> Cc: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Microsoft blocking mail Message-ID: <CACg3zYFdEyQrwyr+OugnrcoPVHexob+r9S2np2wTF8yM_PpW5w@mail.gmail.com<mailto:CACg3zYFdEyQrwyr+OugnrcoPVHexob+r9S2np2wTF8yM_PpW5w@mail.gmail.com>> Content-Type: text/plain; charset=UTF-8 On 18 September 2015 at 10:45, Marcin Cieslak <saper@saper.info<mailto:saper@saper.info>> wrote: On Fri, 18 Sep 2015, Tei wrote: On 18 September 2015 at 04:48, Keith Medcalf <kmedcalf@dessus.com<mailto:kmedcalf@dessus.com>> wrote:

Being blocked is probably a good thing ...

CGI forms that do the validation in the serverside are not up to modern expectations*. You want to do validation clientside. If you do client-side and no server-side, you have a huge security problem. ~Marcin By now is a industry standard. You have to do the validation serverside and clientside. This of course mean duplicated code. ( Excessively clever people have tried to solve the problem by using the same language/code in both the clientside and serverside. But this feels to me like a overreaction and you will be writing code unrelated to this in a new (?) language.... On top the... heurhg... creative pipelining.. to make the whole fa?ade works.) Collesterol High Clients + Collesterol High Servers. Unrelated: this is a funny article http://carlos.bueno.org/2014/11/cache.html -- -- ?in del ?ensaje. ------------------------------ Message: 4 Date: Wed, 14 Oct 2015 19:07:14 +0200 From: Baptiste Jonglez <baptiste@bitsofnetworks.org<mailto:baptiste@bitsofnetworks.org>> To: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Google's peering, GGC, and congestion management Message-ID: <20151014170714.GA16087@lud.polynome.dn42<mailto:20151014170714.GA16087@lud.polynome.dn42>> Content-Type: text/plain; charset="us-ascii" Hi, In its peering documentation [https://peering.google.com/about/traffic_management.html], Google claims that it can drive peering links at 100% utilisation: Congestion management Peering ports with Google can be run at 100% capacity in the short term, with low (<1-2%) packet loss. Please note that an ICMP ping may display packet loss due to ICMP rate limiting on our platforms. Please contact us to arrange a peering upgrade. How do they achieve this? More generally, is there any published work on how Google serves content from its CDN, the Google Global Cache? I'm especially interested in two aspects: - for a given eyeball network, on which basis are the CDN nodes selected? - is Google able to spread traffic over distinct peering links for the same eyeball network, in case some of the peering links become congested? If so, how do they measure congestion? Thanks for your input, Baptiste