Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi Ole, > Op 2 apr. 2020, om 12:10 heeft otr...@employees.org het volgende geschreven: > >> DHCPv6 took itself out of the running when it failed to provide the >> default gateway to its clients. > > I just posted an updated version of what was the "Universal RA option" draft. > It is now the "Universal IPv6 Configuration Option", which includes support > for default gateway in DHCPv6. > > https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1 Ha! You finally accepted my idea from years ago :) One set of options with two distribution protocols (one push and one pull model) Cheers, SAnder signature.asc Description: Message signed with OpenPGP
Re: IPv6 ingress filtering
Hi David, > While I happen to agree with you 2002::/16 SHOULD NOT be filtered, and RFC > 7526 is quite clear that 2002::/16 is still valid. However, it is perfectly > permissible to filter it, if that is the policy a network operator wishes to > enforce. With the 6to4 anycast relays deprecated the only 6to4 traffic should be src 2002::/16 and dst 2002::/16. Sites that are not using 6to4 themselves can filter 2002::/16. Everybody else will only see IPv4+proto41 traffic, which is not impacted by that filter. Cheers, Sander signature.asc Description: Message signed with OpenPGP
Re: CPE Residential IPv6 Security Poll
Hi, > For what it's worth, the Swisscom approach seems sensible to me. At > least if I understand it correctly, in that they by default only block > ports associated with application protocols known to be insecure, meant > for home network use only, etc. All other ports and protocols not on > the blacklist are let through in both directions. As far as I know this > has been working out fine for them. I like that approach as well. It might be generalised into "ports <= x are blocked by default and can be opened manually, ports > x are open by default". Whether x=1024, x=1 or x=16384 can be discussed. If usually services aren't listening on those high-numbered ports then the firewall blocking incoming packets for them doesn't make much of a difference anyway. Cheers, Sander signature.asc Description: Message signed with OpenPGP using GPGMail
Re: A=1 L=0 PIO
Hi Mikael, > I'm trying to figure out what a "normal" currently deployed in the field IPv6 > host would do if it receives an RA with PIO /64 where L=0 and A=1. On an implementation level what I have seen on Linux is that the L flag determines whether the route 2001:db8::/64 -> eth0 is installed or not. Cheers, Sander signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Some very nice broken IPv6 networks at Google and Akamai
Hi Lorenzo, Op 9 nov. 2014, om 22:10 heeft Lorenzo Colitti lore...@google.com het volgende geschreven: On Sat, Nov 8, 2014 at 11:48 PM, Jeroen Massar jer...@massar.ch wrote: The issue with IPv6 access to Google should now be resolved. Please let us know if you're still having problems. The fun question of course is: what/why/how the heck happened? Another fun question is why folks are relying on PMTUD instead of adjusting their MTU settings (e.g., via RAs). But relying on PMTUD still imposes a 1-RTT penalty on every TCP connection to an IPv6 address you haven't talked to in the last few minutes. Why would you do that to your connection? I guess most users wouldn't really notice a 1-RTT delay. But I agree that it is less than optimal that every outbound connection from a network behind a non-1500-MTU link has to suffer this penalty. Unfortunately the current choices seem to be to either limit the link MTU (and making traffic to e.g. the local NAS suffer as well) or suffer the 1-RTT penalty. As to what happened: what happened here is that some Google servers temporarily stopped doing MSS clamping. That was an outage, and AIUI it has since been fixed. (Some parts of) Google infrastructure do not do PMTUD for the latency reasons above and for reasons similar to those listed in https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-00 . Thank you for the information. Great to have real data instead of guesses and speculation :) Cheers! Sander
Re: Some very nice broken IPv6 networks at Google and Akamai
Hi Philipp, Op 10 nov. 2014 om 21:09 heeft Philipp Kern pk...@debian.org het volgende geschreven: On Mon, Nov 10, 2014 at 07:36:22PM +0100, Sander Steffann wrote: I guess most users wouldn't really notice a 1-RTT delay. Depends on the RTT. In mobile networks it generally sucks. Good point :) Sander
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
Hi Andrew, Please help me understand. The standards' purpose is to facilitate the interoperability. MLD snooping happens within a single device. Its only result in a correct implementation must be if you join the group, you should get the traffic, if you did not, you should not function. A result of composition of multiple independent correct implementations of this function remains the same - if you join the group, you should get the traffic, if you did not, you should not. So, which undefined behaviors that prevent the interop today do you think would need to be standardized ? Maybe it's as simple as writing down what you described :) Standards don't have to be complicated. Maybe it can describe how a device should operate in certain failure scenarios like when 1000 hosts join 500 multicast groups each and the switch runs out of memory/CPU/etc. The most 'interesting' interoperability problems occur when different devices behave in different ways in weird situations :) And maybe it is just as simple as you describe :) Cheers, Sander
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
Hi Mikael, Op 21 sep. 2014, om 07:45 heeft Mikael Abrahamsson swm...@swm.pp.se het volgende geschreven: On Wed, 17 Sep 2014, Enno Rey wrote: it should be noted that RFC 4541 is an Informational one and I don't think any normative value for a kind-of vendor-proprietary thing called MLD snooping might be attached to it ;-) I would like to see IGMP and MLD snooping properly standardized. Big +1 Sander
Re: Something with filters
Hi, Especially a check for a zero'd address is really not that hard; it is just crazyness that that is not checked for. If possible, please file this problem with your relevant technical contacts and account managers, as it is just nonsense that that packet is allowed to travel over the Internet. Reminds me of someone showing me a packet with link-local source address and global destination address traveling several hops... :) Cheers, Sander
Re: why don't we start an ipv6 smtp server whitelist?
Hi, ..so, why don't spamhaus or some other well-known email related community don't start an ipv6 mail servers whitelist trying to take onboard gmail, yahoo, aol, microsoft, and other big mail provider? for postmasters it will be only one more little work to do (subscribe MTAs to the whitelist), but it will also help them having servers with a better score on antispams and it will push the ipv6 deployment (if my servers has ipv6 I may be whitelisted and have a better score, so I have a plus running ipv6) ok, now write me all the bugs in this idea :) Something similar has already been tried: http://www.ipv6whitelist.eu That attempt has failed, but you might be able to learn from their experience. Cheers, Sander
Re: IPv6 Assignment for Server
Hi, This is TB is just a government organization which was established to study/develop in field of technology. And TB is one of some services that still be in implement phase. Ah, so there is still time to fix things :) One of the great things of IPv6 is that addresses are plentiful. Especially when doing studies and development this is important. We don't want to force people to learn IPv6 with unnecessary limitations, the users need to be able to make use of the main feature of IPv6. I have worked with government entities before in cases like this. Feel free to give them my email address :) And I'm sure there are more people on this list that can assist! Cheers, Sander
Re: Residential subscribers: numbered or unnumbered?
Hi Philip, Until recently, I was under the impression that most people were using numbered v6 links to residential subscribers, allocating the WAN address using DHCPv6. However, recently two people have told me about a number of providers that are doing unnumbered instead. So for anyone who has deployed or is planning to deploy residential IPv6, I am curious to know which way you are going, and more importantly why you selected that approach? My interest is primarily in IPoE, but I don't mind hearing about PPPoE as well. I'm doing unnumbered PPPoE to residential, which works fine. Each customer gets a prefix through DHCPv6-PD. The PPPoE routers (ASR1k) talk DHCPv6-PD to the customer and RADIUS to our management system. It automatically injects the route for the delegated prefix towards the link + link-local address of the customer. The reason for this is simplicity in the addressing plan. This way we have one prefix per customer, which we completely delegate to them. If the link was numbered we would need another /64 for the link. Which would mean that we have to assign and track two prefixes to each customer: the link /64 and the delegated /56. We would very probably never see any traffic from the /64, but we do need to track it (legal stuff etc). Additional questions for those who have chosen the unnumbered approach or are using SLAAC to number the WAN address. * What are you doing wrt having an address to ping to confirm the CPE is reachable? The CPEs we give to customers have a pingable address from the delegated prefix (prefix::1). And we can always see if the CPE is online by checking the PPPoE session. * For those doing unnumbered, do all CPEs implement the same algorithm for selecting the loopback address according to WAA-7 in RFC 7084? As far as I know: yes. Almost all customers use the CPE that we provide though, so I might just be lucky :) Cheers, Sander
Re: Poll on SMTP over IPv6 Usage
A) Using Postfix (product) from Wietse (vendor) B) Using AS57771 and AS12414 (service provider or “cloud solution”) C) Elected not to implement SMTP over IPv6 at this time because N.A. Fully IPv6 capable (reason) Sander
Re: MTU handling in 6RD deployments
Hi, In the reverse direction, when a 6RD BR forwards a packet to a CE router that it hasn't ping'd before (or hasn't ping'd recently), have it ping the CE with a 1520 byte ping. If it gets a reply, set the MTU to the CE to infinity. If it doesn't get a reply, set the MTU to 1480 (or maybe 1472). Again, no fragmentation and reassembly. The only state in the BR then is an MTU value for each CE that it talks to - in the same way ordinary IPv4 nodes maintain a path MTU cache for the destinations they talk to. Since we assume that 6RD packets between the BR and the CE go over infrastructure that the ISP controls, wouldn't it be easier to just try to send bigger (IPv4) packets from the BR to the CE with the DF bit set, and look for PTB messages? On the public internet relying on PTBs might be a bad idea, but on controlled infrastructure you might be able to reply on those. If you can raise the MTU to 1520 you should be able to make PTBs work, right? ;-) It might save an extra roundtrip with a ping and use standard ICMP messages and associated state. Cheers, Sander
Re: T-Mobile goes IPv6-only on Android 4.4+ devices
Hey Lorenzo, Op 5 nov. 2013, om 08:45 heeft Lorenzo Colitti lore...@google.com het volgende geschreven: On Tue, Nov 5, 2013 at 4:41 PM, Tore Anderson t...@fud.no wrote: Some cool news to start the day with: http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on-Android-44-Devices-126506 Yesss! Nice to see that they link to the commit that turned it on - authored by yours truly. :-) Thanks! :-) Met vriendelijke groet, Sander Steffann
Re: Over-utilisation of v6 neighbour slots
Hi Erik, Looking at our data, looking at an IPv6 FTTH deployment's dedicated resolvers, averaging over 7 days, I'm seeing: Safari + 10.6 = ~89% IPv6 native preference Safari + 10.7 = ~38% IPv6 native preference (somewhat lower sample set) Safari + 10.8 = ~39% IPv6 native preference Safari + 10.9 = ~47% IPv6 native preference This hasn't been rigorously reviewed, of course. Perhaps Mavericks is a bit better, but not much... :-( Sander
Re: ipv6 source address selection
Hi Mikael, I don't understand why the host would choose source address in 2001:db8:1:1000:/64 when pinging 2001:db8:1:1001:1/128 because of this, but use 2001:db8:1:8000::/64 when pinging the rest of the Internet Still Longest prefix matching :-) Don't think of prefixes as prefixes-in-your-routing-table but longest-matching-string-of-bits-from-the-beginning-the-addresses. When pinging 2001:db8:1:1001::1/128 then: - A source in 2001:db8:1:1000::/64 will have 63 bits the same as the destination - A source in 2001:db8:1:8000::/64 will have 48 bits the same as the destination So the address in 2001:db8:1:1000::/64 will have the longest matching prefix and will be used. When pinging 2001:4860:4860::/128 then: - A source in 2001:db8:1:1000::/64 will have 17 bits the same as the destination - A source in 2001:db8:1:8000::/64 will have 17 bits the same as the destination So for longest prefix matching they are equal. As this is the last source address selection rule in the RFC the OS will just decide which address to use, which commonly is the most recently configured address. Cheers, Sander
Re: Sunsetting Teredo Experiment [IETF slides]
Hi Nick, I think he meant: http://lists.test-ipv6.com/mailman/listinfo/v6providers This seems to be a closed access list for v6 providers, but only significant ones. If you're anything other than significant, apparently you don't qualify. Well, I am on that list, so the barrier is not *that* high ;-) Sander
Re: teredo.ipv6.microsoft.com off?
Hi, Anyone found out what happened with teredo.ipv6.microsoft.com ? http://translate.google.com/translate?hl=ensl=deu=http://www.heise.de/netze/meldung/IPv6-Tunnel-Microsofts-Teredo-Server-nicht-erreichbar-1915972.htmlprev=/search%3Fq%3Dteredo%2Bmicrosoft%2Bipv6%26safe%3Doff%26sa%3DX%26biw%3D1303%26bih%3D803%26tbs%3Dqdr:w Since yesterday we have quite an increase of NXDOMAIN in relevant dns requests. Has Microsoft made the big step? Almost :-) This is what is happening now: As an attempt to measure the impact of this sunsetting, we would like to switch off the service for a few days. Resultant feedback and telemetry will help us inform the future of the Teredo service and its default configuration on Windows. We intend to conduct this experiment from approximately July 9 0:0:00 UTC, to July 15 0:0:00 UTC. So it will come back, but it *is* the start of the sunsetting process. Cheers, Sander
Re: Linux 3.9 routing oddity
Hi, If we don't compile with CONFIG_IPV6_ROUTER_PREF (RFC4191 support) a neighbour is only valid if its nud_state is NUD_VALID. I did not find any references that we should probe the router on route insertion time via the other RFCs. So skip this route in that case. We didn't find an RFC that tells us to build a working implementation, so we decided not to... So I assume that the bug would still be there. Sigh... Thanks for chasing this Pierre, Sander
Re: Linux 3.9 routing oddity
Hi, What do you think / rfc says about this? What you describe sounds like a very serious bug to me. Sander
Re: Point-to-point /64
Hi, Op 3 jun. 2013, om 00:26 heeft Brian E Carpenter brian.e.carpen...@gmail.com het volgende geschreven: On 03/06/2013 10:06, Steinar H. Gunderson wrote: 2013/6/2 Brian E Carpenter brian.e.carpen...@gmail.com: I'm not sure about other switches, but for the Catalyst 3750/3750G, it means some quirks with IPv6 ACLs. The 3750/3750D can do ACLs on full /128's, but only if the lower 64 bits are EUI64. Huh? How can it possibly know that? (see draft-ietf-6man-ug) Presumably he means that the middle bits are ff:fe. And the UG bits are 10. But none of that proves that the identifier is EUI64. It only proves that it *might* be EUI64. I think I understand the following: the 'optimisation' that Cisco makes here is that *if* the middle bits are ff:fe and UG is 10, then they accept an ACL with that address, and they don't actually store the 'known' bits but use the space to store other information in the TCAM. It would have to reject any ACL that tries to match on the full 128 bits where those specific bits are not 10 and ff:fe. Darren: am I understanding this correctly? Cheers, Sander
Re: http://www.6assist.net/ - call for test
Hi, I think we all understand that any tunnel connectivity is worst than a native. But still there are a lot of places where it is unable to get a native IPv6 connectivity even for ISPs. Which locations are those, lets discuss that, find those ISPs and help them get native connectivity. One of them is Lebanon. All international connections must go through the incumbent telco, and they don't/won't do IPv6. Annoying, insane, but a fact of life for the ISPs in such countries. So all the ISPs that do IPv6 have to do it with tunnels to HE, OCCAID etc. We killed that experimental thing called the 6bone in 2006, that is 7+ years... If you want to help ISPs get connectivity, get them on this list, and I am sure there are a couple of ISPs here who are more than happy to get them connected. Indeed, in the beginning this will become a tunnel to those transits, but at one point that can be replaced. I wish this was true for all countries :-( Cheers, Sander
