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: CPE Residential IPv6 Security Poll
Hi, > Should we again push our vendors for PCP/UPnP support? Sounds like a chicken&egg problem that needs to be solved. Applications won't implement PCP/UPnP support for IPv6 because no router is offering the service, and routers won't implement it because no application is going to use it. I think we need to push the router side to support it, so that it becomes interesting for applications to try to use it (and give developers the ability to test it). 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: Estonian IPv6 deployment report
Hi, > As statistics go, there are 3+ active IPv6 subscribers (almost 15% of our > customer base, based on our public numbers), 81% of them have have at least > one IPv6 enabled device in the LAN, 70% have more than one. Most IPv6 traffic > is generated by Google+Youtube, Facebook and Akamai. Not bad for a country > with 1.3M people. Congratulations! > Next up: mobile network :) :-) 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 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: Some very nice broken IPv6 networks at Google and Akamai
Hi Lorenzo, Op 9 nov. 2014, om 22:10 heeft Lorenzo Colitti het volgende geschreven: > On Sat, Nov 8, 2014 at 11:48 PM, Jeroen Massar 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: Google IPv6 measurements in Europe appear heading down...
Hi Erik, > Not seeing this in the Akamai data. See for Germany and Belgium. Your graphs show the best results (even going over 30% occasionally for Belgium) so let's go with your data. :) Cheers, Sander /me likes picking the data that best represents what I *want* to see ;)
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 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: IPv6 Assignment for Server
Hi, > Sorry for my mistake, I should write Tunnel Broker instead of ISP. > Due to the ISPs doesn't deploy the IPv6 yet, so I have to access via TB. > And some TB doesn't provide a lot of IPv6 address. Every IPv6 tunnel broker I know gives you a /48, which is 65536 /64s. Can you please let me know which tunnel broker you are using? They are doing it wrong... 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 het volgende geschreven: > On Tue, Nov 5, 2013 at 4:41 PM, Tore Anderson 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: What is Brocade up to here?
Hi, >> It's been broken for months, too. Happy Eyeballs seems to work pretty well >> for the internet. > > Did they just fix it? I did send them a heads-up, so they might. 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: Automatic source routing
Hi, > My reading of his original email was that he was *sending* pings, not > receiving them. Perhaps I was mistaken. Sorry, you are correct. He wrote: > Unfortunately, when performing, for instance, a ping from one specific > interface or source address, the ping always use the most recent default > router. He is however sending from a specific source address, so it is still not related to source address selection ;-) Cheers! Sander
Re: Automatic source routing
Hi, > But I note that the OP is *currently* testing with a single hosts w/ two > interfaces, so host-based source address selection is what's in play here, > not (s,d) routing. It's not source address selection if the host is replying to an incoming (ICMP ping) packet. The source address is fixed, and the OP wants the host to route the outgoing packet through the correct interface. Cheers, Sander
Re: Automatic source routing
Hi Ole, > I'm doing the same as you are with a Cisco IOS router. which also has some > shortcomings that I'm working on ironing out. Woohoo! :-) 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=en&sl=de&u=http://www.heise.de/netze/meldung/IPv6-Tunnel-Microsofts-Teredo-Server-nicht-erreichbar-1915972.html&prev=/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 Hannes, >> "We didn't find an RFC that tells us to build a working implementation, so >> we decided not to..." > > Of coure I did notice the misbehaviour if we compile without > CONFIG_IPV6_ROUTER_PREF and am working on a solution. I hoped to send > out a second patch soon after the first one, but it became more subtle > (and meanwhile lack time until the end of the weekend :( ). Thanks, good to hear that! I got the impression that it wouldn't be fixed. > This is a more complex issue to fix as I did not want to break the > round-robin selection of routes with unkown nud states in the default > router list. Also I am looking to resolve some usability issues: on > executing ``ip route get'' we actually do trigger active nud validation > on the nexthops. This could be a PITA because we do actually change the > results by that (a second ``ip route get'' could yield different results). Yeah, 'get' commands with side effects can really confuse people. They would confuse me :) >>> So I assume that the bug would still be there. >> >> Sigh... > > I'll keep you notified as soon as I have a working solution. Thank you! Sorry for my remark earlier, I misjudged the situation. 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 het volgende geschreven: > On 03/06/2013 10:06, Steinar H. Gunderson wrote: >> 2013/6/2 Brian E Carpenter : 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: Point-to-point /64
Hi, > In the case of /127 or /128 you'd always hit the router's host stack. But that is already protected by CoPP, right? :-) Sander
Re: Point-to-point /64
Hi, > /127 is actually what IETF recommends in RFC6164 > (http://tools.ietf.org/html/rfc6164) > /126 is not officially supported in this RFC. > > I have used /127 on "real" P2P links as well as Ethernet links connecting 2 > routers. I can confirm this. I use /127s on point to point links and it works great. I have been using it on Juniper and Cisco. No problems at all. They seem to follow RFC6164. I reserve the whole /64 but configure a /127. When choosing which /127 out of the /64 to use I usually pick ::a and ::b which makes it nice and readable for the admins. Much nicer than :: and ::1 (which would also violate the SHOULD NOT of RFC6164 section 6a) anyway :-) Cheers, Sander
Re: Cisco IOS IPv6 TCP MSS adjustment (from orignial thread: option 212 for 6RD)
Hi Trevor, > I thought it would be worth giving an update on a couple matters arising from > this original thread. > > - The behaviour Mikael noticed, where MSS adjustment wasn't working for TCP > over IPv6, was a bug that was specific to the 7300 platform. The fix is now > committed and will ship in the next maintenance update of 15.2(4)M. > > - Partly as a result of the feedback received on the original thread, there > is a revised implementation of TCP MSS adjustment planned initially for > 15.3(3)M for ISR platforms, which will allow MSS for TCP over IPv4 and IPv6 > to be adjusted independently. This implementation will then appear on the > ASR1000 series in a subsequent release, currently intended to be 15.4(1)S. > [usual disclaimer about not taking these plans as commitments applies, if you > have a need for any of these capabilities in a particular timeframe, please > work with your account team to get formal agreements for delivery] Thanks for the info. Much appreciated! Sander
Re: http://www.6assist.net/ - call for test
Hi, >> 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. > > So a list with difficult countries and cities and the problematic > carriers, somewhere on a webpage ? And some bigwigs from the ISOC/IETF/ITU 8-) > or so that start to get in touch with the problematic carriers ? > > Or does that sound too easy ? I know in Lebanon it involves political games. I'm not sure that any pressure from the technical community would help there... I'm including Nabil in the CC. He knows :-) 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
Re: IPv6 Addressing Question
Hi Eric, > For your information, Michael (in cc) and I wrote an IETF draft presenting > the pros and cons of this approach: > > http://tools.ietf.org/html/draft-ietf-opsec-lla-only-03 > > Comments are welcome Good document! Sander
Re: IPv6 Addressing Question
Hi, > To be explicit, using a link local completely breaks traceroute, > since ICMP replies sourced from a link local address must be > discarded by the next hop, according to RFC 4291 section 2.5.6. IIRC the router will reply from the loopback address when the interface doesn't have a global address, right? Sander
Re: IPv6 Addressing Question
Hi Mike, > IPv6 routing protocols seem in some cases to exclusively use automatic link > local addresses. Even for manual configuration, link locals deal with the ND > exhaustion attack problem in the core quite nicely, while also simplifying > address management. > > Are there practical reasons for global addresses on router interfaces? Pinging interface endpoints for debugging and monitoring, being able to see which interface is used in a traceroute, stuff like that. Routing protocols can work perfectly fine without global addresses, but netadmins have a harder time with just link locals :-) But true: it is something that I have tested in the lab, and it does reduce the attack surface of the network a bit. Cheers, Sander
