From spz at serpens.de Sun Feb 1 13:33:41 2009 From: spz at serpens.de (S.P.Zeidler) Date: Sun, 1 Feb 2009 13:33:41 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <498310DA.1050003@spaghetti.zurich.ibm.com> References: <20090130120438.GA16878@nic.dtag.de> <4982F7A4.2070102@airwire.ie> <498310DA.1050003@spaghetti.zurich.ibm.com> Message-ID: <20090201123341.GH21531@serpens.de> Thus wrote Jeroen Massar (jeroen at unfix.org): > Martin List-Petersen wrote: > > Martin Horneffer wrote: > > [SNIP] > >> Would that be a sensible addressing scheme? Or would a customer insist > >> to get a completely independet /64 for the link addresses? > > > > SixXS uses the approach commonly of assigning the link-addresses out of > > a seperate /48 in the PoP. One /40 per PoP. [some good technical points] > Btw, you should have already done all of this when REQUESTING your > prefix from RIPE. Numberplans are important to them, they should also be > important to you. I wouldn't exactly call it wrong to check ones plans against other peoples experience every once in a while. Best practise does change over time. That said: an address plan I was involved with in the past asked for leased lines to be numbered with a /64 from the specific PoPs /48, expecting a router on the other side, and throwing a full /48 to the customer. That makes routing easier if the customer has site resilient links, too. For datacenter connections it also fed /64 from the datacenter /48 and only gave /48 if the customer had a router installed. It's expected that the customer would rarely exhaust a /64 in a flat network ;-P All in all, KISS is a very useful principle and one ought to step away from it only if it's really neccessary. :) regards, spz -- spz at serpens.de (S.P.Zeidler) From dwhite at olp.net Mon Feb 2 04:51:11 2009 From: dwhite at olp.net (Dan White) Date: Sun, 01 Feb 2009 21:51:11 -0600 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <4983B622.3010701@ibctech.ca> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> Message-ID: <49866DAF.2010909@olp.net> Steve Bertrand wrote: > ...and, if you assign a /64 global between eBGP peers (as opposed to > anything longer), BGP will automagically configure the next-hop to the > link-local: > > B>* 2001:478:235::/48 [20/0] via fe80::d8ea:2f09, gif1, 06:07:43 > > ...as opposed to this route, where a /128 global PtP is in place: > > B>* 2001:478:178::/48 [20/0] via 2001:4978:1:600::1, gif0, 06:08:14 > > What I haven't tested, but plan on doing so, is whether my theory that > moving the IPv6 peering address from one source interface to another > will not disrupt this link-local next-hop. > > You (Dan) are going to like BGP. I have had much fortune finding people > to help me out with it, particularly in the v6 context. If you ever need > any help testing a setup in the global context, email me off-list. So > long as it's low-bandwidth, I'll do anything I can to pass along > knowledge I've gained from others (including sessions (non-transit), > VMs, test routers etc). When I help others learn, I'm either reinforcing > knowledge, or having to research the unknown. > > Thanks Steve, I appreciate all the pointers in the right direction. What is the benefit of using BGP in a scenario like this (ethernet link to customer)? Would OSPF6 or RIPNG make more sense since shouldn't need to know their address? - Dan From patara at lacnic.net Mon Feb 2 19:56:24 2009 From: patara at lacnic.net (Ricardo Patara) Date: Mon, 2 Feb 2009 16:56:24 -0200 Subject: mtu Message-ID: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> Hi, Just wondering if some of you are using this technique to avoid problems from someone else accessing your website, for instance. We have our site with ipv6 for a while now, and have received complaints and we had opportunity to face the same problem several times. This happens when trying to access the site via a tunnel connection. The browser simply gives a timeout. We think this is related to pmtu and sites filtering icmp6. One of the solutions was to lower down the MTU at the site server. The question is, if this is the solution you did in case you also faced this problem. I tried to contact someone from google, but with no success. I mention google as we always try ipv6.google.com when having this type of problem just to make sure there is nothing "completely" wrong the network setup. thanks -- Ricardo Patara From ek at google.com Mon Feb 2 19:59:31 2009 From: ek at google.com (Erik Kline) Date: Mon, 2 Feb 2009 19:59:31 +0100 Subject: mtu In-Reply-To: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> Message-ID: <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> You tried to contact us? I must have missed that email, sorry. We set the MTU to 1280 near the server. We've not had any reported MTU problems (knock on wood), to the best of my knowledge. FWIW: http://ispcolumn.isoc.org/2009-01/mtu6.html 2009/2/2 Ricardo Patara : > Hi, > Just wondering if some of you are using this technique to avoid problems > from someone else accessing your website, for instance. > > We have our site with ipv6 for a while now, and have received complaints and > we had opportunity to face the same problem several times. > > This happens when trying to access the site via a tunnel connection. The > browser simply gives a timeout. > We think this is related to pmtu and sites filtering icmp6. > > One of the solutions was to lower down the MTU at the site server. > The question is, if this is the solution you did in case you also faced this > problem. > I tried to contact someone from google, but with no success. > > I mention google as we always try ipv6.google.com when having this type of > problem just to make sure there is nothing "completely" wrong the network > setup. > > thanks > -- > Ricardo Patara > > From patara at lacnic.net Mon Feb 2 22:06:06 2009 From: patara at lacnic.net (Ricardo Patara) Date: Mon, 2 Feb 2009 19:06:06 -0200 Subject: mtu In-Reply-To: <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> Message-ID: Hello Erik, Actually I tried to send an email to point of contact associated with the IP block :) Then I search for some google folks email address with no success. Thanks for your promptly answer and attention on this. In our case, in order to test if the MTU was the problem, we lowered it to 1480. But maybe it should be something around the number you mentioned. Just for curiosity, did google tried to contact upstream providers or peering to find out if there was any icmp6 filtering in some of the paths? thanks again. -- Ricardo Patara Em 02/02/2009, ?s 16:59, Erik Kline escreveu: > You tried to contact us? I must have missed that email, sorry. > > We set the MTU to 1280 near the server. We've not had any reported > MTU problems (knock on wood), to the best of my knowledge. > > FWIW: http://ispcolumn.isoc.org/2009-01/mtu6.html > > 2009/2/2 Ricardo Patara : >> Hi, >> Just wondering if some of you are using this technique to avoid >> problems >> from someone else accessing your website, for instance. >> >> We have our site with ipv6 for a while now, and have received >> complaints and >> we had opportunity to face the same problem several times. >> >> This happens when trying to access the site via a tunnel >> connection. The >> browser simply gives a timeout. >> We think this is related to pmtu and sites filtering icmp6. >> >> One of the solutions was to lower down the MTU at the site server. >> The question is, if this is the solution you did in case you also >> faced this >> problem. >> I tried to contact someone from google, but with no success. >> >> I mention google as we always try ipv6.google.com when having this >> type of >> problem just to make sure there is nothing "completely" wrong the >> network >> setup. >> >> thanks >> -- >> Ricardo Patara >> >> From gih at apnic.net Mon Feb 2 22:13:04 2009 From: gih at apnic.net (Geoff Huston) Date: Tue, 3 Feb 2009 08:13:04 +1100 Subject: mtu In-Reply-To: <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> Message-ID: <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> I had found a problem with the RFC Editor web site that prompted me to look at PMTU behavior and write the article that Erik references. The somewhat annoying aspect of this problem is that both the server and the client can be fully IPv6 "compliant" and doing absolutely nothing wrong IPv6-wise, and still the client can get a white screen "hang". What I find (as described in that article) was an initial TCP handshake with a MSS of 1440 was being used, while the true path MTU was 1480 bytes, or a TCP MSS of 1420. What I also found was that a change in end-to-end path resolved the issue for me. It seems that the most pragmatic advice is to use a lower-than-1500 MTU from the outset for IPv6 servers. More details of what I found are at http://ispcolumn.isoc.org/2009-01/mtu6.html Given that the IPv6 spec requires all network elements to cope with a 1280 octet IPv6 packet without fragmentation Google's approach here appears to be a "safe" one in terms of maximizing the prospects of a successful connection. (www.ripe.net uses a similar reduced IPv6 MTU size, as does www.apnic.net - I have not done any exhaustive survey here, but the problems with the original rfc-editor server prompted me to look around a bit to see what others did with their initial MTU. On 03/02/2009, at 5:59 AM, Erik Kline wrote: > You tried to contact us? I must have missed that email, sorry. > > We set the MTU to 1280 near the server. We've not had any reported > MTU problems (knock on wood), to the best of my knowledge. > > FWIW: http://ispcolumn.isoc.org/2009-01/mtu6.html > > 2009/2/2 Ricardo Patara : >> Hi, >> Just wondering if some of you are using this technique to avoid >> problems >> from someone else accessing your website, for instance. >> >> We have our site with ipv6 for a while now, and have received >> complaints and >> we had opportunity to face the same problem several times. >> >> This happens when trying to access the site via a tunnel >> connection. The >> browser simply gives a timeout. >> We think this is related to pmtu and sites filtering icmp6. >> >> One of the solutions was to lower down the MTU at the site server. >> The question is, if this is the solution you did in case you also >> faced this >> problem. >> I tried to contact someone from google, but with no success. >> >> I mention google as we always try ipv6.google.com when having this >> type of >> problem just to make sure there is nothing "completely" wrong the >> network >> setup. >> >> thanks >> -- >> Ricardo Patara >> >> From gih at apnic.net Mon Feb 2 22:19:08 2009 From: gih at apnic.net (Geoff Huston) Date: Tue, 3 Feb 2009 08:19:08 +1100 Subject: mtu In-Reply-To: References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> Message-ID: <29D8BFAE-C3DD-4521-9A5D-372AA3F02F7F@apnic.net> 1480 still appears to be a little too high if you want to be conservative. A teredo packet requires a 40 octet header, not 20 becuase of the UDP packet. Google offer an initial TCP mss of 1212 (which corresponds to an IPv6 packet of 1272 octects - I'm not sure why they left 'headroom' of 8 octets here - maybe some TCP option? Or allowing for an MPLS header? Or ...? I've seen 1300 octets and 1400 octets being used. but I'd offer the view that 1480 is pushing it close. But perhaps there is another way of looking at this. Ricardo, why do you want to keep the MTU as large as you can? What issues do you think you will encounter for your web pages with a MTU of, say, 1300 octets, as compared to using 1480 octets? Geoff On 03/02/2009, at 8:06 AM, Ricardo Patara wrote: > Hello Erik, > Actually I tried to send an email to point of contact associated > with the IP block :) > Then I search for some google folks email address with no success. > Thanks for your promptly answer and attention on this. > > In our case, in order to test if the MTU was the problem, we lowered > it to 1480. But maybe it should be something around the number you > mentioned. > > Just for curiosity, did google tried to contact upstream providers > or peering to find out if there was any icmp6 filtering in some of > the paths? > > thanks again. > -- > Ricardo Patara > > Em 02/02/2009, ?s 16:59, Erik Kline escreveu: > >> You tried to contact us? I must have missed that email, sorry. >> >> We set the MTU to 1280 near the server. We've not had any reported >> MTU problems (knock on wood), to the best of my knowledge. >> >> FWIW: http://ispcolumn.isoc.org/2009-01/mtu6.html >> >> 2009/2/2 Ricardo Patara : >>> Hi, >>> Just wondering if some of you are using this technique to avoid >>> problems >>> from someone else accessing your website, for instance. >>> >>> We have our site with ipv6 for a while now, and have received >>> complaints and >>> we had opportunity to face the same problem several times. >>> >>> This happens when trying to access the site via a tunnel >>> connection. The >>> browser simply gives a timeout. >>> We think this is related to pmtu and sites filtering icmp6. >>> >>> One of the solutions was to lower down the MTU at the site server. >>> The question is, if this is the solution you did in case you also >>> faced this >>> problem. >>> I tried to contact someone from google, but with no success. >>> >>> I mention google as we always try ipv6.google.com when having this >>> type of >>> problem just to make sure there is nothing "completely" wrong the >>> network >>> setup. >>> >>> thanks >>> -- >>> Ricardo Patara >>> >>> > From ek at google.com Mon Feb 2 22:43:58 2009 From: ek at google.com (Erik Kline) Date: Mon, 2 Feb 2009 13:43:58 -0800 Subject: mtu In-Reply-To: <29D8BFAE-C3DD-4521-9A5D-372AA3F02F7F@apnic.net> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <29D8BFAE-C3DD-4521-9A5D-372AA3F02F7F@apnic.net> Message-ID: <2e8c64260902021343n53948578maf5280bc6651ec8c@mail.gmail.com> Ricardo, Without being too explicit, let me just toss out ~4 categories of IPv6 brokenness we've seen in various network devices/scenarios: (1) Just no IPv6 implementation whatsoever Pretty self-explanatory. (My mom's home gateway falls into this category. Poor mom.) (2) No or low quality or quantity of testing Sometimes devices/code will actually have basically working IPv6 implementations but because of various constraints they have not had sufficient real world testing. If you're lucky you find these in your testing sandbox. Otherwise you probably only see the brokenness when live traffic starts to pass through it. (3) IPv6 != IPv4 with bigger addresses This is particularly annoying. Some implementations fail to notice the subtle differences, like that Path MTU is required to work, or you might have to (gasp!) process an IPv6 extension header, etc. Some implementations appear to understand that these differences exist but don't implement them properly anyway. These could fall in category #2, so maybe this is really #2.5 in stead of #3. (4) Misconfiguration This is the category to which I think folks refer most often, namely misconfigured ICMP6 filtering (either breaking pMTU or in some cases even breaking ND!), not paying careful attention to route preferences when one of them goes through a tunnel, and other symptoms of not generally paying the same attention to IPv6 as folks do to IPv4. Depending on your mood you might consider software IPv6 implementations a "brokenness" where there should be hardware implementations. Or add a general category for "poor performing implementations", but mostly I'd be concerned with *working* over performing, at least for current levels of IPv6 traffic. That being said, I'm not aware of any significant performance problem IPv6 Google services might be experiencing due to an MTU of 1280. If you see some please let us know (google-ipv6 at google.com). Obviously it would be cooler to run with a slightly higher MTU but I would listen to Geoff on the "1480 might be pushing your luck" point. YMMV, obviously. (Geoff: I still have no idea why those other 8 bytes are shaved off, but I've not had time to look into it. :-) 2009/2/2 Geoff Huston : > 1480 still appears to be a little too high if you want to be conservative. A > teredo packet requires a 40 octet header, not 20 becuase of the UDP packet. > > Google offer an initial TCP mss of 1212 (which corresponds to an IPv6 packet > of 1272 octects - I'm not sure why they left 'headroom' of 8 octets here - > maybe some TCP option? Or allowing for an MPLS header? Or ...? > > I've seen 1300 octets and 1400 octets being used. > > but I'd offer the view that 1480 is pushing it close. > > But perhaps there is another way of looking at this. Ricardo, why do you > want to keep the MTU as large as you can? What issues do you think you will > encounter for your web pages with a MTU of, say, 1300 octets, as compared to > using 1480 octets? > > Geoff > > > > > On 03/02/2009, at 8:06 AM, Ricardo Patara wrote: > >> Hello Erik, >> Actually I tried to send an email to point of contact associated with the >> IP block :) >> Then I search for some google folks email address with no success. Thanks >> for your promptly answer and attention on this. >> >> In our case, in order to test if the MTU was the problem, we lowered it to >> 1480. But maybe it should be something around the number you mentioned. >> >> Just for curiosity, did google tried to contact upstream providers or >> peering to find out if there was any icmp6 filtering in some of the paths? >> >> thanks again. >> -- >> Ricardo Patara >> >> Em 02/02/2009, ?s 16:59, Erik Kline escreveu: >> >>> You tried to contact us? I must have missed that email, sorry. >>> >>> We set the MTU to 1280 near the server. We've not had any reported >>> MTU problems (knock on wood), to the best of my knowledge. >>> >>> FWIW: http://ispcolumn.isoc.org/2009-01/mtu6.html >>> >>> 2009/2/2 Ricardo Patara : >>>> >>>> Hi, >>>> Just wondering if some of you are using this technique to avoid problems >>>> from someone else accessing your website, for instance. >>>> >>>> We have our site with ipv6 for a while now, and have received complaints >>>> and >>>> we had opportunity to face the same problem several times. >>>> >>>> This happens when trying to access the site via a tunnel connection. The >>>> browser simply gives a timeout. >>>> We think this is related to pmtu and sites filtering icmp6. >>>> >>>> One of the solutions was to lower down the MTU at the site server. >>>> The question is, if this is the solution you did in case you also faced >>>> this >>>> problem. >>>> I tried to contact someone from google, but with no success. >>>> >>>> I mention google as we always try ipv6.google.com when having this type >>>> of >>>> problem just to make sure there is nothing "completely" wrong the >>>> network >>>> setup. >>>> >>>> thanks >>>> -- >>>> Ricardo Patara >>>> >>>> >> > > From berni at birkenwald.de Tue Feb 3 00:13:55 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 3 Feb 2009 00:13:55 +0100 Subject: mtu In-Reply-To: <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> Message-ID: <20090202231354.GA4689@lxbsc01> On Tue, Feb 03, 2009 at 08:13:04AM +1100, Geoff Huston wrote: Hello Geoff, > It seems that the most pragmatic advice is to use a lower-than-1500 MTU > from the outset for IPv6 servers. More details of what I found are at > http://ispcolumn.isoc.org/2009-01/mtu6.html Great summary, thanks a lot for this excellent article! However, I cannot agree with your conclusion. On the one hand we see a lot of people, especially in the research networks lobbying for networks that are transparent for 4470 byte or ~9000 byte frames to reduce overhead and increase (host) throughput with >>GE rates, and on the other hand we cannot even get 1500 byte reliably and propose to set the MTU of servers (all servers?) to a lower value? That can't be right. We need to rat out those issues before it's too late. We have been running our webservers (http://www.lrz.de, granted it's not really high profile) v6-enabled with MTU 1500 for three years now, same for MX and other services. We have some thousand clients all running on MTU 1500 links (and thus sending out MSS 1440 and relying on IPv6 pMTU discovery) and have not heard complaints. If you are repeatedly having issues chances are high that the problem is close to your own network, which might make debugging and contacting the appropriate parties a bit easier. The most common issues are IPv6 tunnels on interprovider links. Most implementations (including Cisco and Juniper) set the IPv6 MTU of the tunnel to the IPv4 MTU (to the tunnel destination) minus 20/24 bytes of overhead. Which is a good default when you have the standard 1500 byte core links, but bad when your tunnelbox is connected with (for example) POS (4470 bytes) or some jumbo-enabled ethernet link. IPv6 MTU is set to 4450 bytes, a native 1500 byte IPv6 packet comes in, gets encapsulated, sent as 1520 byte IPv4 packet through the core and then dies at the 1500 byte IX fabric to the peer. Bam! I've seen this issue multiple times now. These defaults are service affecting. Even worse, two or three times when I told the engineering folks of the affected network about the problem they did not fix the tunnel immediately or turned it down, but kept it running. After all they see traffic through it, so it can't be broken. But they broke a lot of connections through that tunnel without even noticing it. So a lot of education about pMTU and the effects of broken pMTU due to misconfigured tunnels is still necessary. Your article, although a bit lengthy for a quick slap, is very helpful in this. If you are having issues and you have a Linux box around, try tracepath6. It is a really great tool to find MTU issues on routers, and notifying the affected party of this problem helps you and a lot of other people. OBtracerouteoftheday: traceroute to www.rfc-editor.org (2001:1878:400:1:214:4fff:fe67:9351) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 80, from port 60366, 30 hops max, 60 byte packets 1 vl-23.csr2-2wr.lrz-muenchen.de (2001:4ca0:0:f000::2) 0.400 ms 0.302 ms 0.282 ms 2 vl-3051.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:51::1) 0.530 ms 0.400 ms 0.336 ms 3 xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1) 0.543 ms 0.393 ms 0.362 ms 4 2001:638:c:c043::2 (2001:638:c:c043::2) 8.272 ms 8.133 ms 7.889 ms 5 dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1) 7.826 ms 7.808 ms 7.834 ms 6 abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12) 100.938 ms 119.152 ms 106.065 ms 7 2001:468:ff:209::2 (2001:468:ff:209::2) 117.410 ms 117.312 ms 117.330 ms 8 2001:468:ff:204:8000::2 (2001:468:ff:204:8000::2) 127.892 ms 127.959 ms 127.867 ms 9 2001:468:ff:407::2 (2001:468:ff:407::2) 174.721 ms 173.358 ms 173.695 ms 10 2001:468:ff:716::1 (2001:468:ff:716::1) 173.303 ms 185.809 ms 174.810 ms 11 kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6) 169.214 ms 169.212 ms 169.147 ms 12 cenichpr-1-is-jmb-778.snvaca.pacificwave.net (2001:504:b:88::129) 184.891 ms 184.551 ms 184.509 ms 13 lax-hpr--svl-hpr-10ge.cenic.net (2001:468:e00:403::1) 184.587 ms 184.534 ms 184.519 ms 14 2607:f380::4:0:103 (2607:f380::4:0:103) 180.625 ms 180.597 ms 180.691 ms 15 2001:1878:8::2 (2001:1878:8::2) 180.895 ms 180.827 ms 180.773 ms 16 www.rfc-editor.org (2001:1878:400:1:214:4fff:fe67:9351) 181.112 ms [open] 181.000 ms 180.865 ms Am I the only one shuddering when I see Kreonet in the middle of an Europe-to-US trace? Fortunately traffic stays within .us and does not take a detour, but that might just be my luck today. Bernhard From dr at cluenet.de Tue Feb 3 00:47:35 2009 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 Feb 2009 00:47:35 +0100 Subject: mtu In-Reply-To: <20090202231354.GA4689@lxbsc01> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> Message-ID: <20090202234735.GA2453@srv03.cluenet.de> On Tue, Feb 03, 2009 at 12:13:55AM +0100, Bernhard Schmidt wrote: > The most common issues are IPv6 tunnels on interprovider links. Indeed, this is in line with my observations over the years. > Most implementations (including Cisco and Juniper) set the IPv6 MTU of the > tunnel to the IPv4 MTU (to the tunnel destination) minus 20/24 bytes of > overhead. Cisco IOS and Juniper JUNOS derrive the tunnel payload MTU from the physical egress interface MTU the tunnel traverses over at any given moment in time. So it's best practise to always nail your tunnel MTU to the proper value according to what you can guarrantee between the tunnel end points. For IOS: interface Tunnel1 tunnel mode gre ip (default) ipv6 mtu 1476 interface Tunnel2 tunnel mode ipv6ip ipv6 mtu 1480 For JUNOS: interfaces { // GRE gr-0/0/0 { unit 1 { family inet6 { mtu 1476; } } } // IPv6-in-IP ip-0/0/0 { unit 1 { family inet6 { mtu 1480; } } } } Beware: this is payload MTU. Above MTU will result in max 1500 octet tunnel packets. Using GRE features like keying will increase tunnel overhead so payload MTU has to be lowered. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From niels=cluenet at bakker.net Tue Feb 3 01:40:05 2009 From: niels=cluenet at bakker.net (Niels Bakker) Date: Tue, 3 Feb 2009 01:40:05 +0100 Subject: mtu In-Reply-To: <20090202234735.GA2453@srv03.cluenet.de> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> <20090202234735.GA2453@srv03.cluenet.de> Message-ID: <20090203004005.GN56621@burnout.tpb.net> * dr at cluenet.de (Daniel Roesen) [Tue 03 Feb 2009, 00:47 CET]: [..] >Beware: this is payload MTU. Above MTU will result in max 1500 octet >tunnel packets. Using GRE features like keying will increase tunnel >overhead so payload MTU has to be lowered. Or you go native. Why do people insist on this bad practice of digging tunnels for what is supposed to be the new internet protocol? *points at calendar* -- Niels. -- From gih at apnic.net Tue Feb 3 03:11:59 2009 From: gih at apnic.net (Geoff Huston) Date: Tue, 3 Feb 2009 13:11:59 +1100 Subject: mtu In-Reply-To: <20090202231354.GA4689@lxbsc01> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> Message-ID: <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> These are interesting comments Bernhard and, on the whole I agree with them. A few comments in response: 1 - On large packet sizes. It seems anomalous that the IEEE has been unable to reach the levels of consensus thjat would allow standardization of packet frames of size > 1500 octets. In a world where the LAN carriage rate has advanced from 10Mbps to 10 Gbps, a comparable packet size would be 1.5M. Yet 1500 is as large as the standard world has got to. Part of the problem is that there are a number of problems here - carriage efficiency in terms of multiplexing multiple independent streams tends to want a lower minimum packet size for constant time / data applications (voice, interactive access, even video) while larger packet sizes tend to work to the advantage of the efficiency of large volume non time-based transfers (which although fewer in number in terms of stream counts are still larger in terms of byte volumes, 2 - on the interaction between packet sizes and TCP transport. The basic mathematical model is MSS BW = --------------------------------------------------------- RTT*sqrt(1.33*p) + RTO*p*(1+32*p^2) * min(1,3*sqrt(.75*p)) (I hope that asciified ok) or MSS 1 BW = C --- ------- RTT sqrt(p) where p is the packet loss rate. It suggests that higher MSS sizes is directly proportional to throughput, but that's misleading in some ways - the issue is the packet loss rate, p. If that too is proportional to the packet size then the expectation that larger packet sizes directly produces better performance is not exactly the case. Another model of TCP congestion performance is to take the "sawtooth" pattern of TCP and note that the area under the "sawtooth is related to the available flow capacity of the connection, not the packet quantization levels (a smaller packet size produces a higher frequency oscillation, but not necessarily a greatly reduced mean value across with TCP oscillates. i.e. smaller packet sizes are not necessarily going to mean greatly reduced network throughput rates in many practical cases. 3 - the problem is close to "your own network". The example I wrote up for the article was interesting in that the problem was close neither to me as the client nor close to the server. The problem was in the transit path. Now I can't generalize about this because my sources of data are limited. Intuition tends to say that per packet filters are more likely to be at the edge than in the interprovider code, so close to the edge seems like a good guess, but the case that I looked at in detail tended to suggest otherwise with IPv6 - maybe its becuase of the strange behaviours of a network that still contains a reaonsable 4 - tunnels - tunnels are just SO strange when you look at the corner cases - what happens with ICMP messages that originated within the tunnel, for example, and the treatment of the DF bit. I am still scratching my head with my local IPv6 in IPv4 tunnel, for example: interface Tunnel0 no ip address ipv6 address tunnel source 10.0.0.1 tunnel destination 10.0.0.2 tunnel mode ipv6ip Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 1514? what a strange default selection! I also don't understand the encapsulation behavior on tunnel ingress - but maybe thats just me! i.e.when an IPv6 packet thats too big for a tunnel gets wrapped in an IPv4 wrapper where IPv4 fragmentation is allowed, then should the ingress router simply accept the packet, and fragment it? On the whole I'd stand by the general advice that a dual-homed server will fewer client "problems" if it uses a more conservative approach to MTU selection that allows for somewhere between 40 and 60 bytes to be added to an IPv6 packet in transit without causing the packet to hit a 1500 octet fragmentation choke point with all the consequent issues of ICMPv6 coherency that we seem to have in today's networks. The tradeoff appears to be one related to performance and I am not convinced that the marginal differences in theoretical performance with the slightly larger MTU are worth the pain. Your view may well be different, of course! Geoff On 03/02/2009, at 10:13 AM, Bernhard Schmidt wrote: > On Tue, Feb 03, 2009 at 08:13:04AM +1100, Geoff Huston wrote: > > Hello Geoff, > >> It seems that the most pragmatic advice is to use a lower-than-1500 >> MTU >> from the outset for IPv6 servers. More details of what I found are at >> http://ispcolumn.isoc.org/2009-01/mtu6.html > > Great summary, thanks a lot for this excellent article! > > However, I cannot agree with your conclusion. On the one hand we see a > lot of people, especially in the research networks lobbying for > networks > that are transparent for 4470 byte or ~9000 byte frames to reduce > overhead and increase (host) throughput with >>GE rates, and on the > other hand we cannot even get 1500 byte reliably and propose to set > the > MTU of servers (all servers?) to a lower value? That can't be right. > > We need to rat out those issues before it's too late. We have been > running our webservers (http://www.lrz.de, granted it's not really > high > profile) v6-enabled with MTU 1500 for three years now, same for MX and > other services. We have some thousand clients all running on MTU 1500 > links (and thus sending out MSS 1440 and relying on IPv6 pMTU > discovery) > and have not heard complaints. If you are repeatedly having issues > chances > are high that the problem is close to your own network, which might > make > debugging and contacting the appropriate parties a bit easier. > > The most common issues are IPv6 tunnels on interprovider links. Most > implementations (including Cisco and Juniper) set the IPv6 MTU of the > tunnel to the IPv4 MTU (to the tunnel destination) minus 20/24 bytes > of > overhead. Which is a good default when you have the standard 1500 byte > core links, but bad when your tunnelbox is connected with (for > example) > POS (4470 bytes) or some jumbo-enabled ethernet link. IPv6 MTU is > set to > 4450 bytes, a native 1500 byte IPv6 packet comes in, gets > encapsulated, > sent as 1520 byte IPv4 packet through the core and then dies at the > 1500 > byte IX fabric to the peer. Bam! > > I've seen this issue multiple times now. These defaults are service > affecting. Even worse, two or three times when I told the engineering > folks of the affected network about the problem they did not fix the > tunnel immediately or turned it down, but kept it running. After all > they see traffic through it, so it can't be broken. But they broke a > lot > of connections through that tunnel without even noticing it. So a lot > of education about pMTU and the effects of broken pMTU due to > misconfigured tunnels is still necessary. Your article, although a bit > lengthy for a quick slap, is very helpful in this. > > If you are having issues and you have a Linux box around, try > tracepath6. It is a really great tool to find MTU issues on routers, > and > notifying the affected party of this problem helps you and a lot of > other people. > > OBtracerouteoftheday: > > traceroute to www.rfc-editor.org > (2001:1878:400:1:214:4fff:fe67:9351) from > 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 80, from port 60366, 30 > hops max, 60 byte packets > 1 vl-23.csr2-2wr.lrz-muenchen.de (2001:4ca0:0:f000::2) 0.400 ms > 0.302 ms 0.282 ms > 2 vl-3051.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:51::1) 0.530 ms > 0.400 ms 0.336 ms > 3 xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1) 0.543 ms > 0.393 ms 0.362 ms > 4 2001:638:c:c043::2 (2001:638:c:c043::2) 8.272 ms 8.133 ms > 7.889 ms > 5 dfn.rt1.fra.de.geant2.net (2001:798:14:10aa::1) 7.826 ms 7.808 > ms 7.834 ms > 6 abilene-wash-gw.rt1.fra.de.geant2.net (2001:798:14:10aa::12) > 100.938 ms 119.152 ms 106.065 ms > 7 2001:468:ff:209::2 (2001:468:ff:209::2) 117.410 ms 117.312 ms > 117.330 ms > 8 2001:468:ff:204:8000::2 (2001:468:ff:204:8000::2) 127.892 ms > 127.959 ms 127.867 ms > 9 2001:468:ff:407::2 (2001:468:ff:407::2) 174.721 ms 173.358 ms > 173.695 ms > 10 2001:468:ff:716::1 (2001:468:ff:716::1) 173.303 ms 185.809 ms > 174.810 ms > 11 kreonet-1-lo-jmb-706.sttlwa.pacificwave.net (2001:504:b:10::6) > 169.214 ms 169.212 ms 169.147 ms > 12 cenichpr-1-is-jmb-778.snvaca.pacificwave.net (2001:504:b: > 88::129) 184.891 ms 184.551 ms 184.509 ms > 13 lax-hpr--svl-hpr-10ge.cenic.net (2001:468:e00:403::1) 184.587 > ms 184.534 ms 184.519 ms > 14 2607:f380::4:0:103 (2607:f380::4:0:103) 180.625 ms 180.597 ms > 180.691 ms > 15 2001:1878:8::2 (2001:1878:8::2) 180.895 ms 180.827 ms 180.773 > ms > 16 www.rfc-editor.org (2001:1878:400:1:214:4fff:fe67:9351) 181.112 > ms [open] 181.000 ms 180.865 ms > > Am I the only one shuddering when I see Kreonet in the middle of an > Europe-to-US trace? Fortunately traffic stays within .us and does not > take a detour, but that might just be my luck today. > > Bernhard From dr at cluenet.de Tue Feb 3 08:02:59 2009 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 Feb 2009 08:02:59 +0100 Subject: mtu In-Reply-To: <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> Message-ID: <20090203070259.GA16306@srv03.cluenet.de> On Tue, Feb 03, 2009 at 01:11:59PM +1100, Geoff Huston wrote: > interface Tunnel0 > no ip address > ipv6 address > tunnel source 10.0.0.1 > tunnel destination 10.0.0.2 > tunnel mode ipv6ip > > > Tunnel0 is up, line protocol is up > Hardware is Tunnel > MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > > 1514? > > what a strange default selection! sh ip ro 10.0.0.2 to find out egress interface for the tunnel. Then do a "sh ip int $EGRESS-IF | i MTU". I guess you will see 1538 there. Which might or might not be a misconfig itself. IOS tries to be clever. See my other posting in the thread. > I also don't understand the encapsulation behavior on tunnel ingress - but > maybe thats just me! i.e.when an IPv6 packet thats too big for a tunnel > gets wrapped in an IPv4 wrapper where IPv4 fragmentation is allowed, then > should the ingress router simply accept the packet, and fragment it? Some discussion on the subject: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gall at switch.ch Tue Feb 3 10:35:26 2009 From: gall at switch.ch (Alexander Gall) Date: Tue, 3 Feb 2009 10:35:26 +0100 Subject: mtu In-Reply-To: <20090203070259.GA16306@srv03.cluenet.de> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> <20090203070259.GA16306@srv03.cluenet.de> Message-ID: <18824.4062.795586.29266@hadron.switch.ch> On Tue, 3 Feb 2009 08:02:59 +0100, Daniel Roesen said: > On Tue, Feb 03, 2009 at 01:11:59PM +1100, Geoff Huston wrote: >> interface Tunnel0 >> no ip address >> ipv6 address >> tunnel source 10.0.0.1 >> tunnel destination 10.0.0.2 >> tunnel mode ipv6ip >> >> >> Tunnel0 is up, line protocol is up >> Hardware is Tunnel >> MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, >> reliability 255/255, txload 1/255, rxload 1/255 >> >> 1514? >> >> what a strange default selection! > sh ip ro 10.0.0.2 to find out egress interface for the tunnel. Then do a > "sh ip int $EGRESS-IF | i MTU". I guess you will see 1538 there. Which > might or might not be a misconfig itself. No, I think Geoff did a "show interface tunnel" but that MTU is irrelevant, I think. What you say is true for the MTU from "show ipv6 interface tunnel". That one will be the MTU of the egress interface towards the tunnel destination minus the encapsulation overhead unless you explicitely set the MTU in the configuration ("ipv6 mtu"). But beware, if that value is the same as the default derived from the egress interface, the "ipv6 mtu" statement does not appear in the configuration and the MTU changes dynamically when the egress interface changes (which can be a problem in certain cases). Here is one of our tunnels: swiCS4#sh int tun 100 | i transport|MTU MTU 1514 bytes, BW 100 Kbit, DLY 50000 usec, Tunnel protocol/transport IPv6/IP, key disabled, sequencing disabled swiCS4#sh run int tun 100 | i ipv6 mtu swiCS4#sh ipv6 int tun 100 | i MTU MTU is 9172 bytes And the MTU on the egress towards the endpoint (20 bytes encapsulation overhead) swiCS4#sh int gig 3/4 | i MTU MTU 9192 bytes, BW 1000000 Kbit, DLY 10 usec, -- Alex From dr at cluenet.de Tue Feb 3 10:52:34 2009 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 3 Feb 2009 10:52:34 +0100 Subject: mtu In-Reply-To: <18824.4062.795586.29266@hadron.switch.ch> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> <20090203070259.GA16306@srv03.cluenet.de> <18824.4062.795586.29266@hadron.switch.ch> Message-ID: <20090203095234.GA14196@srv03.cluenet.de> On Tue, Feb 03, 2009 at 10:35:26AM +0100, Alexander Gall wrote: > No, I think Geoff did a "show interface tunnel" but that MTU is > irrelevant, I think. Oh indeed, I was thinking of "sh ip(v6) interface TunnelX". I do see the same bogus MTU of 1514 on "physical" Tunnel interface level as well (encaps GRE here, so it seems to be ). > But beware, if that value is the same as the default derived from > the egress interface, the "ipv6 mtu" statement does not appear in > the configuration and the MTU changes dynamically when the egress > interface changes (which can be a problem in certain cases). Argh, I never saw this happen... need to lab that. Is that consistent behaviour across all IOS? IOS trying to be smart is harmful at best. :-( Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gall at switch.ch Tue Feb 3 11:18:57 2009 From: gall at switch.ch (Alexander Gall) Date: Tue, 3 Feb 2009 11:18:57 +0100 Subject: mtu In-Reply-To: <20090203095234.GA14196@srv03.cluenet.de> References: <947ACB19-B61F-4718-BF44-9C420C33DED7@lacnic.net> <2e8c64260902021059ja0157f7u2e2ffa9567378332@mail.gmail.com> <110F95C3-44A9-45DB-B124-BF04F0384F04@apnic.net> <20090202231354.GA4689@lxbsc01> <81795940-D074-497D-987B-0EF8C6B095CE@apnic.net> <20090203070259.GA16306@srv03.cluenet.de> <18824.4062.795586.29266@hadron.switch.ch> <20090203095234.GA14196@srv03.cluenet.de> Message-ID: <18824.6673.31748.376269@hadron.switch.ch> On Tue, 3 Feb 2009 10:52:34 +0100, Daniel Roesen said: > On Tue, Feb 03, 2009 at 10:35:26AM +0100, Alexander Gall wrote: >> But beware, if that value is the same as the default derived from >> the egress interface, the "ipv6 mtu" statement does not appear in >> the configuration and the MTU changes dynamically when the egress >> interface changes (which can be a problem in certain cases). > Argh, I never saw this happen... need to lab that. Is that consistent > behaviour across all IOS? A rather Herculean task to find this out ;-) I'm pretty sure it's in (all, most, some?) 12.2 releases, definitely sure about 12.2(33)SX/R. -- Alex From ipv6-ops+phil at spodhuis.org Tue Feb 3 20:31:40 2009 From: ipv6-ops+phil at spodhuis.org (Phil Pennock) Date: Tue, 3 Feb 2009 11:31:40 -0800 Subject: IPv6 net diagnostic tools - pointers please Message-ID: <20090203193139.GA25822@redoubt.spodhuis.org> Anyone have any pointers for network diagnostic tools which are useful for IPv6, please? Obviously, ping6 and traceroute6; and I know mtr supports IPv6. Things like traceroutes which support AS, equivalents to lft(8) so that you can trace at a higher layer, etc. Currently I'm trying to track down problems talking to ns-nl1.globnix.net (IPv6-only DNS NS host) over UDP from various places. I now know that the problems are not on my end, since at least one remote site which was having problems can query over IPv6 UDP now. If this doesn't work: dig +norec -t soa globnix.net @ns-nl1.globnix.net but this does: dig +tcp +norec -t soa globnix.net @ns-nl1.globnix.net then that's an example of the sort of thing I'm encountering and it would be pleasant to have some more advanced tools to probe for, eg, network blockage of 53/udp6. (Besides dig + tcpdump on my end). Thanks, -Phil From dean at deanpemberton.com Tue Feb 3 21:17:52 2009 From: dean at deanpemberton.com (Dean Pemberton) Date: Wed, 04 Feb 2009 09:17:52 +1300 Subject: IPv6 net diagnostic tools - pointers please In-Reply-To: <20090203193139.GA25822@redoubt.spodhuis.org> References: <20090203193139.GA25822@redoubt.spodhuis.org> Message-ID: <4988A670.6050309@deanpemberton.com> Don't forget tracepath6 for finding those MTU change points. Dean Phil Pennock wrote: > Anyone have any pointers for network diagnostic tools which are useful > for IPv6, please? > > Obviously, ping6 and traceroute6; and I know mtr supports IPv6. > > Things like traceroutes which support AS, equivalents to lft(8) so that > you can trace at a higher layer, etc. > > Currently I'm trying to track down problems talking to > ns-nl1.globnix.net (IPv6-only DNS NS host) over UDP from various places. > I now know that the problems are not on my end, since at least one > remote site which was having problems can query over IPv6 UDP now. > > If this doesn't work: > dig +norec -t soa globnix.net @ns-nl1.globnix.net > but this does: > dig +tcp +norec -t soa globnix.net @ns-nl1.globnix.net > then that's an example of the sort of thing I'm encountering and it > would be pleasant to have some more advanced tools to probe for, eg, > network blockage of 53/udp6. (Besides dig + tcpdump on my end). > > Thanks, > -Phil > > From spz at serpens.de Tue Feb 3 21:51:41 2009 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 3 Feb 2009 21:51:41 +0100 Subject: IPv6 net diagnostic tools - pointers please In-Reply-To: <20090203193139.GA25822@redoubt.spodhuis.org> References: <20090203193139.GA25822@redoubt.spodhuis.org> Message-ID: <20090203205140.GL21531@serpens.de> Thus wrote Phil Pennock (ipv6-ops+phil at spodhuis.org): > Obviously, ping6 and traceroute6; and I know mtr supports IPv6. also pchar regards, spz -- spz at serpens.de (S.P.Zeidler) From gert at space.net Wed Feb 4 16:41:34 2009 From: gert at space.net (Gert Doering) Date: Wed, 4 Feb 2009 16:41:34 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <49866DAF.2010909@olp.net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> <49866DAF.2010909@olp.net> Message-ID: <20090204154134.GT44476@Space.Net> Hi, On Sun, Feb 01, 2009 at 09:51:11PM -0600, Dan White wrote: > What is the benefit of using BGP in a scenario like this (ethernet link > to customer)? Would OSPF6 or RIPNG make more sense since shouldn't need > to know their address? Control. With BGP, you can easily filter which routes you are going to accept from your customer - even if it's a bit more tedious to set up. With OSPF, the customer can just inject you funny things like "hey, give all packets to google's IPv6 address to me"... Even if you know that your customers do not have any malicious intent, mistakes and typos happen. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090204/0a2d72ae/attachment.bin From dwhite at olp.net Wed Feb 4 17:07:38 2009 From: dwhite at olp.net (Dan White) Date: Wed, 04 Feb 2009 10:07:38 -0600 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <20090204154134.GT44476@Space.Net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> <49866DAF.2010909@olp.net> <20090204154134.GT44476@Space.Net> Message-ID: <4989BD4A.9020805@olp.net> Gert Doering wrote: > Hi, > > On Sun, Feb 01, 2009 at 09:51:11PM -0600, Dan White wrote: > >> What is the benefit of using BGP in a scenario like this (ethernet link >> to customer)? Would OSPF6 or RIPNG make more sense since shouldn't need >> to know their address? >> > > Control. > > With BGP, you can easily filter which routes you are going to accept > from your customer - even if it's a bit more tedious to set up. > > With OSPF, the customer can just inject you funny things like "hey, > give all packets to google's IPv6 address to me"... > > Even if you know that your customers do not have any malicious intent, > mistakes and typos happen. > > Gert Doering > -- NetMaster > I would think that I could filter ospf6/ripng advertisements based on which interface (customer) i'm receiving them from. I just need to set this up in a lab and learn from experience. Thanks, - Dan From steve at ibctech.ca Wed Feb 4 17:49:37 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 04 Feb 2009 11:49:37 -0500 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <4989BD4A.9020805@olp.net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> <49866DAF.2010909@olp.net> <20090204154134.GT44476@Space.Net> <4989BD4A.9020805@olp.net> Message-ID: <4989C721.5050507@ibctech.ca> Dan White wrote: > Gert Doering wrote: >> Hi, >> >> On Sun, Feb 01, 2009 at 09:51:11PM -0600, Dan White wrote: >> >>> What is the benefit of using BGP in a scenario like this (ethernet >>> link to customer)? Would OSPF6 or RIPNG make more sense since >>> shouldn't need to know their address? >>> >> >> Control. >> >> With BGP, you can easily filter which routes you are going to accept >> from your customer - even if it's a bit more tedious to set up. >> >> With OSPF, the customer can just inject you funny things like "hey, >> give all packets to google's IPv6 address to me"... >> >> Even if you know that your customers do not have any malicious intent, >> mistakes and typos happen. >> >> Gert Doering >> -- NetMaster >> > > I would think that I could filter ospf6/ripng advertisements based on > which interface (customer) i'm receiving them from. > > I just need to set this up in a lab and learn from experience. I absolutely, totally agree with the 'lab-it-up' and learn from experience statement. RIP/OSPF are not scalable for containing all routes within even a small size network. It is also not designed with security in mind. You could do all sorts of ACL's and other trickery to prevent malicious/accidentally mis-configured hosts from messing things up, but BGP generally does this inherently. As Gert stated, BGP is about control. You can do all manner of route management/manipulation from within the protocol itself. You can go as far as to allow your customers to manipulate their own routes on your routers, without the fear of them causing you issues. Definitely lab it up... but then do some research on BGP in general, eBGP and how/what it is for, and then iBGP over OSPF-carried loopbacks (vs. static routes) for within your own network. Cheers, Steve From tore at linpro.no Wed Feb 4 17:54:46 2009 From: tore at linpro.no (Tore Anderson) Date: Wed, 04 Feb 2009 17:54:46 +0100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <4989BD4A.9020805@olp.net> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> <49866DAF.2010909@olp.net> <20090204154134.GT44476@Space.Net> <4989BD4A.9020805@olp.net> Message-ID: <4989C856.3030701@linpro.no> * Dan White > I would think that I could filter ospf6/ripng advertisements based on > which interface (customer) i'm receiving them from. With OSPF you can't filter prefixes, since it's a link-state routing protocol. At least most implementations I've dealt with does not allow it. With RIPv2 you can, though, so I guess you can with RIPng as well. FWIW I've used RIP to connect customers that doesn't want the complexity of BGP, where I generally just send them a default route, and import whatever they send me into OSPF - if it passes my RIP filters, that is. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From truman at suspicious.org Wed Feb 4 23:08:14 2009 From: truman at suspicious.org (Truman Boyes) Date: Thu, 5 Feb 2009 09:08:14 +1100 Subject: How to choose IPv6 addresses for customer links? In-Reply-To: <4989C856.3030701@linpro.no> References: <20090130120438.GA16878@nic.dtag.de> <498322AA.8090506@olp.net> <20090130171557.GV44476@Space.Net> <49836528.7020805@olp.net> <20090130214953.GX44476@Space.Net> <4983B622.3010701@ibctech.ca> <49866DAF.2010909@olp.net> <20090204154134.GT44476@Space.Net> <4989BD4A.9020805@olp.net> <4989C856.3030701@linpro.no> Message-ID: <70A79ED8-1E01-44C9-8ED6-13A42584004C@suspicious.org> Hi, As noted you can't filter prefixes if you run OSPF with the customer. You can always do things like run a totally stubby area or not-so- stubby-area with you customer, but it's just a pain and it doesn't prevent the customer from sending you LSAs that can grow your LSDB. If your customer's routes are contained within a specific routing context (other than your default routing context, ie. VPN) you can decide to run OSPFv3 on your customer links. These routes will not affect other routing contexts. Ideally you will want to run BGP, it scales better for inter-domain routing. Truman Boyes On 5/02/2009, at 3:54 AM, Tore Anderson wrote: > * Dan White > >> I would think that I could filter ospf6/ripng advertisements based on >> which interface (customer) i'm receiving them from. > > With OSPF you can't filter prefixes, since it's a link-state routing > protocol. At least most implementations I've dealt with does not > allow it. > > With RIPv2 you can, though, so I guess you can with RIPng as well. > FWIW > I've used RIP to connect customers that doesn't want the complexity of > BGP, where I generally just send them a default route, and import > whatever they send me into OSPF - if it passes my RIP filters, that > is. > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > From waja at cyconet.org Wed Feb 18 18:30:53 2009 From: waja at cyconet.org (Jan Wagner) Date: Wed, 18 Feb 2009 18:30:53 +0100 Subject: IPv6 Assignment Tracking Software In-Reply-To: <496E5936.5020308@noved.org> References: <496E5936.5020308@noved.org> Message-ID: <200902181831.01778.waja@cyconet.org> On Wednesday 14 January 2009, Devon True wrote: > My ideal software would include the following: > > o Ability to track IPv4 and IPv6 addresses > o A DB that we can import and export data to/from (postgres or mysql > preferred) > o A web interface > o Ability to find IPv4 subnets easily (e.g. I have a /20, find me the > next available /28 without having to pre-allocate /28s for use) > o Robust search engine > o Built-in rwhois is a bonus Maybe you should have a look at HaCi[1]. With kind regards, Jan. [1] http://sourceforge.net/projects/haci/ -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090218/87af2ac3/attachment.bin From tls at panix.com Mon Feb 9 18:18:05 2009 From: tls at panix.com (Thor Lancelot Simon) Date: Mon, 09 Feb 2009 17:18:05 -0000 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? Message-ID: <20090209171801.GA19113@panix.com> >From almost anywhere in the Eastern U.S. I test from, traceroutes to the 6to4 anycast address seem to land at SWIPnet in Amsterdam. This is because SWIPnet seems to peer with several major U.S. providers in New York City, giving a short path from many networks in the U.S. to their Amsterdam relay -- notably, from the networks of the major U.S. residential cable providers, Time Warner and Cablevision. It looks like most public-relay traffic from a large chunk of the U.S. could stop tromboning through Europe (and wasting SWIPnet's link bandwidth across the Atlantic) if a 6to4 relay were added to one of SWIPnet's NYC core routers. Is there any chance of this? -- Thor Lancelot Simon tls at rek.tjls.com "Even experienced UNIX users occasionally enter rm *.* at the UNIX prompt only to realize too late that they have removed the wrong segment of the directory structure." - Microsoft WSS whitepaper From martin at airwire.ie Sat Feb 28 19:50:18 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 28 Feb 2009 18:50:18 +0000 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <20090209171801.GA19113@panix.com> References: <20090209171801.GA19113@panix.com> Message-ID: <49A9876A.4060406@airwire.ie> Thor Lancelot Simon wrote: >>From almost anywhere in the Eastern U.S. I test from, traceroutes to > the 6to4 anycast address seem to land at SWIPnet in Amsterdam. This > is because SWIPnet seems to peer with several major U.S. providers in > New York City, giving a short path from many networks in the U.S. to > their Amsterdam relay -- notably, from the networks of the major U.S. > residential cable providers, Time Warner and Cablevision. > > It looks like most public-relay traffic from a large chunk of the U.S. > could stop tromboning through Europe (and wasting SWIPnet's link > bandwidth across the Atlantic) if a 6to4 relay were added to one of > SWIPnet's NYC core routers. Is there any chance of this? > The question is, would it not be better to pursue some of the US carriers to get a public 6to4 relay set up. The biggest issue is the lack of 6to4 relays in the US and also in general. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From tls at panix.com Sat Feb 28 20:08:08 2009 From: tls at panix.com (Thor Lancelot Simon) Date: Sat, 28 Feb 2009 14:08:08 -0500 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <49A9876A.4060406@airwire.ie> References: <20090209171801.GA19113@panix.com> <49A9876A.4060406@airwire.ie> Message-ID: <20090228190807.GA2512@panix.com> On Sat, Feb 28, 2009 at 06:50:18PM +0000, Martin List-Petersen wrote: > Thor Lancelot Simon wrote: > > > > It looks like most public-relay traffic from a large chunk of the U.S. > > could stop tromboning through Europe (and wasting SWIPnet's link > > bandwidth across the Atlantic) if a 6to4 relay were added to one of > > SWIPnet's NYC core routers. Is there any chance of this? > > > > The question is, would it not be better to pursue some of the US > carriers to get a public 6to4 relay set up. Of course that would be a good thing. But I'd think SWIPnet might like to stop wasting transatlantic bandwidth -- it's just an accident of their IPv4 peering arrangements that is sucking 6to4 packets from all over the U.S. into their network across their transatlantic link. I don't know how to find the right people at SWIPnet, but it seems worth asking about if anyone _does_ know them. Perhaps someone here could point me in the right direction? Thor From martin at millnert.se Sat Feb 28 20:12:55 2009 From: martin at millnert.se (Martin Millnert) Date: Sat, 28 Feb 2009 20:12:55 +0100 Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <20090228190807.GA2512@panix.com> References: <20090209171801.GA19113@panix.com> <49A9876A.4060406@airwire.ie> <20090228190807.GA2512@panix.com> Message-ID: <1235848375.32023.13.camel@hsa.csbnet.se> On Sat, 2009-02-28 at 14:08 -0500, Thor Lancelot Simon wrote: > On Sat, Feb 28, 2009 at 06:50:18PM +0000, Martin List-Petersen wrote: > > Thor Lancelot Simon wrote: > > > > > > It looks like most public-relay traffic from a large chunk of the U.S. > > > could stop tromboning through Europe (and wasting SWIPnet's link > > > bandwidth across the Atlantic) if a 6to4 relay were added to one of > > > SWIPnet's NYC core routers. Is there any chance of this? > > > > > > > The question is, would it not be better to pursue some of the US > > carriers to get a public 6to4 relay set up. > > Of course that would be a good thing. But I'd think SWIPnet might like > to stop wasting transatlantic bandwidth -- it's just an accident of > their IPv4 peering arrangements that is sucking 6to4 packets from all > over the U.S. into their network across their transatlantic link. > > I don't know how to find the right people at SWIPnet, but it seems worth > asking about if anyone _does_ know them. Perhaps someone here could > point me in the right direction? > > Thor Hi Thor, I asked a SWIPnet person and he said it is in the plan to fix that. Cheers, -- Martin Millnert From swmike at swm.pp.se Sat Feb 28 20:17:12 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 28 Feb 2009 20:17:12 +0100 (CET) Subject: SWIPnet relay handling most U.S. east coast 6to4 traffic? In-Reply-To: <1235848375.32023.13.camel@hsa.csbnet.se> References: <20090209171801.GA19113@panix.com> <49A9876A.4060406@airwire.ie> <20090228190807.GA2512@panix.com> <1235848375.32023.13.camel@hsa.csbnet.se> Message-ID: On Sat, 28 Feb 2009, Martin Millnert wrote: > I asked a SWIPnet person and he said it is in the plan to fix that. Hi, I am the person he spoke to (just subscribed to this list because I heard there was a discussion regarding us). I work for Tele2/SWIPnet. It's in our plans to enable 6to4 relay on the east coast of US, but I don't have an exact date when this will happen. We've been considering stopping announcing 6to4 in the US, but we have plenty of capacity available right now, and it seems the 6to4 relay availability in the US is quite lacking, so our conclusion so far has been that it's better that we provide good capacity 6to4 with high latency, than basically none at all. If people have strong opinions that we should stop annonucing our 6to4 relays in the US, please tell us and we'll take it under consideration. -- Mikael Abrahamsson email: swmike at swm.pp.se