Re: IPv6 addresses for Microsoft Office 365 hosted domains?
On a related note, I'm in the process of setting up mail for our new domain, and Office365 was one of the options. I was surprised to see that Office 365 hosted domains have only one MX, which resolves to only two IPv4 addresses: visser@cajones:~$ host geant-org.mail.protection.outlook.com. geant-org.mail.protection.outlook.com has address 213.199.154.87 geant-org.mail.protection.outlook.com has address 213.199.154.23 Both sit in the same network, which seems like a bad idea. Unless this is anycast? Can't tell from here. However, MS seems to have changed things recently: http://blogs.msdn.com/b/tzink/archive/2014/10/28/support-for-anonymous-inbound-email-over-ipv6-in-office-365.aspx Better late than never. The alternative for e-mail is Google Apps, which has IPv6 for years. Dick On 27 November 2014 at 03:00, Frank Bulk frnk...@iname.com wrote: This afternoon I saw several log messages in our email server's logs in relation to emails our local business customer (who uses our ISP email server) was trying to send to a Microsoft Office 365 hosted domain: [:::12.43.166.xx] Site target domain redacted (2a01:111:f400:7c0c::11) said after data sent: 554 5.7.1 Service unavailable, message sent over IPv6 [2607:fe28:0:4000::10] must pass SPF or DKIM validation (message not signed) The PTR for 2a01:111:f400:7c0c::11 is mail-by26c0c.inbound.protection.outlook.com. But when I check the MX record of the target domain I see there's no for the redacted.mail.eo.outlook.com, just three A's. Fortunately we control our local business customer's DNS and I've added in our email server's DKIM so that future emails, if they were sent over IPv6, should be accepted by Microsoft. Our customer has no SPF record. I also saw two log messages for two Microsoft Office 365 hosted domains: 26 13:30:59.00 [56882563] Failed :::199.120.69.25 notification+kyg2k...@facebookmail.com target domain1 email redacted 9259 1502549920004098-1497189607206...@groups.facebook.com [:::199.120.69.25] ubad=0, Site (target domain1 redacted/2a01:111:f400:7c10::1:10) said: 550 5.2.1 Service Unavailable, [target domain1 redacted] does not accept email over IPv6 26 19:04:52.00 [83985160] Failed :::12.43.166.20 from redacted target domain2 email redacted 6546 0EBCBB96763E41B2A4CD9A4CD3DD94BE@sp.local [:::12.43.166.20] ubad=1, Site (target domain2 email redacted/2a01:111:f400:7c0c::11) said: 550 5.2.1 Service Unavailable, [target domain2 email redacted] does not accept email over IPv6 There's no PTR for 2a01:111:f400:7c10::1:10. I checked the last 7 days of logs I only saw these today. It's like Microsoft published some 's for some MX records, but then withdrew them, but not before there were a few failures. Frank -- Dick Visser Sr. System Networking Engineer GÉANT Association, Amsterdam Office (formerly TERENA) Singel 468D, 1017 AW Amsterdam, the Netherlands Tel: +31 (0) 20 530 4488 GÉANT Association Networking. Services. People. Learn more at: http://www.géant.org
Re: Poll on SMTP over IPv6 Usage
On 13 February 2014 21:23, James Small jim.sm...@mail.com wrote: Interested in what you’re using to send/receive SMTP over IPv6: A) Using Postfix on Ubuntu, for mailing lists B) Using Google Apps for Education for MX/SMTP -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands
So, time for some real action?
http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-off-ipv4-on-6-june-2014-for-one-day/ I fully support this idea. But I'm in doubt what to actually do on 6 June. There isn't much benefit in turning off IPv4 on client devices in our office, because we already have a good idea what will work and what won't. Turning off IPv4 on all internet facing services would be better, because it will point out any IPv6 connectivity problems that visitors have. In that case, I can go about this in several ways. Doing it through (low TTL + removal of A records) gives you less control over things. If you block IPv4 access at the service level (filtering/ACLs), then it's easier to restore things. Maybe some intermediate solution, such as serving up an explanation page to IPv4 users? Other ideas? -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands
Re: So, time for some real action?
I know there are different opinions on this. But between black and white there are many shades of grey. That's why I was asking. I know that some stuff will break, I'm looking for ways to put this 'breakage' to positive use. On 6 February 2014 16:48, Nick Hilliard n...@foobar.org wrote: On 06/02/2014 14:51, Dick Visser wrote: http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-off-ipv4-on-6-june-2014-for-one-day/ This is a terrible idea which will cause IPv6 to be associated with gratuitous breakage. Nick -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands
Re: 'Upgrading' NAT64 to 464XLAT?
Well, to be honest that wasn't even clear to me ;-) I just am reading up on the RFC and it looks like it doesn't have to be on the end host necessarily: http://tools.ietf.org/html/rfc6877#section-6.5 Time for me to read the rfcs in their entirety On 25 November 2013 15:22, Eric Vyncke (evyncke) evyn...@cisco.com wrote: Dick 464XLAT is contained within a host, so, you will need an implementation for all your end host (laptop, tablets, ...) But, I am sure that you already know that ;-) -Original Message- From: ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de [mailto:ipv6-ops-bounces+evyncke=cisco@lists.cluenet.de] On Behalf Of Dick Visser Sent: lundi 25 novembre 2013 14:20 To: ipv6-ops@lists.cluenet.de Subject: 'Upgrading' NAT64 to 464XLAT? hi guys We've been running a NAT64/DNS64 set-up for a while now on some parts of our office network. This seems to work well, but it doens't work for everything (e.g. Skype etc). If those apps were working, it would be possible to actually use if for production. I was reading about 464XLAT, and from what I understand, this is more or less NAT64, but with some sort of local (RFC1918) IPv4 in the mix. For phones this is done using a special daemon that provides a local IPv4 address. I'd like to 'upgrade' out existing NAT64/DNS64 setup to do 464XLAT, but there aren't many docs about how to set 464XLAT to begin with. I've seen https://sites.google.com/site/tmoipv6/464xlat, and I asked around here and there. A schema with actual addresses would be nice, but I can't find that. Since we have an office set-up with, I assume I should configure the IPv6-only VLAN so that RFC1918 addresses are handed out on it as well? What I don't understand, if a device gets an RFC1918 IPv4 address, and a global IPv6 address, how would it be possible that apps that support IPv6-only use the IPv6 path? I can imagine that some applications still prefer to take the IPv4 path? Thanks!! -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands
Avoiding EUI64 addresses on Ubuntu 12.04
Hi I'm trying to configure an Ubuntu 12.04 Server VM with static IP addresses. The config is this: # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.87.38.9 netmask 255.255.255.192 gateway 192.87.38.1 # IPv6 static address iface eth0 inet6 static address 2001:610:148:cafe::9 netmask 64 autoconf 0 privext 0 dns-search terena.org dns-domain terena.org dns-nameservers 2001:610:1:800a:192:87:106:106 2001:610:188:140:145:100:188:188 Because there is a bug in network-manager, I also set this in /etc/sysctl.d/10-ipv6-privacy.conf: net.ipv6.conf.all.use_tempaddr = 0 net.ipv6.conf.default.use_tempaddr = 0 After rebooting I still have the EUI64 address: eth0 Link encap:Ethernet HWaddr 00:50:56:86:00:0f inet addr:192.87.38.9 Bcast:192.87.38.63 Mask:255.255.255.192 inet6 addr: 2001:610:148:cafe:250:56ff:fe86:f/64 Scope:Global inet6 addr: fe80::250:56ff:fe86:f/64 Scope:Link inet6 addr: 2001:610:148:cafe::9/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:477 errors:0 dropped:0 overruns:0 frame:0 TX packets:474 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:90380 (90.3 KB) TX bytes:76199 (76.1 KB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:222 errors:0 dropped:0 overruns:0 frame:0 TX packets:222 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16746 (16.7 KB) TX bytes:16746 (16.7 KB) Any idea how to get rid of it? This is a server, and I don't want privacy/security extensions, just the manually configured address. Thanks!!! -- Dick Visser System Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands
