Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Thu, Apr 02, 2020 at 10:44:04AM +0200, Philip Homburg wrote: > >So you need to somehow build a prefix distribution mechanism, so people > >can have an arbitrary number of PD prefixes in "wherever network they=20 > >happen to be". So we're back to multi-level PD, with all the challenges > >(firewall rules, ACLs, internal routing, ...). And even then, a /48 > >might no longer be sufficient for a company with, say, 500 internal > >network segments and 40.000 employees - where it would be extremely=20 > >spacious otherwise. > > Independent of the prefix distribution mechanism, it may be worth revisiting > having a single /48 for an organisation of 4 employees. Sure, but if we start handing out /40s like there's enough of them, eventually there won't be. > There needs to be way to shield network complexity within a host from the > rest of the network. If we don't then limits on what routers can track (ND) > can become a limit in what we can do on a host. Even now people are already > worried about the number of 'privacy addresses'. > > So having an address policy that would support a /64 per host makes sense to > me. This is, interestingly enough, too big and too small at the same time. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Thu, Apr 02, 2020 at 05:24:34AM -0300, Fernando Gont wrote: > > As far as I understand, the official IETF recommendation for "how to > > run a home with multiple subnets" is "homenet / HNCP" now, which distributes > > individual /64s via HNCP, not whole prefixes via DHCPv6-PD. > I haven't been following homenet, to be honest. Is it widely implemented? Not at all. IETF killed it nicely, by entering a quabbeling contest at the crucial "it should be hit vendor implementations *now*" phase - so after the standards were finally done, all plastic box vendors had IPv6 implementations in their CPEs and nobody cared about homenet anymore. (Also, one of the nicest aspects of homenet is "dual ISP multihoming", which surprisingly ISPs seem to have no interesting in paying their CPE vendors to implement... also, still not as nice as one might think due to source address selection / source address *failover*) Picking on just a few bits of your reply (because I am not disagreeing with most) [..] > And the desire to delegate prefixes is also a bit at odds with the > strict definition of /64 subnets which end up using a huge address space > with a very low host density. Yes. If we do away with /64s, and permit hosts to request a, like, /96, via DHCP-PD, setting this all up would be much much easier - routers could have a /64 on the LAN, and a second /64 for "as many /96s as you could possible sustain" - or even "carved out of the /64" (if DHCPv6-IA_NA is used and the router knows what is free). Of course this would break *inside* the machine now, when you setup a "virtual network segment" with said /96, and your android VM refuses to do DHCPv6-IA_NA on it (and SLAAC doesn't work due to "not /64"). > > Corporate ISP-to-customer delegates a /48, so theoretically, there are > > "enough /56s in there to do lots of PD delegation to next-level routers" - > > but in practice, a /48 is supposed to be sufficient for a good-sized > > office building with *lots* of internal structure, and as soon as you > > have lots of internal network segments, you have no liberty to just give > > out random /56s here and there anymore. > > But, in that case, I'm not sure you'd want *dynamic* leases. Well, as for classic DHCPv6, "it depends". Most folks are totally happy with a dynamic endpoint, because they do not need to sustain sessions across a "change network" event. Some will want static leases, that follow them around in the building. But what when they roam to LTE in between? [..] > Just curious: what would be the use case of /64 per host (besides trying > to limit number of entries in the NC, etc.)? I let the proponents of DHCPv6-PD-to-the-host answer that - so far I haven't heard "smaller than /64" proposed anywhere. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Thu, Apr 02, 2020 at 12:09:34AM -0300, Fernando Gont wrote: > On 1/4/20 14:16, Gert Doering wrote: > [...] > > Even IETF discontinued recommending DHCPv6-PD for "inside a home network", > > because it doesn't work. > > Would you mind elaborating on this one? Which of the two parts? :-) As far as I understand, the official IETF recommendation for "how to run a home with multiple subnets" is "homenet / HNCP" now, which distributes individual /64s via HNCP, not whole prefixes via DHCPv6-PD. The reason why I state "DHCPv6 doesn't work" is "in practice". There is a practical lack of interest from vendors to make it work properly (as in, you can properly tie the delegated prefix(es) to ACLs, for example). On the "why is this a bad idea to start with" side, the chunkiness of subnet distribution makes it really unsuitable for anything but the most simple 1-level hierarchy. So, ISP-to-customer, delegates a /56. Next-level router asks for a prefix, and gets... what? Third-level router asks for a prefix, and gets what? Corporate ISP-to-customer delegates a /48, so theoretically, there are "enough /56s in there to do lots of PD delegation to next-level routers" - but in practice, a /48 is supposed to be sufficient for a good-sized office building with *lots* of internal structure, and as soon as you have lots of internal network segments, you have no liberty to just give out random /56s here and there anymore. Now, abandon the idea of "multi-level" DHCPv6-PD, and just assume "all you'll ever see is mobile clients asking for a single /64" (which, as I heard, is thinking too small, because you can have stacks of stacks, but stick to the /64 for the moment). Normally, you'd assign a /64 per network segment - office LAN floor 1, 2, 3, guest LAN, etc. - and have (effectively) an infinite number of addresses for more machines than you can ever connect. If you need to set aside "as many /64s as there could ever machines connect", you'll end up reserving /56s (256 hosts) or even more *per LAN*. Which will totally ruin your address planing, and all of a sudden a /48 will be *tight* for a normal company network. So you need to somehow build a prefix distribution mechanism, so people can have an arbitrary number of PD prefixes in "wherever network they happen to be". So we're back to multi-level PD, with all the challenges (firewall rules, ACLs, internal routing, ...). And even then, a /48 might no longer be sufficient for a company with, say, 500 internal network segments and 40.000 employees - where it would be extremely spacious otherwise. Could this be made to work? Possibly. Is anyone interested to *pay* for this work? Doubtful. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Wed, Apr 01, 2020 at 08:05:04PM +0200, Ola Thoresen wrote: > I also fail to see why the cost of implementing PD in a network would be > significantly higher than doing all the ND snoping and logging you would > need to track individual addresses - _especially_ in an enterprise network. Try build it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Wed, Apr 01, 2020 at 05:53:02PM +0200, Bjørn Mork wrote: > Lorenzo Colitti writes: > > > I'm not sure that the folks asking for IA_NA would be happy with IA_PD > > though. > > Why don't you just try and see? You have nothing to lose AFAICT. I've said it on IETF discussions and will happily say it again - this is a particular corner-case that might benefit developers running stacks of VMs in VMs on their laptops, but I fail to see a real world argument why this would be beneficial. OTOH the cost to implement this on the network-side is significant. Think "enterprise networks". You have LANs, and members of those networks. Not "distribution machinery for arbitrary prefixes to be doled out in places where you have no idea how many subnets of which size you might need". DHCPv6-PD has it's place in "connecting a client *network* to an internet provider (wired/wireless/LTE/whatever)" but I totally fail to see a positive benefit/cost analysis for anything else. Even IETF discontinued recommending DHCPv6-PD for "inside a home network", because it doesn't work. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Wed, Apr 01, 2020 at 10:56:55AM +0200, Bjørn Mork wrote: > The rest of us we can live just fine with SLAAC+DHCPv6. Just remember > that it is so much better than SLAAC+DHCPv6+whatever. Maybe it's time for a unified SLAAC+DHCPv6 standard! Much better than two competing standards! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: GDPR issues of mailing lists ? - Was: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Wed, Apr 01, 2020 at 10:56:09AM +0200, JORDI PALET MARTINEZ wrote: > The RFC is good, but GDPR is ???agnostic??? of RFCs ??? The DPA can say, even > if you are RFC-folks, the list is open for any other folks to subscribe, and > they don???t need to know that the list unsubscribe info is in the header, > they may not even know how to see the header ??? This domain is called "cluenet.de", it implies "can quote, and understands e-mail". No? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi,
On Wed, Apr 01, 2020 at 10:11:30AM +0900, Lorenzo Colitti wrote:
> On Wed, Apr 1, 2020 at 4:03 AM Gert Doering wrote:
>
> > (What they *want* is "IPAM shows what IPv6 address is in use on which
> > device in the network", which DHCPv6 would do nicely, including
> > static assignments via DHCP reservations - while everything else
> > relies on "IPv6/MAC ND logging on the router" or other disintegrated
> > fumbling...)
>
> Gert, have you asked why the solutions listed in Enno's blog post
> <https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>
> earlier in this thread don't work for them? Specifically, the router-based
> IP snooping and NDP monitoring features in switch platforms? Is it just
> that support for these features is patchy, and existing IPAMs do not
> support them?
Mostly this, plus control / reservations ("this machine is supposed to
get *that* address").
> Or is there some deeper problem? What can we do to make this
> better? Yes, using IA_NA would address this particular need, but it has
> disadvantages compared to SLAAC as well.
You could just stop being the ugly kid that does not want to play with
the others.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Tue, Mar 31, 2020 at 03:10:50PM -0300, Fernando Gont wrote: > > So, managed networks tend to like DHCPv6 (DNS!), and wonder how they > > should cope with Android. > Probably they don't. I'm working with one enterprise right now, and one of the options on the table is "have a separate wifi segment for android with SLAAC, and use the NAC software in place to bump android devices to that subnet". Which is a major PITA... (What they *want* is "IPAM shows what IPv6 address is in use on which device in the network", which DHCPv6 would do nicely, including static assignments via DHCP reservations - while everything else relies on "IPv6/MAC ND logging on the router" or other disintegrated fumbling...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
Hi, On Tue, Mar 31, 2020 at 12:17:44PM +0200, Mark Tinka wrote: > At my house, I don't even bother with DHCPv6 for DNS. I just use the > IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about > done with the purist madness around this. "In da house", mDNS usually does the trick nicely for "I want to ssh to my wife's laptop to fix her time machine backup". As soon as you have a larger routed network, mDNS falls short, and (unless you have a windows domain) there are no existing mechanisms to put a SLAAC v6 address into DNS... Yes, thanks, IETF. Well done. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
Hi, On Sat, Oct 26, 2019 at 04:06:17PM +0200, Bjørn Mork wrote: > Fernando Gont writes: > > > They can't do stable addresses, and they are facing this problem. > > This is a constructed problem. The solution is to remove the > construction. > > I realize that the "can't do stable addresses" might be enforced by > non-technical entities, but this would most likely not happen if it was > a violation of a standards track RFC. > > I'm sure you can fix that :-) It's a fallacy that people are interested in RFCs that conflict with real world constraints. Like, "must inspect arbitrarily deep EH chains at wire speed". Or "must guarantee a static IPv6 prefix assignment for the duration of a contract in an extremely low-margin market". As I said before, this insistence on "IPv6 prefixes must never change!! So if they change, we do not care about the consequences, but complain about the change itself!!" is foolish to start with. People want to change ISPs, want to multihome, if they have two ISPs, one or the other might fail at times - so, getting our standards and implementations in order to actually *deal with reality* (= prefixes change) would result in a much nicer overall experience. But then, since this is IETF, maybe reality is just all wrong, and just not conforming to standards tracks RFC in the first place... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
Hi, On Fri, Oct 25, 2019 at 09:07:42PM -0300, Fernando Gont wrote: > Not sure how many more 100's of messages are needed before we get to do > something about it... If something the IETF makes is not working properly out in the field, it's never the IETF's fault. So you must be doing it all wrong. The trick here seems to be to argue long enough to make people give up and deploy IPv4 instead (lots of money to be made fixing other people's NAT444 setups that nobody understand anymore, but "IPv4 is much easier!" - just as a side note). Seriously: I think your draft is a necessary document - whether to do it in one or three documents, not sure, but maybe reaching individual consensus is easier. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
Hi, On Fri, Oct 25, 2019 at 11:33:29PM +, Michael Sturtz wrote: > The problem with non-routable private ULA addressing is most vendor equipment > doesn't support having a SLAAC or DHCP6 dynamic routable address and a static > ULA address. You have claimed that before, but I find this hard to believe. In my experience with various host implementations, having multiple addresses (multiple SLAAC prefixes or static + SLAAC) works just as one would expect. Maybe not OpenSolaris, but anything sane out there. So, which systems exist that cannot handle static + SLAAC? > For simple home networks I suppose we could have a RFC that proposes the FE80 > address space be used as the "static" address space for SOHO server > addressing and locating such as local DNS or single server environments or > the end user equipment could just assume that it would be "static" given the > common use of EUI-64 for the /64 portion (Windows excepted). fe80 is not ULA, and using fe80 for mDNS is long-established practice already :-) > Right now, with the way it actually works in the field it is very disruptive > every time the /64 is renumbered by the ISP In my experience this happens > way too often. An end user should not have to go around and reboot devices, > hunt around for the new printer IP and so on just because the ISP caused a > renumber of their automatically assigned /64. This is why "enter an IPv6 address for a device into anything else" should be strongly frowned upon. Nobody should need to know the IPv6 address for a printer in the first place. mDNS exists, bonjour exists, these things actually work well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: ipv6-ops Digest, Vol 159, Issue 1
Hi, On Thu, Oct 24, 2019 at 09:02:44AM -0300, Fernando Gont wrote: > As noted in the draft, the renumbered home network is one of many > possible scenarios where the renumbering event occurs. While we can > certainly recommend stable prefixes, I do think that the network should > be robust in the presence of such events. Right. This is missing in the whole "only bad ISPs will ever give their customers prefixes that are not stable" discussing - customers *change* ISPs, and this should be as painless as it is in the IPv4+NAT world. Thus, anything relying or implicitly assuming "IPv6 addresses are stable" (in an unmanaged SoHo network) must be very much discouraged. Maybe even dual-/48 multihoming can be made to work one day (and no, it is not even working well in theory today, but even less so in practice with the CPE implementations you can buy today). Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: ipv6-ops Digest, Vol 159, Issue 1
Hi, On Wed, Oct 23, 2019 at 03:00:21PM +, Michael Sturtz wrote: > As far as I know ULA was deprecated in 9/2004 Those were site-locals, not ULAs. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPv6 ingress filtering
Hi, On Sat, May 18, 2019 at 08:06:00AM +1200, Brian E Carpenter wrote: > And surely the question is "What would produce the most help desk calls?". > Filtering something that is presumably working for its remaining users > might not be a good idea from that point of view. Oh, since those are not *my* users, it's not my helpdesk. Which is, annoyingly enough, the grand problem with IPv6 anyway - "someone messing up their v6" will inevitably cause helpdesk calls *elsewhere*. Like this beauty discovered by someone today: $ host -t bayerwaldhof.de bayerwaldhof.de has IPv6 address :: ... the helpdesk calls will happen on the dual-stacked ISP side, not on the messed-up content side... Those that stick to v4-only are usually spared any helpdesk calls. *sigh* Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: IPv6 ingress filtering
Hi, On Fri, May 17, 2019 at 12:55:33PM -0500, David Farmer wrote: > A few questions; > > Are you generating ICMPv6 toward non-2002::/16 sources for traffic destined > to 2002::/16? > Are you generating ICMPv6 toward 2002::/16 source for traffic destined to > non-2002::/16? > For the later, where are you getting the route for 2002::/16 from? Indeed, as you said, filtering correctly (= ICMP unreachable, so clients can fail over quickly [if HE is not in use]) is hard. We still run our own relay, so do not filter today. Mostly because I know it works and (since it's our relay) I can rely on it to not break things for people - and haven't had time to change that to "filter". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: IPv6 ingress filtering
Hi, On Tue, May 14, 2019 at 11:08:21PM +0200, JORDI PALET MARTINEZ wrote: > 6in4 needs manual configuration (or a TB). > > 6to4 is 6in4 with automatic configuration. You might not have noticed, but I have done a bit of IPv6 over time, so yes, I understand. And thus: 6to4 needs to die. In flames. > Living in a perfect world is ideal (I will love to have just one ISP with > IPv6 in every country). But is not real. This is not solved by poor-quality tunnels. All these tunnels do is "make IPv6 look bad", so people get to learn "IPv6 has more latency, more packet loss, and I can not even call customer support if it does not work, so better avoid it". This was already accepted truth 10+ years ago. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: IPv6 ingress filtering
Hi, On Tue, May 14, 2019 at 05:50:52PM +0200, JORDI PALET MARTINEZ wrote: > I don???t agree. There are many users with tunnel brokers that use 6in4. If > you filter 6to4 as a protocol, you???re also filtering all those users??? > traffic. 6in4 is not 6to4. 6to4 with 2002:: addresses and anycast relays must die. In flames. 10 years ago. > Not everybody is lucky enough to have native IPv6 support from its ISP. Those should either change ISP or just use IPv4. The days of cross-ISP tunneling are *over*. Either do it right, or do not do it at all. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Realistic number of hosts for a /64 subnet?
Hi, On Fri, May 10, 2019 at 10:14:36PM +0100, Nick Hilliard wrote: > I'm sure 1000 hosts on a network will usually work fine, until someone > does something dumb and takes down the entire segment, at which point > you'll have 1000 people shouting at you. Just make sure their phones are in the same network segment. No shouting. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Realistic number of hosts for a /64 subnet?
Hi, On Fri, May 10, 2019 at 01:07:44PM +0200, H.Zuleger wrote: > > (The whole reason why /64 semeed a good idea back then was CGA and > > "we can make it work with EUI-64 on IEEE-1394 devices!", of which CGA > > never truly happened, EUI-64 based on MAC addresses is dying off, and > > IEEE-1394 is long gone... I always thought that /64 was a bit silly) > Maybe, but this large address space, give you the room for all these ideas > (and a lot more like 8+8 etc.). > I think the great benefit and the main driver was (and is) the full automated > address configuration. I've heard lots of "great ideas" in the last 20 years... What is left: - large networks are hard - can we please do p2p instead, routed, wherever possible - autoconfig based on hardware identifiers sucks, can we please do something hash-based (= autoconf in a /96 would quite likely work perfectly fine) - we do not have enough bits *in front* of the /64 mark to do nice things Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Realistic number of hosts for a /64 subnet?
Hi, On Fri, May 10, 2019 at 08:26:46AM +0200, Mark Tinka wrote: > Whether a single LAN can scale to the number of devices a /64 can > maximally support... I don't think so, but I also don't know of anyone > who has tried. Math says there is no way to do that. Like, store 2^63 ND entries in finite memory... (The whole reason why /64 semeed a good idea back then was CGA and "we can make it work with EUI-64 on IEEE-1394 devices!", of which CGA never truly happened, EUI-64 based on MAC addresses is dying off, and IEEE-1394 is long gone... I always thought that /64 was a bit silly) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: UPnP/IPv6 support in home routers?
Hi, On Mon, Dec 18, 2017 at 10:12:42PM +, Tom Hill wrote: > On 11/12/17 15:03, Gert Doering wrote: > > But that's the whole idea of UPnP or IGD. Whether you open one port or > > all of them, on request of a possibly-compromised host, is of no relevance. > > I would disagree, on the purely theoretical basis of how it would be > presented to the user: > > Situation 1: 'good' host has opened recognisable TCP port > Situation 2: 'bad' host has opened unrecognisable TCP port > Situation 3: 'good' host has opened all TCP/UDP ports to its addresses > Situation 4: 'bad' host has opened all TCP/UDP ports to its addresses > > It is relatively trivial to identify or query malicious behaviour when > the possible situations in front of you are #1 and #2. When they are #3 > and #4 it isn't as simple because you simply have less information about > what's going on. This is assuming that the host #2 won't just open a standard TCP port to do its thing. Why shouldn't it? It's bad, so lying about it's purpose is straightforward... (and then, everything is HTTP anyway today). > If the standards were to theoretically permit the legitimate > 'DFZ-enabling' in any such protocol, software creators will eventually > use it for legitimate (albeit probably stupid) reasons, and it'll become > common enough that even a relatively clued-up user would not be able to > recognise if a host is placing itself in a DFZ for legitimate or > illegitimate reasons. See? > I personally disable uPnP everywhere, but as we're stuck with it in the > wild, we should always be considering how changes could make the > situation even worse than the current situation, as opposed to saying > "this is all rubbish anyway". :) "bad hosts can open back doors at their whim" is as bad as it can get, there is no "more of that". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: UPnP/IPv6 support in home routers?
Hi, On Tue, Dec 12, 2017 at 03:45:17PM +0100, Jan Pedro Tumusok wrote: > What about alle the people that are not able to setup their own filters and > other security mechanisms? Most people got this computer stuff for usage > and not to thinker with or spend ours figuring out the best type of > configuration. > How do we give them a bit more security than wide open devices? Besides the IoT crap, most devices nowadays have not been "wide open" in a long time. So either you assume the devices are vulnerable to network attacks - and in that case, they should not share a network with IoT and other crap. Or you assume the devices are indeed hardened properly (otherwise, I would not connect a laptop to a public wifi either...) - in which case a firewall mostly gets in the way of getting work done. Now, the IoT crap should just be moved to the garbage bin, and *that* would help. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: UPnP/IPv6 support in home routers?
Hi, On Mon, Dec 11, 2017 at 11:54:15AM +, Tom Hill wrote: > "Dear Gateway, I am definitely not a compromised host, please open all > ports toward me." But that's the whole idea of UPnP or IGD. Whether you open one port or all of them, on request of a possibly-compromised host, is of no relevance. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Link-local and ACLs
Hi, On Wed, Jul 26, 2017 at 08:48:43AM +1200, Brian E Carpenter wrote: > >> And why would ACLs be relevant for on-link traffic? > > > > Interface ACLs are relevant for all packets leaving or entering an > > interface, generally... > > Yes, but why are they relevant except for routers? I didn't see > anything in the original message that limited its scope to routers. > Most nodes aren't routers. I don't expect to see ACLs on normal > hosts. All my hosts that are in some way Internet exposed have ACLs of some sort - call it "Windows firewall" or "FreeBSD pf(4)". Usually these implicitly understand what is needed to make ND work, but I've heard more than once about cases where Linux people blocked "everything on input except tcp/80" with ip6tables, killing ND in the process -> bam, machine fell of the net, IPv6 gone. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Link-local and ACLs
Hi, On Mon, Jul 24, 2017 at 08:56:41PM +0100, Nick Hilliard wrote: > Gert Doering wrote: > > "on the same link"? > > return traffic. Not much good in having unidirectional data flow. Even return traffic "on the same link" shouldn't be subject to "packets with fe80 sources MUST NOT be routed"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Link-local and ACLs
Hi, On Mon, Jul 24, 2017 at 06:50:57PM +0100, Nick Hilliard wrote: > David Farmer wrote: > > Also, in theory a link-local address could talk to a GUA or ULA address > > on the same link. However, in practices does this really happen? If it > > does happen in practice what are circumstances? > > will that packet not be dropped because a LL ipv6 packet won't be > routed? (MUST NOT in whatever rfc). "on the same link"? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: SixXS shutting down 2017-06-06
Hi, On Thu, Mar 23, 2017 at 03:38:58PM +, Tim Chown wrote: > I think SiXXS and tunnel broker.net<http://broker.net> have both been > excellent services over the (many) years, and certainly good value for money > for the users :) Many thanks for providing it! > > I understand the rationale. I???ve generally been a > tunnelbroker.net<http://tunnelbroker.net> guy, but now rarely use it as I???m > finding IPv6 more widely available, and have had it natively at home in the > UK for a few years now. I think your observation of "SixXS is no longer able > to contribute to the solution, and is hampering its own goals of facilitating > the migration of consumers to native IPv6??? rings true. > > All the best Pim (and Jeroen!) What Tim said. Thanks, sixxs folks. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: question regarding over the counter devices
Hi, On Mon, Mar 06, 2017 at 02:07:31PM +0100, Mikael Abrahamsson wrote: > On Mon, 6 Mar 2017, Gert Doering wrote: > > > 3G mandated IPv6, no carrier actually deployed it *before* they had a > > huge legacy of IPv4-only handsets in the field... could have been done > > from day one. > > On the other hand no handset manufacturer apart from Nokia ever made any > 3G handsets that supported IPv6. I'm not sure why "point to the part in the 3G specs that says v6 is mandatory" would have been so hard... > Also, since you needed two concurrent bearers and the 3GPP network vendors > charged per bearer, it also make IPv6 deployment extremely expensive. > > Yes, plenty of blame to go around. It's not only a carrier problem. If you wanted reasons to not deploy IPv6, there have always been excuses galore. But then do not complain 10 years later that you have such a large basis of IPv4-only clients and all of a sudden it's sooo much work... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: question regarding over the counter devices
Hi, On Mon, Mar 06, 2017 at 01:26:57PM +0100, Mikael Abrahamsson wrote: > > The mobile carriers nicely demonstrated how *not* to do it - by ignoring > > the mandate for IPv6 in 3G, and rolling out huge masses of v4-only > > handsets, they suddenly had a huge installed basis of, well, v4-only > > legacy devices to deal with... > > Most carriers do not control handsets anymore. Those days are long gone. The day to roll out mobile Internet properly are indeed long gone, now they get to deal with the legacy. 3G mandated IPv6, no carrier actually deployed it *before* they had a huge legacy of IPv4-only handsets in the field... could have been done from day one. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: question regarding over the counter devices
Hi, On Mon, Mar 06, 2017 at 12:11:53PM +0100, Florian Lohoff wrote: > You cant enable some feature for "Aunt Tilly" without her at least > beeing able to take action. Aunt Tilly has no idea what IPv4, IPv6 or "Internet" is. As long as her web browser will show cat videos, she's happy. If you wait for Aunt Tilly to make a decision regarding "how should her Internet access be provisioned?", nothing will ever happen. [..] > I have been with a large Carrier in .de and we had the transitional > problems and we didnt fix/enable it at all until i left in 2011. > Although we enabled the core of my former employee to IPv6/6PE > and the BRAS were all IPv6 capable we didnt enable it. So around 1.7 > million DSL Subscribers without IPv6. I and a few collegues started a > new carrier and we shipped 100% Dualstack but we knew the oldest Software > of our CPEs and we new the features. So it was much easier. If a CPE has no v6 support, having it available on the DSLAM (in passive mode = do not start IPv6CP until the client initiates it) will not do harm. > You need to start somewhere and the non-tier1 carriers with enough > IP Adresses dont even start enabling IPv6 because they have no answer > to the transition scenario. Delaying the inevitable will just raise your costs more and more. The mobile carriers nicely demonstrated how *not* to do it - by ignoring the mandate for IPv6 in 3G, and rolling out huge masses of v4-only handsets, they suddenly had a huge installed basis of, well, v4-only legacy devices to deal with... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: question regarding over the counter devices
Hi, On Mon, Mar 06, 2017 at 11:37:30AM +0100, Florian Lohoff wrote: > Nevertheless - As an ISP i would never enable IPv6 for Customers > without beeing shure that they are aware. > > - Deploy IPv6 Dualstack from some point in time and making it clear > in your paperwork. > - Make it an option for legacy users to opt in. > - After some time - send emails telling the users > - Enable a captive portal for users to let them enable ipv6 This is "last century's process": wait for customers to ask for IPv6, which they will not do, and then you can prove to your management that "there is no demand", so you can continue to not roll out v6. If we ever want to reach the point when we can stop bothering with IPv4 on the server side, IPv6 needs to be on by default on *ALL* access. Not opt-in. Not "it will take another 20 years". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: question regarding over the counter devices
Hi, On Wed, Mar 01, 2017 at 08:39:43AM +0100, sth...@nethelp.no wrote: > FreeBSD, at least until 11.0-STABLE: No IPv6 firewall turned on by > default. Which is exactly what I want. Well, "have no services on by default" is good enough for the issue at hand "can my devices protect themselves, or would a firewall be beneficial in any way?"... :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Linux and ULA support and default route
Hi, On Fri, Oct 14, 2016 at 12:00:04PM +0200, Holger Zuleger wrote: > Of course the default route should *not* be withdrawn. > The RA default router announcement says just, "Hey hosts, I'm the way > out of your local subnet", and not "Hey host, I have a upstream > connection to the rest of the internet". If the router has no default route, it should not announce one - this is why PIO exists for more specific info. Imagine a setup with *two* routers. One of them has broken Internet, the other is working. How can the hosts decide if both keep announcing themselves as "I can reach anything"? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 smime.p7s Description: S/MIME cryptographic signature
Re: BBWF Beer meetup
Hi, On Sat, Oct 08, 2016 at 09:17:53PM +1100, Eric Wisner wrote: > KILL ME I take the beer was good, and lots of it? :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: v6 naming and shaming - *.europa.eu
Hi, On Wed, May 18, 2016 at 03:33:45PM +0100, Phil Mayers wrote: > This is a fair point. Perhaps I'm overreacting - we don't get too many > of these. Still annoying. Organizations that make (or "use to make") a big hubbub about IPv6 should be able to then actually *use* it. Like, use it on their internal networks, provide it in their guest WiFi, have all external facing services (web, mail, DNS, ...) dual-stacked, etc. I could start a rant about "IPv6 task forces" around the world now... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: v6 naming and shaming - *.europa.eu
Hi, On Wed, May 18, 2016 at 02:06:57PM +, Tim Chown wrote: > > I'm specifically not asking about encouraging people who haven't deployed; > > rather people who have and who have broken or abandoned their efforts. > > Well, a not uncommon approach to discourage bad behaviour is to > create an appropriate blacklist where offenders are added when such > behaviour is observed, so that people can choose to use the blacklist, That would be akin to the mentioned RPZ zone - which helps your local users (good!) but effectively hides the real problem (bad). Maybe just add such offendors to an RPZ zone that suppresses their IPv4 record, so it's "fix your IPv6 or die"? Not really serious... > But perhaps some public ???wall of shame??? might > be a step towards that. The first question is how/whether you would > detect / report such offenders in the first place; I would also > hope cases are very rare. And whether enough people care to actually get things fixed, then. frustrated, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: MTU/MSS testing IPv6
Hi, On Fri, Apr 29, 2016 at 09:38:50AM +0200, Shane Kerr wrote: > OTOH, blocking all IPv6 fragments seems a bit too aggressive for > firewalls. My guess is more along the lines of "this is on FreeBSD, using the pf(4) packet filter, which is still not able to do anything reasonable with IPv6 fragments" (you can permit-all or deny-all, but no reassembly and no more educated filtering). OpenBSD fixed that, but FreeBSD changed their networking stack enough that they cannot just import new versions of pf(4) from OpenBSD anymore (and it seems nobody really cares *sigh*). We're using NAT64 techniques to access customer private networks (using ULAs mapped to their private addresses on the outside) and these atomic fragments + FreeBSD pf(4) has bitten us as well... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: Slow WiFi with Android Marshmallow & IPv6?
Hi, On Wed, Apr 27, 2016 at 09:37:05AM +0200, Bjørn Mork wrote: > But we could discuss whether it currently makes sense to support DNS > queries over IPv6 at all. Doubling the number of resolver addresses is > not necessarily good. I believe most consider 2 addresses optimal in > IPv4 only deployments. Resolver libraries are notorioulsy bad at > fail-over, so there isn't really any point in more that that. And you'd > better make both addresses always be up and responding. Adding 2 more > addresses is only adding trouble. So why do we do that? To be nice to > all the IPv6 only devices out there? Right... So we can eventually turn off IPv4... "IPv6 is hard, let's go fishing instead" isn't the proper way forward. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Slow WiFi with Android Marshmallow & IPv6?
Hi, On Mon, Apr 25, 2016 at 05:50:50PM +0200, Steinar H. Gunderson wrote: > On Mon, Apr 25, 2016 at 05:48:52PM +0200, Bjørn Mork wrote: > > But why would this problem affect only Android? And why only a very > > specific Android version? That doesn't compute... > > Because people have Windows, OS X, iOS and Android devices, and only one of > those support RFC 6106. OS X and iOS support 6106 just fine, but maybe they are not so daft about recursor failover in case one turns out to be broken? (I'm not sure about Windows and 6106 right now, so not commenting on that) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPv6 Dynamic Prefix Problems
Hi, On Wed, Dec 16, 2015 at 01:16:41PM +0100, Jeroen Massar wrote: > > It's not something that would work for an enterprise network, but as soon > > as the "we need persistant addresses!" phase of denial is over, it's a great > > solution for SoHo networks. And yes, been there, tested OpenWRT HNCP > > implementation, liked the result. > > Homenet (for homes as it and you say) is a good start indeed though > primarily addresses outbound traffic. > > DynDNS can 'solve' inbound connectivity but the world would be so much > better off if it actually used SRV so one could publish preferences that > way. Indeed, more work needs to be done. I'm not claiming this is perfect - many little details need to be improved, like SRV for externally-visible components (= software that can publish them, dyndns services that can handle them, client software that will query for them). gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpXPKkzPNj8T.pgp Description: PGP signature
Re: IPv6 Dynamic Prefix Problems
Hi,
On Wed, Dec 16, 2015 at 01:01:19PM +0100, Jeroen Massar wrote:
> Routing scaling research will be fun, but in the end, that is the only
> real way to handle that situation.
Dual-PA multihoming works, and has a number of extra benefits that you
cannot get with PI - like, applications can decide which ISP to use
("bittorrent on cable, ssh on LTE") by selecting the corresponding
source address.
It's not something that would work for an enterprise network, but as soon
as the "we need persistant addresses!" phase of denial is over, it's a great
solution for SoHo networks. And yes, been there, tested OpenWRT HNCP
implementation, liked the result.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPv6 Dynamic Prefix Problems
Hi, On Wed, Dec 16, 2015 at 10:33:29AM +0100, Johannes Weber wrote: > what are your experiences with dynamic IPv6 prefixes? Here in Germany, > several ISPs only offer dynamic /56 prefixes that change after a router > reboot. Of course, for "normal" end-users this is not a problem. But for > companies having several remote offices behind such ISP lines, this is a > problem. (And of course, for me as a network guy, too. ;)) I do feel your pain, but I wonder if this is not just assumptions that need to go away - and if this is the right way to *make* them go away (by breaking stuff that relies on "the IPv6 address of will never ever change!"). Yes, network people like to have SSH sessions that survive for weeks or longer, but really, we're just 0.01% of the users - and typical users have no idea what a "long-lived TCP session" might be... OTOH, what you really want is multihoming with two different IPv6 access ISPs, and that will have to work with "I get one prefix from each ISP and my devices have to handle having multiple addresses, some of them coming and going at unexpected times" - which inevitably leads to needing new strategies for service discovery (= "dynDNS") and session failover in case one of the addresses just stops working because the ISP line broke. [..] > 1) Many DNS changes for services behind the dyn prefix (not all devices > are able to update DNS records) This indeed is tricky. OTOH, AVM can do it for devices *behind* the router, so we "just" need to ensure router vendors understand what is needed... > 2) Security policies with DynDNS ranges (how to allow a dyn IPv6-range > in other firewall policies?) Is "relying on source IP address" a good security strategy? > 3) Routing inside IPv6 VPN tunnels (solved with OSPFv3, but maybe not > optimal?) The "multiple addresses" model lends itself to "the VPN will provide yet another /64 for the LAN, and by choosing the appropriate *source* address the client will decide whether it wants to go into the VPN or not" (homenet source-address dependent routing). > I am highly interested in others experience about dynamic prefixes. How > do you solve these problems, e.g., when a company has several remote > offices with dynamic prefixes? Add a second prefix from the internal company range and put that into the VPN (source address selection will nicely handle this today, unlike all the potential pitfalls with proper source address *failover* in the multihoming case). Food for thought, not an "answer today". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPv6 QUIC traffic
hi, On Thu, Jun 04, 2015 at 04:03:14PM +0100, Dominik Bay wrote: Why are you blocking QUIC traffic anyway? Because traditionally, UDP/80 was badness from stupid blackhats... (We don't, but I can very well understand why UDP on traditional tcp ports would get blocked, or strictly rate-limited...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Cost of IPv6 for IT operations team
Hi, On Mon, Apr 13, 2015 at 11:31:57PM +0200, Jens Link wrote: I told my first customer about Y2k in 1980. He called last week. If anyone of you speaks Cobol the customer is paying $large_amount per hour for fixing his problems. With IPv6 there is no fixed date but I will happen too. customer called, and is offering $large_amount for anyone capable and willing to fix their quad-nat-ipv4-only mission critical network Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why do we still need IPv4 when we are migrating to IPv6...
Hi, On Wed, Feb 18, 2015 at 04:04:32PM +, Phil Mayers wrote: Don't get me started on SCADA systems. [..] There is a woeful lack of ability in this bit of the industry. I'd love a big player to come in and blow the market sky high. The next truly big exploit for these piles of junk will ensure that the vendors will disappear... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why do we still need IPv4 when we are migrating to IPv6...
Hi, On Thu, Feb 12, 2015 at 02:37:09PM -0800, Erik Kline wrote: Sure this potential Data Retention Directive will not be IPv6-specific and somehow exempt IPv4? I read the original concern as if they force DR on us, and we run a CGN, it will not be possible / too expensive / ... to log the NAT mappings that the CGN did. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Why do we still need IPv4 when we are migrating to IPv6...
Hi, On Thu, Feb 12, 2015 at 10:41:05AM +0100, Ole Troan wrote: When will IPv6 provide me as an end-user with more value than what my current NATed IPv4 connection does? Today! [..] But that's better value by making IPv4 work less good. and I'll postulate that we can make A+P / shared IPv4 work good enough that end-users who are trained to live behind a NATs will not notice. For me, IPv6 has always been about IPv4 does not have enough addresses, and as a consequence of that, pain and avoidable cost ensues. Thus, I'm not sure we do ourselves a favour by making IPv4-cludges so good that the pain is hidden well enough - the fact that Kabel Deutschland is breaking SIP is causing quite a bit of pain at one of the bigger german SIP providers, who are rumoured to look into IPv6 deployment now... For me I would get added value when I could deploy IPv6 only services at home, e.g. mail, XMPP, web, SIP... VPN. And I could reach my own home whenever I'm travelling. I can see that, and of course I have that for IPv4 already :-) - but I claim that this is actually not something most (for wild handwaving values of most) users want, given that normal end users just don't run services at home, might not even have always-on components at all (readers of this list are not normal end users, your parents might be). One of the major benefits of IPv6 I see for SOHO users is the homenet architecture with multihoming, SADR and service/ISP selection *by the application* (use cable ISP for bittorrent, use DSL for web browsing). We're not there yet, though... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgps3e2AmF6HX.pgp Description: PGP signature
Re: Why do we still need IPv4 when we are migrating to IPv6...
Hi, On Thu, Feb 12, 2015 at 01:11:21PM +, Anfinsen, Ragnar wrote: However, we are there soon, but it does not change the fact that we still need to keep our IPv4 running, due to the slow movement of many content providers. Amen. Frustrating as it is. I wonder if it would make a difference if big eyeballs ISPs (among the 3 largest in a country) would start talking to content providers, telling them hey, you know, your content is quite popular with our users, but since it's v4-only, we need to seriously throttle it to avoid overloading our CGN. v6 goes unlimited, btw just dreaming... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: 6to4 in Internet aaaa records
Hi, On Thu, Oct 02, 2014 at 10:31:25PM -0400, Jeroen Massar wrote: http://www.azdes.gov)... 2002::cf6c:8846 That is an invalid 6to4 address as it would have a 6to4 gateway of 0.0.0.0. Uh, what? Who are you and what happens to the Jeroen I know who understands IPv6, and knows that 6to4 addresses do (unlike Teredo) not call a reference to the gateway in there... and that the biggest part of the actual *problem* with 6to4 is exactly the anycast nature of it's current deployment...? One would think with all the IPv6 consultants in the US, that .gov agencies would be able to get that part right... Though, better point them out that 6to4 is a bad idea in general anyway. I certainly agree with that sentiment, though. 6to4 should never ever (NEVER!) show up in public DNS for servers, as just stick to IPv4 is guaranteed to give better service. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: 6to4 in Internet aaaa records
Hi, On Sat, Oct 04, 2014 at 12:49:00PM +0200, Gert Doering wrote: On Thu, Oct 02, 2014 at 10:31:25PM -0400, Jeroen Massar wrote: http://www.azdes.gov)... 2002::cf6c:8846 That is an invalid 6to4 address as it would have a 6to4 gateway of 0.0.0.0. Uh, what? Who are you and what happens to the Jeroen I know who understands IPv6, [..] Aliens stole the body of Gert Doering, and now he can't find the button withdraw this e-mail in his Outlook mail client anymore... Sorry, of course Jeroen is right here, and I need to sleep more before typing. While anycast *is* the problem, of course the exit side of the tunnel needs an address, aka gateway... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Something with filters
Hi, On Thu, Aug 28, 2014 at 04:31:22PM +0200, Enno Rey wrote: to be honest, as another security person, I'm not really sure about the benefit of uRPF in the IPv6 world, in some scenarios. imagine a single infected smartphone on LTE, generating connections with potentially 2^64 different source addresses from its assigned /64. How would you counter that with uRPF? The point is not to counter devices from spoofing random addresses - but from spoofing random addresses *not trackable to them*. not to speak about a home device sitting behind a CPE (and mimicing connections from different /64s being part of the /56 the CPE got)... thoughts? Same thing. I do not care which address customer A uses out of their /56, but if I get an abuse complaint, I do care very much that customer A is not sending packets with a source belonging to customer B... (And the whole bunch of reflective DoS attacks we're seeing these days would be stopped cold if uRPF/BCP38 would be deployed at the true sources of the spoofed packets) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818
Hi, On Fri, Aug 22, 2014 at 10:51:26PM -0700, Michael Chang wrote: If a spammer gets a hold of a /64, then the spammer can send 18 billion billion (~2^64) different email addresses, each coming from a different IP address. Never-mind that a spammer can go to a half-dozen tunnel brokers and get /48s for free. And if the reputation system is worth a cup of salt, it will notice that it already has down-graded sufficient addresses inside the /64 (/56, /48, /32) to down-grade the rest of it. Just because it needs a bit more thinking than for IPv4 doesn't mean it cannot be done. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: SMTP over IPv6 : gmail classifying nearly all IPv6 mail as spam since 20140818
Hi, On Fri, Aug 22, 2014 at 07:32:41AM -0700, Lorenzo Colitti wrote: From what I've heard it's somewhat of a consensus position among large email operators on what to do for IPv6 SMTP inbound. Well... some think it's a good idea, and there is an IETF draft, which largely failed to get support. I think it's a very bad idea to have stronger requirements on IPv6 mail than on IPv4, as it is yet another obstacle to IPv6 deployment - but maybe that's just me, and I have a slighly different focus than most religious anti-spammers. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Large IPv6 Multicast Domains
Hi, On Thu, Jun 05, 2014 at 09:32:08PM -0400, James Small wrote: If there is no direct connection between the domains, either use some sort of VPN (which you'll likely have anyway) or possibly just a simple GRE or configured 6in4 tunnel. Coming from an IPv4 Multicast background, I'm having a hard time accepting that my only Inter-domain RP option is embedded RP. I understand the issues with MSDP and why it wasn't extended to support IPv6. However, it still feels like there should be some kind of inter-domain RP communication/synchronization option. Perhaps I have not fully grokked IPv6 Multicast yet? Point is, RP synchronization is only necessary if different PIM speakers have different ideas who the RP is. So your routers talk to your RP, their routers talk to their RP, and the RPs synchronize with MSDP. In IPv4, you could configure your routers to use their RP for a given multicast group, and not use MSDP - but nobody does that as it's manual work. With the embedded RP, all routers know which is the right (and only) RP for a given group, so there is nothing left to synchronize... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Residential subscribers: numbered or unnumbered?
Hi, On Tue, Mar 25, 2014 at 10:28:06PM -0400, Philip Matthews wrote: Are these PPPoE or IPoE deployments? PPPoE for the large-scale DSL deployments in DE. Cable for the large-scale cable deployments :-) (As far as I know, cable has a shared /64 on the WAN side). And more importantly, any insights as to WHY they went this route? Were the other options considered? No idea about the reasoning behind. *Our* small-scale deployment truly doesn't count, as everything is fully managed and fixed-config on the CPE (so neither SLAAC nor DHCPv6 involved), mostly due to when we set this up, DHCPv6 didn't exist in IOS and we never came around to rebuilding the plattform... For IPoE with RA/SLAAC, I am curious to know how the provider learns of an address on the CPE for pings or whatever? Or do they just not care? I have no idea how TR69 management works (will the CPE just call in?), but besides that, in those large-scale deployments I know about, the ISP couldn't care less - most CPEs are unmanaged. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpWqtbItmpkp.pgp Description: PGP signature
Re: Residential subscribers: numbered or unnumbered?
Hi, On Tue, Mar 25, 2014 at 01:29:39PM -0400, Philip Matthews wrote: 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. All large scale deployments I know about are using RA for WAN, and DHCP-PD for LAN - so that's a third variant... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Microsoft: Give Xbox One users IPv6 connectivity
Hi, On Thu, Mar 13, 2014 at 10:44:17PM +, Eric Vyncke (evyncke) wrote: Or is it because AVM blocks all inbound IPv6 connection and X/Box has no choice but falling back on Teredo? I am really unclear on the exact situation No, AVM blocks *Teredo*. Native IPv6 is permitted according to firewall config on the box... but as far as I understand, the XBox does not even *try* native. It will do Teredo, period. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpe3d7W6nW6B.pgp Description: PGP signature
Re: Microsoft: Give Xbox One users IPv6 connectivity
Hi, On Thu, Mar 13, 2014 at 07:17:16PM -0500, David Farmer wrote: They prefer native IPv6, but only if all the peer-to-peer participants also have native IPv6. So, if all your gamer buddies have native IPv6, then native IPv6 is preferred. They do not want to use Teredo Gateways. So, they do not allow Native IPv6 to Teredo communications, and prefer Teredo if any of the participants needs Teredo to do IPv6. OK, thanks. I was not fully aware of these details, but it does explain what happens - since native IPv6 is still not ubiquitous, at least one of the players will be on Teredo, and *that* will not work through a (default-config) AVM box if the AVM has native IPv6 (do not tunnel if you can do native, it's better for your packets), so all fall back to IPv4... Yeah, hard to see how to fix that, without resorting to Teredo relays (which are not a good approach to latency-sensitive gaming traffic either). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpTr8iJD7mhG.pgp Description: PGP signature
Re: Microsoft: Give Xbox One users IPv6 connectivity
Hi On Thu, Mar 13, 2014 at 07:12:54PM +, Eric Vyncke (evyncke) wrote: What annoys me more if the fact that AVM (and they are not the only one -- see Technicolor others) naively believes that NAT44 offered some security by preventing inbound connections... This means that there is NO open connectivity between two X/Box behind a closed AVM CPE... Hence X/Box has no choice and is smart enough to fall back in the legacy NAT44 mode with a TURN (or in this case Teredo) to bypass NAT. A very nice opportunity to run man-in-the-middle attack on a foreign ground. I'm not sure what NAT44 has to do with it. The point is that there is *native* IPv6 and the XBox insists on preferring Teredo - and the AVM box blocks Teredo if it has native IPv6, because there is no real use in permitting an tunnel IPv6 around the IPv4-only router! protocol when there *is* a perfectly good IPv6-capable router around... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: interesting multicast packet
Hi, On Wed, Feb 26, 2014 at 10:57:07PM -0600, Frank Bulk wrote: I suggest using Microsoft Network Monitor (http://www.microsoft.com/en-us/download/details.aspx?id=4865) to identify the processing sending out that traffic. We did. It says unknown... But I think Daniel's find is spot-on, as https://malwr.com/analysis/ZDg2MzhjNmJhOGIxNGNiM2I2NmRkMTMzODBkZjllYmY/ shows the string we saw in the packet (click on static analysis - strings - RELARELAY_RESPONDRELA), a McAffee Framework Service is indeed installed and that seems to be a known side effect - though nobody seems to have observed this on IPv6 yet... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpk1po1jEHQU.pgp Description: PGP signature
interesting multicast packet
Hi, my google-fu is failing me, but maybe one of you knows. After some troubleshooting around a Juniper SSG cluster today, we found that a windows server on the trust side of the SSG cluster is emitting UDP packets towards ff08::2.8083 (UDP, payload length 21) ff08::2 = all routers, organization-scoped These packets are sent about every 61 minutes, and caused some interesting issues here as the *passive* SSG leaked them out towards the router, leading to the NSRP MAC address showing up on the wrong switch port, causing short hickups. But that's not what I'm wondering about - I'm more curious about that sort of packet - what is that? What is it used for? Which process is emitting it, and what is it trying to achieve? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: interesting multicast packet
Hi, On Tue, Feb 25, 2014 at 11:13:31AM +0100, Mikael Abrahamsson wrote: On Tue, 25 Feb 2014, Gert Doering wrote: ff08::2.8083 (UDP, payload length 21) But that's not what I'm wondering about - I'm more curious about that sort of packet - what is that? What is it used for? Which process is emitting it, and what is it trying to achieve? http://www.adminsub.net/tcp-udp-port-finder/8083 Port: 8083/UDP8083/UDP - Known port assignments (3 records found) ServiceDetailsSourceus-srvUtilistor (Server)IANA EMC2 (Legato) Networker or Sun Solcitice Backup (Official)WIKI QuickTime Streaming ServerApple Yeah, that I did google :-) - but it didn't really ring a bell. Does the windows machine run legato networker och similar backup service? Nothing of that sort. It's an internal management system, so something with netapp or vcenter would be possible. Backup is done with DPM, so it's not that... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpiYeMU_e4If.pgp Description: PGP signature
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Fri, Jan 24, 2014 at 01:13:13PM +, Benedikt Stockebrand wrote: Gert Doering g...@space.net writes: RFC 2292 / 3542 talk about the socket API extentions to get IPv6 destination addresses (IPV6_RECVPKTINFO), so with that and a bit of source code reading, you can figure out how it works for IPv4 (I haven't found actual docs for that yet). I still consider Stevens/Fenner/Rudoff (Unix Network Programming, Vol.1, Third Edition) the my personal favourite, especially when it comes to making sure that code is portable. Chapter 22 covers the destination address issue. Ho hum. My Stevens needs an update! I have edition one here, which ends with chapter 18 (RPC)... :-o Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Wed, Jan 22, 2014 at 12:00:05PM -0500, Simon Perreault wrote: Le 2014-01-22 11:54, Francis Dupont a écrit : On 20/01/2014 17:12, Simon Perreault wrote: IIRC, recent versions of Bind open a socket per address on IPv4 = not it is not by choice, just: - DNS requires to answer from the address the request was received - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) Exactly what I had guessed. Thanks for confirming. I was about to write it's not that hard, you have IP_PKTINFO on Linux and IP_RECVDSTADDR on *BSD - but then I remembered that bind runs on a *lot* more platforms than that, and I'm not sure if I want to know about the gory details on AIX, HP-UX, SCO, ... regarding this :-) OpenVPN is much more lucky here: it needs a tun/tap driver, so all the (nowadays) oddball platforms can not be supported anyway, which makes my life much easier (in a way). = BIND polls from time to time interfaces to bind() to new addresses (again, there is no standard/portable way to be notified. BTW we (ISC) know this is a point which can be improved so if you know a generic simple solution...) Listening on a routing socket doesn't qualify as generic nor simple, does it? ;) I'm fairly sure half of the platforms BIND runs on do not have routing sockets... so that part of the code is likely to be full of interesting bits and pieces as well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Wed, Jan 22, 2014 at 05:10:17PM +, Nick Hilliard wrote: On 22/01/2014 16:54, Francis Dupont wrote: - there is no standard/portable way to do this without the one socket per address in IPv4 (if you need an argument, just ask what this discussion is about :-) i thought recvfrom() fixed this issue? Forgive me if I'm wrong here - it's been far too long since I've done any socket related stuff. recvfrom() will give you the source address of the packet, but not the destination address (*your* address where you received the packet on). recvmsg() will give that to you, but the interface for IPv4 is system dependent, and I'm fairly sure, not present everywhere bind runs. RFC 2292 / 3542 talk about the socket API extentions to get IPv6 destination addresses (IPV6_RECVPKTINFO), so with that and a bit of source code reading, you can figure out how it works for IPv4 (I haven't found actual docs for that yet). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Mon, Jan 20, 2014 at 12:49:56PM +, Benedikt Stockebrand wrote: Gert Doering g...@space.net writes: So I would activate both IPPROTO_IPV6/IPV6_RECVPKTINFO *and* SOL_IP/IP_PKTINFO, and depending on the real address family I'll see one or the other? I've run into this sort of problems a few years ago, but I used a different solution: I didn't use mapped addresses but two separate sockets, one for IPv4 and another for IPv6. It isn't nice, but it sorted out the problem in a way that worked on all platforms I tested without any problems or #ifdefs or whatever. I expected that suggestion :-) (actually I expected a much longer discussion about the evilness of IPv4-mapped addresses on an IPv6 socket, but to my pleasant surprise, the actual fix came much faster) (I'm surprised your code didn't need #ifdefs for the IPv4 part, as the ancilliary socket stuff is completely different on Linux and the BSDs here... IP_PKTINFO vs. IP_RECVDSTADDR... for IPv6 it's the same, but even there you have 2292-only and 3542 implementations) Of course, the key question then is how much trouble is it to fix that in the existing application code base. Much :-). This *is* a long-term goal, though, to enable OpenVPN to listen on multiple sockets in parallel (including udp and tcp in the same server), but this part of the code is *old*, has way too many options, and runs on way too many systems with their own specific surprises. We're slowly working our way through it, and what we'll have in OpenVPN 2.4 is clean dual-stack handling with a single socket (2.3 has IPv4 and IPv6, but no real call getaddrinfo(), use IPv4 or IPv6, depending on what getaddrinfo() returns and what works mechanics). So, for the time being, the decision was to go for a single server socket at this point and fix other stuff first. Then come back. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Mon, Jan 20, 2014 at 09:28:21AM -0500, Simon Perreault wrote: Le 2014-01-20 09:00, Gert Doering a écrit : This *is* a long-term goal, though, to enable OpenVPN to listen on multiple sockets in parallel (including udp and tcp in the same server), but this part of the code is *old*, has way too many options, and runs on way too many systems with their own specific surprises. rant In my experience, this is the single most difficult thing about migrating a code base to dual-stack. Code bases that already deal with multiple IPv4-only sockets are *much* easier to migrate to dual-stack than those that expect only a single socket. True, and other functionality is easier to add as well (like listen on the official port and something else for special cases, etc.) :-) Turns out, as you describe, that we can't always start from scratch but have to work with what's there... (The option to rip out *all* socket handling and replace it by boost asio has been brought up...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Mon, Jan 20, 2014 at 04:01:23PM +, Benedikt Stockebrand wrote: Anyway, if you really want to make your life miserable, open sockets bound to the individual IP addresses found on the machine---and then also listen on a routing socket so you know you have to look for new addresses coming in... (Last time I checked that was pretty much the only option you had with Java.) *That* is where we will *not* go. It's what bind and ntpd do, and it's a large can of different worms we do not like either :-) And the #ifdef list for how do I find out which interfaces exist on this system? is just so slightly longer than how do I get target addresses out of ancilliary data :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgp0VIzpqf6NV.pgp Description: PGP signature
IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, there is a lot of Linux IPv6 knowhow here, let's see if this rings a bell for someone. OpenVPN currently uses a single UDP socket for it's network communication, which means that on a server with more than one IPv6 address, it needs to use IPV6_RECVPKTINFO (RFC 3542, 6.2, last paragraph) to get it's *own* IPv6 address the packet went to, and reply with the correct address (other daemons like bind or ntpd use one udp socket per IPv6 address, which sucks in other ways). To make things a bit more complicated, we have *one* UDP socket, and use that for IPv4 and for IPv6 packets, so IPv4 connections to a dual-stack server show up as IPv6 connections coming from :::1.2.3.4 - which also works quite nicely, except for one catch... ... the IPV6_RECVPKTINFO code just returns *nothing* on Linux for this case (specifically, CMSG_FIRSTHDR() is just NULL...) - so it looks as if this is a case of someone should propably implement this... (interesting enough, FreeBSD up to 8.x behaved the same way as Linux, but in 9.x it works. It also works on NetBSD. Since OpenBSD does not support dual-stack sockets, it's not relevant there) Now the actual question: does this ring a bell for one of the Linux kernel gurus reading here? (Test code smaller than install OpenVPN is available at http://www.greenie.net/ipv6/mhome.c - run as ./mhome, and then send an IPv6 or IPv4 packet UDP packet to port 50001 on that host. The code is not very pretty and might have bugs on its own, but it *has* all the diagnostics to see what happens under the hood on the myriard just-so-slightly-different unix-alike systems...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?
Hi, On Sun, Jan 19, 2014 at 11:00:00PM +0100, Hannes Frederic Sowa wrote: ... the IPV6_RECVPKTINFO code just returns *nothing* on Linux for this case (specifically, CMSG_FIRSTHDR() is just NULL...) - so it looks as if this is a case of someone should propably implement this... I see the problem and yes, this is unfortunate, I see. Let me cook up a patch this week and depending on the size we maybe can get this into stable. Cool :-) You can also use IP_PKTINFO on IPv6 socket with correct protocol level in setsockopt, it will report the the local address via IPv4 SOL in_pktinfo ancillary data, then. So I would activate both IPPROTO_IPV6/IPV6_RECVPKTINFO *and* SOL_IP/IP_PKTINFO, and depending on the real address family I'll see one or the other? Since the recvmsg() code has to be version agnostic anyway, that might actually work... *testing*... mmmh, it returns *something* (improvement!) but the bits are not there the way the code expects them (it prints 200:0:c195:30aa:: as address, which has all the right bits, but not in the right place). Ah, I can see what is happening... the code is (unsurprisingly) getting confused about is this IPv4 or IPv6 and filling the wrong structure... more hacking on that tomorrow. Thanks! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpTf2B5xSRih.pgp Description: PGP signature
Re: MTU handling in 6RD deployments
Hi, On Tue, Jan 07, 2014 at 12:37:39PM +0100, Tore Anderson wrote: Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: Have a higher IPv4 MTU between the 6rd tunnel endpoints sounds like a nice solution an ISP could deploy. But I've long given up hope after everybody seems to agree that 1492 is just fine. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: RA DHCP problem...
Hi, On Mon, Dec 30, 2013 at 04:13:28PM +0100, Lorenzo Colitti wrote: No, I mean - from a *security* perspective there's actually no security, because if there existed a host implementation that always tried all source addresses every time it connected, then that implementation would always work with no issues, even if you tried to put it on a restricted VLAN. No :-) - incoming packets from the host will be put into the assigned VLAN *only*. So exactly one combination of src address + default gw will get anywhere (hitting all restrictions if it's a restricted VLAN), and all other combinations will get *nowhere* - at least nowhere off-link - because the source IP will be wrong. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: 'Upgrading' NAT64 to 464XLAT?
Hi, On Tue, Nov 26, 2013 at 12:55:18AM -0800, Doug Barton wrote: On 11/26/2013 12:31 AM, Gert Doering wrote: I think he's saying that everyone should be using dual-stack, because that's so much easier to roll out and maintain, and there's still plenty of IPv4 left in the US region. Which uses more IPv4 addresses, a traditional IPv4 NAT or 464xlat? At the end of the day the PLAT still has to talk to the v4 net. You completely missed the point about dual-stack being so much easier to roll out and maintain. If I can get away with providing only a single-stack IPv6 *network*, with some added warts for a small (we're talking mobile networks here, and only a few applications there insist on being IPv4-only) subset that needs to do IPv4, this is a clear win. And of course you need less IPv4 if most of your customer base is not using IPv4. Note that I didn't say I would do this in a DSL style mass market deployment. And frankly I take offense at the gratuitous American bashing here. I wasn't bashing Americans in general here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpA_e2_B1Z0f.pgp Description: PGP signature
Re: Best practice - dual stack DNS?
Hi, On Tue, Oct 22, 2013 at 04:45:02AM +, Eric Vyncke (evyncke) wrote: I can confirm the lack of support on IOS (see my email address). Moreover, AFAIK there is no support in Windows, Android and Mac OS/X There is support in iOS, though :-) Gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Best practice - dual stack DNS?
Hi, On Mon, Oct 21, 2013 at 02:24:27PM +0200, Roger Wiklund wrote: So currently I only have IPv4 DNS and what works just fine. What's the best practice for dual stack DNS? Should I bother with setting up DHCPv6 relay etc? Well, how do you handle clients that do not want to use IPv4? So yes, DHCPv6 and RDNSS is it :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: Best practice - dual stack DNS?
Hi, On Mon, Oct 21, 2013 at 02:46:08PM +0200, Enno Rey wrote: Well, how do you handle clients that do not want to use IPv4? So yes, DHCPv6 and RDNSS is it :-) which both are (still) not supported by Android, to the best of my knowledge. Yeah, Android seems to be a bit lacking in the IPv6 department... :-( Not sure about the environment of the OP but at least for Android clients his exact setup is probably the way to go [besides manually configuring DNS resolvers in some Android-based phones GUI]. This worked nicely on the IPv6-only + NAT64/DNS64 wifi at RIPE67 - configuring a bogus IPv4 address, no IPv4 default gateway, and manually entering the IPv6 DNS64 server. But of course that was just a stopgap to enable testing the NAT64 environment, not something I consider production ready. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: interesting about OSX, NAT64 prefix discovery
Hi, On Mon, Oct 14, 2013 at 08:30:05AM +0200, Mikael Abrahamsson wrote: Well, I don't *know* this is what was happening, but I see no other mechanism that would explain the behaviour I was seeing. Anyone else seen this or know more? My guess would be more like resolver queries for IPv4 and IPv6. IPv4 is serviced from /etc/hosts, while IPv6 is serviced from DNS = DNS64. An IPv4-only entry in /etc/hosts will not result in IPv6 resolver lookups will return NXDOMAIN. At least that's my theory (not having an MacOS 10.8 available just now to test) :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: IPV6 Minimom alocation for recidential customers
Hi, On Tue, Aug 20, 2013 at 10:55:48PM -0700, David Conrad wrote: On Tue, Aug 20, 2013 at 05:03:01PM +0200, Gert Doering wrote: fixing my sentence to avoid more confusion: The IETF formally left the address space distribution regime when they delegated responsibility to IANA Wait. What? IETF gave responsibility for address distribution to IANA. It's called delegation, which goes along with not meddling with it anymore. IANA, in turn, gave it to the RIRs, and policy is now made by the RIR constituencies, not by IETF or IANA. But you know all that already, so what about the sentence above (except my blunder) is upsetting you? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 pgpfmDAjer0IX.pgp Description: PGP signature
Re: Amount of announced IPv4-space by ASN not announcing IPv6?
Hi, On Tue, Aug 13, 2013 at 12:01:57PM +0400, ?? wrote: it means that no. of AS's in my message is wrong... Indeed. Number of IPv4 ASes is at about 45.000, IPv6 ASes at about 7500. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 pgpMfQeLfLjZy.pgp Description: PGP signature
Re: Google's unusual traffic notification
Hi, On Wed, Jul 24, 2013 at 10:05:16AM +0200, g...@switch.ch wrote: A customer reported to us that many of his users have been getting the Our systems have detected unusual traffic from your computer network message from Google since last week. Apparently, this is only happening for IPv6, which makes me suspect that there is some kind of glitch with Google's technique for detecting what they believe is automated traffic. ACK! I've had this happen twice to our office network now, only on IPv6, and nothing in my logs or netflow data backs this... I filled in their form at https://support.google.com/websearch/contact/ban, but I'm not particualry optimistic that this will help. ... it helped (as in the message is gone), but we never heard anything back why it happened. Which is a bit frustrating. You are evil but we're not willing to tell you what it is so you can't fix it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: Linux 3.9 routing oddity
Hi, On Tue, Jul 02, 2013 at 10:09:00PM +0200, Jeroen Massar wrote: You might also want to try this out with something that is not a tun/tap interface, thus a default ethernet interface, as tun/tap might have all kinds of odd behavior, eg no or hacked neighbor discovery depending on the tool being used by the tun device. (and in case you use openvpn, kick Gert ;) I'm not sure why it would want to use ND on a tun device anyway... it doesn't do that for mine. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: same link-local address on multiple interface and OSPFv3
Hi, On Sat, Jun 29, 2013 at 08:07:57AM +1200, Brian E Carpenter wrote: Dumb question: would the same product fail if you configured 10.1.1.1 on two different IPv4 interfaces? (If yes, it tells you there is some sloppy basic design.) Uh, for IPv4, this is not exactly clearly defined what the outcome of two IPv4 interfaces having the same IP address is supposed to be - where will a packet for 10.1.1.2 be sent to, given that IPv4 has no concept of a scoped ID? For IPv6, fe80:: is fairly well defined... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: New IPv6 king of the hill: Switzerland?
Hi, On Fri, Jun 14, 2013 at 09:41:18AM +, guillaume.leclan...@swisscom.com wrote: It's interesting to remark that there is a very good availability of customer IPv6-enabled end-devices at home, so that part is definitely out of the chicken-and-egg problem. The ~10% value displayed by Switzerland is quite close to the maximum expected value if we take in consideration our market share and the percentage of customers we have enabled. It proves that the efforts especially from Google, Apple, and Microsoft have had very good results. Can you share what CPEs you are using, and how you provision 6rd there? Genuinely curious... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: Point-to-point /64
Hi, On Sun, Jun 02, 2013 at 05:49:05PM +0200, Ivan Pepelnjak wrote: I thought it was urban lore until I started digging into data sheets for various DC switches covered in my DC Fabrics webinar (yeah, couldn't resist ;) All high-speed DC switches use some variant of TCAM-based forwarding. Most of them have shared TCAM for IPv4 and IPv6 with IPv6 table size being 1/2 IPv4 table size. Draw your own conclusions. Insufficient data to draw conclusions. It could be that forwarding performance for *all* IPv6 is only half the pps rate as for IPv4 (due to alway doing two lookups), or anything else, or a combination of that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 pgpZ1HEscOnUA.pgp Description: PGP signature
Re: is gmail strongly penalizing IPv6 senders?
Hi, On Thu, May 30, 2013 at 11:35:16AM -0400, Jared Mauch wrote: On May 30, 2013, at 11:30 AM, m...@linux.it (Marco d'Itri) wrote: For the time being let's just assume that I am not a moron. :-) As a likely moron on this topic, my mail seems to be working OK. (e.g.: I refuse to deploy DNSSEC for a few reasons, and breaking my domain is a major contributor.. I only *think* i mostly get the other stuff like SPF right). If it broke over IPv6, I'm positive Gert would hunt me down. Uh, right now puck is whitelisted anyway... acl whitelist addr 2001:418:3f4::/48 ... so I won't even see whether milter-greylist thinks the SPF records are good or not. OTOH, to the semi-trained eye, the TXT record for puck looks good :-) You might want to check the ones for the lists that you host that are not list@puck.nether.net, though - outages.org comes to mind, which has no SPF record today. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
