From shane at time-travellers.org Tue Jun 1 04:34:20 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 01 Jun 2010 10:34:20 +0800 Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C03D7DA.5020006@foobar.org> References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> Message-ID: <1275359660.2541.434.camel@shane-asus-laptop> Nick, On Mon, 2010-05-31 at 16:38 +0100, Nick Hilliard wrote: > At least Windows vista/7, Linux and FreeBSD all support dhcpv6. I look > forward to seeing os/x support some time soon. Are there plans for this that you know of? My understanding was that the Networking Powers that Be in Apple did not approve of DHCPv6 for philosophical differences. Since autoconf is Good Enough for random laptops (or other iThingies) running in dual-stack mode, I don't see much motivation for Apple to change and support DHCPv6. Maybe some enterprising Apple fan will wrap a DHCPv6 client with the Mac magical way to install things cleanly and provide a nice work-around for Apple users. It's not as good as official Apple support, but that would be useful for some administrators... -- Shane From bjorn at mork.no Tue Jun 1 09:22:02 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 01 Jun 2010 09:22:02 +0200 Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C03BADF.3080902@foobar.org> (Nick Hilliard's message of "Mon, 31 May 2010 14:34:23 +0100") References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> Message-ID: <87k4qjkyjp.fsf@nemi.mork.no> Nick Hilliard writes: > On 30/05/2010 11:05, Benedikt Stockebrand wrote: >> Using Autoconf and Network Unreachability Detection for router >> failover doesn't give you the fastest failover time, but at least it >> gives these people a chance. > > Depending on RA means: > > - loss of service measured in (by default) minutes in the case of router > failure Why? You are free to install more than one default route. > - serious security problems due to rogue RA announcements by unauthorised > network clients I don't see why RA is special here. The same goes for rogue DHCP and DHCPv6 servers. You need to filter. You do not want to allow incoming RAs on any client port in your network. Bj?rn From nick at foobar.org Tue Jun 1 11:42:49 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Jun 2010 10:42:49 +0100 Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <1275359660.2541.434.camel@shane-asus-laptop> References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> <1275359660.2541.434.camel@shane-asus-laptop> Message-ID: <4C04D619.3080409@foobar.org> On 01/06/2010 03:34, Shane Kerr wrote: > Are there plans for this that you know of? No, not aware of anything in particular; but it just looks to me that the world is going to move to dhcpv6 and will largely ignore RA, where possible. The reason for this is that Windows has pretty decent support for dhcpv6 these days, and having worked in corporate environments, I just cannot see any motivation to want to support multiple host configuration protocols, particularly when one of them (RA) doesn't give the level of control over addressing that you're used to. > My understanding was that the Networking Powers that Be in Apple did not > approve of DHCPv6 for philosophical differences. There's been very little dhcpv6 client software available until recently, but Apple will probably just ship dhcpd-4.2(+) with some shim layer. It's not like os/x isn't a melange of third party code already. > Since autoconf is Good Enough for random laptops (or other iThingies) > running in dual-stack mode, I don't see much motivation for Apple to > change and support DHCPv6. It's only a matter of time before they are forced to, and their barrier to doing so is very low indeed. Nick From tony at lava.net Tue Jun 1 11:52:26 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 31 May 2010 23:52:26 -1000 (HST) Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C04D619.3080409@foobar.org> References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> <1275359660.2541.434.camel@shane-asus-laptop> <4C04D619.3080409@foobar.org> Message-ID: On Tue, 1 Jun 2010, Nick Hilliard wrote: > No, not aware of anything in particular; but it just looks to me that the > world is going to move to dhcpv6 and will largely ignore RA, where You must be living in a different world ;) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From nick at foobar.org Tue Jun 1 14:20:48 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Jun 2010 13:20:48 +0100 Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> <1275359660.2541.434.camel@shane-asus-laptop> <4C04D619.3080409@foobar.org> Message-ID: <4C04FB20.1050701@foobar.org> On 01/06/2010 10:52, Antonio Querubin wrote: > You must be living in a different world ;) Perhaps. Anyway, this topic has strayed far off anything approaching relevance to ipv6-ops and has descended into a shouting match. If RA makes you happy, then feel free to use it and I wish you well. Nick From tjc at ecs.soton.ac.uk Tue Jun 1 15:05:11 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 1 Jun 2010 14:05:11 +0100 Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C04D619.3080409@foobar.org> References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> <1275359660.2541.434.camel@shane-asus-laptop> <4C04D619.3080409@foobar.org> <108420EC-534F-4258-B00F-EA484E209CBE@ecs.soton.ac.uk> Message-ID: On 1 Jun 2010, at 10:42, Nick Hilliard wrote: > >> Since autoconf is Good Enough for random laptops (or other iThingies) >> running in dual-stack mode, I don't see much motivation for Apple to >> change and support DHCPv6. > > It's only a matter of time before they are forced to, and their barrier to > doing so is very low indeed. > > Nick I think Apple seem to work on and push through v6 stuff that's fine for SOHO users, including Airport, but are lacking many things that are desirable in an enterprise/campus deployment. DHCPv6 is one of those, RFC3484 support and MLDv2 are other examples. We can hope :) Tim From ted.m at ipinc.net Tue Jun 1 07:13:11 2010 From: ted.m at ipinc.net (Ted Mittelstaedt) Date: Mon, 31 May 2010 22:13:11 -0700 Subject: DHCPv6 for OS/X, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <1275359660.2541.434.camel@shane-asus-laptop> References:

<4C0189A0.4030509@netability.ie> , <4C03BADF.3080902@foobar.org> <4C03D7DA.5020006@foobar.org> <1275359660.2541.434.camel@shane-asus-laptop> Message-ID: <4C0496E7.90902@ipinc.net> On 5/31/2010 7:34 PM, Shane Kerr wrote: > Nick, > > On Mon, 2010-05-31 at 16:38 +0100, Nick Hilliard wrote: >> At least Windows vista/7, Linux and FreeBSD all support dhcpv6. I look >> forward to seeing os/x support some time soon. > > Are there plans for this that you know of? > > My understanding was that the Networking Powers that Be in Apple did not > approve of DHCPv6 for philosophical differences. > > Since autoconf is Good Enough for random laptops (or other iThingies) > running in dual-stack mode, I don't see much motivation for Apple to > change and support DHCPv6. > > Maybe some enterprising Apple fan will wrap a DHCPv6 client with the Mac > magical way to install things cleanly and provide a nice work-around for > Apple users. It's not as good as official Apple support, but that would > be useful for some administrators... > The WIDE/KAME dhcp sources are known to compile on 10.5 (just type configure and make) Assuming the DHCPv6 client in this works that would let you get the IP info under OSX, the problem is sticking it into the Mac. There is someone who has done some work on this: http://tsennyipa.livejournal.com/3347.html My guess is a few hours of time from an experienced MacOSX programmer would get tsennyipa's code working. It sounds like he's almost there. I personally wouldn't want to use his protocol engine, since it's not open source, I'd try using the WIDE client. A report from IETF-71: "during the Q&A session at the plenary (after the IPv6 only event), Stuart Cheshire of Apple was venting at the mike about why they should have to support yet another protocol for address assignment and other configuration info. Someone mentioned RFC 5006 to him, and he said yes, that's most likely what they would support .. Ted From me at benedikt-stockebrand.de Tue Jun 1 15:39:51 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 13:39:51 +0000 Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C03BADF.3080902@foobar.org> (Nick Hilliard's message of "Mon, 31 May 2010 14:34:23 +0100") References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> Message-ID: Hi Nick and list, Nick Hilliard writes: > Depending on RA means: > > - loss of service measured in (by default) minutes in the case of router > failure if you had actually either tried this or at least taken a proper look at the specs, then you'd know that the upper bound here is 45s (REACHABLE_TIME \times MAX_RANDOM_FACTOR, as defined in RFC 4861) plus whatever another round of neighbor discovery takes (usually <1s). That's well within standard TCP timeouts, and yes, I've actually taken the time to double (in the RFC) and triple (in a quick test setup) check this. > - serious security problems due to rogue RA announcements by unauthorised > network clients That's a problem inherent in all multiple access networks and not specific to Autoconf. I can do the same in an IPv4 network with VRRP or HSRP clustered routers or whatever by well known ARP manipulation attacks, among other things. It's admittedly bad that router, and especially WLAN access point, vendors haven't yet widely implemented ways to filter rogue RAs like they filter rogue DHCP servers, but that's an implementation problem, not a specification one. Beyond that, if you can't get your network topology sorted out in a way that prevents these issues simply by not allowing any unauthorized clients into your sensitive subnets, that's hardly something you can blame Autoconf for. You can't expect the network layer to fix all security issues stemming from your link layer. > Either of these problems on their own makes RA unsuitable for most > applications other than enthusiast / home / playpen. Since you keep trying to insinuate that I don't know about data center operations: Take a look at http://www.top500.org/system/5090. Among the lessons I've learned from building that system is that the only way to get reliability is to avoid complexity where it doesn't contribute to the system---especially if you run 24/7 and have to ensure that you always have a team on call duty who can handle the system in all of its aspects. I'm not saying that this is a setup where I'd use router failover based on Autoconf, but if I ever had to build anything like that again I'd test all the options available (VRRP, HSRP, passive OSPF, passive RIP, Autoconf, whatever redundancy features the application software offers, custom failover scripts) before I'd jump to conclusions. > But, if you want to operate your network with lousy availability > characteristics and where any arbitrary client can hijack the > network, then by all means, please go ahead and do so. Just don't > pretend that it's going to be reliable. Again, maybe you should just fix your networks. From your comments I suggest you start with separating nodes with different privileges into separate subnets. Then maybe split subnets with a significant number of machines in there (use a bit of quantitative risk analysis to find an adequate number for your setup) into smaller ones to contain the impact of any (intentional or accidential) incident. If you can't get physical security straight, consider to use 802.1x. Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From me at benedikt-stockebrand.de Tue Jun 1 15:56:33 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 13:56:33 +0000 Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <20100531134055.GV88261@ronin.4ever.de> (Elmar K. Bins's message of "Mon, 31 May 2010 15:40:55 +0200") References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> Message-ID: Hi Elmar and list, "Elmar K. Bins" writes: > It gets more interesting if you try to really help your users with > an anycast gateway address. How do you propagate this one, and not > the routers', with RAs? don't. What you do is that you enable router advertisements on both routers (and make sure they advertise the same prefixes). If you want, you can fiddle with their priority along the way. Then you simply leave the rest to Neighbor Unreachability Detection (NUD). The hosts will maintain a list of default routers and switch between them as soon as NUD indicates that the one used has become unavailable. Simple implementations maintain a single "active" default router for all traffic, but the specs also allow implementations to maintain individual first-hop routers per destination. NUD ensures that a dead router is detected at an average 30s, plusminus 15s to avoid synchronization effects. RFC 4861 has all the details. In the end this gives you a failover in at worst 45s plus whatever a new round of ND takes. Not good enough for VoIP, but fast enough for TCP and still much faster than switching over manually. And all that at minimal complexity. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From mohacsi at niif.hu Tue Jun 1 16:03:02 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 1 Jun 2010 16:03:02 +0200 (CEST) Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <81D49719B798A4429C3958475FCDF2F362117C7BC6@AMS2PMS4001.upcit.ds.upc.biz> References: , <81D49719B798A4429C3958475FCDF2F362117C7BC6@AMS2PMS4001.upcit.ds.upc.biz> Message-ID: On Mon, 31 May 2010, Tosolini, Luca wrote: > an interesting proposal is to convey the default-router in DHCP only; > thus making RA less of a requirement: > > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-03 Maybe, except informing clients to use DHCPv6 ;-) > > Luca. > ________________________________________ > From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of David Freedman [david.freedman at uk.clara.net] > Sent: Monday, May 31, 2010 3:58 PM > To: Rickman, Phil; Nick Hilliard; Benedikt Stockebrand > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: So why is "IPv4 with longer addresses" a problem anyway? > >> one final point. >> I am curious how you wish to dynamic assign 2,000 clients, for an examples, >> gateways if DHCPv6 does not support it? > > Yes, I think the point here is "Make DHCPv6 support it" , folk should have > the choice to use the lightweight, insecure RA or not. > > You keep mentioning "suppression" with regards to RA and confusing it with > some form of security, I think Nick is alluding to the ability of parties to > inject rogue RA into a network and for it to be accepted, one possible > solution to this is > which has yet to > be implemented in mainstream equipment. > > Dave. > > > > From michael.dillon at bt.com Tue Jun 1 16:13:05 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Jun 2010 15:13:05 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: References:

<4C0189A0.4030509@netability.ie><4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> Message-ID: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> > don't. What you do is that you enable router advertisements on both > routers (and make sure they advertise the same prefixes). If you > want, you can fiddle with their priority along the way. > > Then you simply leave the rest to Neighbor Unreachability Detection It seems to me that all of the good bits from this discussion are the kind of thing that belongs on an IPv6 cookbook site. I don't know if there is already such a site, but if not, I suppose that ARIN's http://www.getipv6.info wiki would be a good place to put it. Then, instead of wading through arguments filled with red herrings and appeals to authority, people could just read a simple cookbook article on "Anycast gateway addresses" or "Configuring RA for use with DHCPV6". If such a site existed, then it might also be useful to end threads that drag on by asking people to go there and edit the recipes to make them clearer or whatever. --Michael Dillon From ipv6-ops at c0mplx.org Tue Jun 1 16:28:32 2010 From: ipv6-ops at c0mplx.org (Kurt Jaeger) Date: Tue, 1 Jun 2010 16:28:32 +0200 Subject: IPv6 fast reroute ? In-Reply-To: References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> Message-ID: <20100601142832.GG20255@home.opsec.eu> Hi! Benedikt wrote: > In the end this gives you a failover in at worst 45s plus whatever a > new round of ND takes. Not good enough for VoIP, but fast enough for > TCP and still much faster than switching over manually. And all that > at minimal complexity. This leads me to the next question: There's the IP fast reroute crowd, with their goal of 50ms switchover, like they had it in SDH. Look eg at: http://www.faqs.org/rfcs/rfc5286.html How will this be done in IPv6 ? -- pi at opsec.eu +49 171 3101372 10 years to go ! From mtinka at globaltransit.net Tue Jun 1 16:29:01 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 1 Jun 2010 22:29:01 +0800 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> References:

<28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <201006012229.01958.mtinka@globaltransit.net> On Tuesday 01 June 2010 10:13:05 pm michael.dillon at bt.com wrote: > If such a site existed, then it might also be useful to > end threads that drag on by asking people to go there > and edit the recipes to make them clearer or whatever. I support this effort because this is a real problem, today (and a real shame that we haven't reached any decent "operational" consensus). Existing LAN administrators will need all the information they can get if they start deploying IPv6 in a LAN environment before we work out the SLAAC vs. DHCPv6 issues. And the more "updated" information they can source in a single (or multiple) location(s), the better off they will be. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100601/27804231/attachment.bin From me at benedikt-stockebrand.de Tue Jun 1 16:36:44 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 14:36:44 +0000 Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C03D36A.2050903@foobar.org> (Nick Hilliard's message of "Mon, 31 May 2010 16:19:06 +0100") References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <4C03D36A.2050903@foobar.org> Message-ID: Hi once more, Nick Hilliard writes: > RFC 2461, section 6.3.4: just for completeness sake: That one's been obsoleted by RFC 4861 since September 2007. > "the receipt of a Router Advertisement MUST NOT invalidate all information > received in a previous advertisement or from another source. However, when > received information for a specific parameter (e.g., Link MTU) or option > (e.g., Lifetime on a specific Prefix) differs from information received > earlier, and the parameter/option can only have one value, the most > recently-received information is considered authoritative." > > ... and the rest of section 6.3.4, which provides the mechanism for RA > Default Router List timeout. > > Please read this section carefully. You are simply not guaranteed quick > failover when using RA. Yes, you can tune things down, but it's never > going to be anything like a router failover protocol. The timeout you are referring to determines how long a router is kept in the list of default routers on a host, not for how long it is actually used. The timeout determining which router is actually used is the NUD timeout at 30s plusminus 15s. > I'd be happy to retract a statement like that if you can provide a > reference. In <4C03BADF.3080902 at foobar.org> you write: ] - loss of service measured in (by default) minutes in the case of router ] failure Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From me at benedikt-stockebrand.de Tue Jun 1 16:39:42 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 14:39:42 +0000 Subject: Mysterious missing DHCPv6 feature, was Re: How does one obtain an IPv6 DNS server when VPNing to an ASA? In-Reply-To: <874ohpns2h.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Sun, 30 May 2010 20:49:10 +0200") References: <20100517.084430.78711679.sthaug@nethelp.no> <20100518075150.404fd6a6@opy.nosense.org> <20100518.073644.23028119.he@uninett.no> <874ohpns2h.fsf@mid.deneb.enyo.de> Message-ID: Hi Florian and list, Florian Weimer writes: > * Benedikt Stockebrand: > >> I disagree here. From what I've seen so far the key problem with >> regard to IPv6 is that a lot of people try to make IPv6 an "IPv4 with >> larger addresses", preserving all the workarounds they have come to >> get used to. "We've always used DHCP", "I want my NAT back", "I've >> always written IP addresses in decimal", "There can't be multiple >> default routes in a routing table" and so on. > > On the other hand, increased familiarity helps to cut down training > and documentation costs, and generally makes things easier to run. true, but you have to find an individual balance between those costs and actually improving things. We have kept a number of things untouched when moving from IPv4 to IPv6, but they largely go unnoticed exactly because they haven't changed. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From michael.dillon at bt.com Tue Jun 1 16:42:24 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 1 Jun 2010 15:42:24 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <201006012229.01958.mtinka@globaltransit.net> References:

<28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <201006012229.01958.mtinka@globaltransit.net> Message-ID: <28E139F46D45AF49A31950F88C4974580637EE58@E03MVZ2-UKDY.domain1.systemhost.net> > > If such a site existed, then it might also be useful to end threads > > that drag on by asking people to go there and edit the recipes to > > make them clearer or whatever. > > I support this effort because this is a real problem, today (and a real > shame that we haven't reached any decent "operational" consensus). Actually, I think we have reached an operational consensus. There is no right answer that suits all situations, just a number of best practices that you have to choose from depending on your network situation. And before designing a new network, you should review the possibilities and make sure that you don't force yourself down a complex route, if you don't otherwise need to. Even in an ISP network, there is no magic bullet. The office LAN might need something different from the DSL customer network and different again for the management LANs. It might be as simple as choosing a different timer value, but it is always good to have a solution spelled out in detail along with the reasons for doing it that way. > And the more "updated" information they can source in a single (or > multiple) location(s), the better off they will be. Yes. And since ARIN is not going away anytime soon, their wiki seems like a good place to put it. In fact, maybe we should urge RIPE and the other RIRs to also adopt the ARIN wiki as their preferred site for IPv6 educational materials. All of the RIRs do a certain amount of education and outreach. --Michael Dillon From me at benedikt-stockebrand.de Tue Jun 1 17:01:16 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 15:01:16 +0000 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses" a problem anyway?) In-Reply-To: <201006010047.26322.mtinka@globaltransit.net> (Mark Tinka's message of "Tue, 1 Jun 2010 00:47:19 +0800") References: <4C0189A0.4030509@netability.ie> <201006010047.26322.mtinka@globaltransit.net> Message-ID: Hi Mark and list, Mark Tinka writes: > I probably wouldn't go around saying RIP is better to deploy > than a link-state routing protocol (despite the "balance > between easy-to-handle simplicity and ultimate performance > complexity" quote), Depends. As far as deployment goes: If you use e.g. a BSD or Solaris you get a lightweight RIP daemon as part of the base system, so with these systems deployment is actually a bit easier---you just turn it on. On other systems the only difference may be that people tend to copy configurations without changing the router ID. >From a security/reliability point of view, both shouldn't be used in networks where untrustworthy nodes are connected, so they don't differ much in that respect---whenever you want to use dynamic routing, you better get your network topology sorted out beforehand. Beyond that it's where the difference comes into play: It's not so much the deployment but troubleshooting. From experience I know that I can train anybody with basic knowledge of IP within about two hours (including hands-on training) how RIP{v2,ng} works, what the packets they see in a packet sniffer mean and how to analyze and fix problems. With OSPFv{2,3} you can barely explain how it works during that time. To make people really comfortable with OSPF it takes a few days training, on-the-job time to gather experience, and periodic training. If people only touch dynamic routing protocols maybe once or twice a year, RIP gives them much more of a chance than OSPF when things go wrong. So beyond "normal" data center or medium-to-large enterprise networks, but in environments without specialized network admins, small enough network diameter and modest failover time requirements, RIP does have its niche. (And yes, I've seen people overextending themselves with OSPF...) > but I gather that isn't the gist of this thread. See Subject header:-) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From mtinka at globaltransit.net Tue Jun 1 17:09:44 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 1 Jun 2010 23:09:44 +0800 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C4974580637EE58@E03MVZ2-UKDY.domain1.systemhost.net> References: <201006012229.01958.mtinka@globaltransit.net> <28E139F46D45AF49A31950F88C4974580637EE58@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <201006012309.49267.mtinka@globaltransit.net> On Tuesday 01 June 2010 10:42:24 pm michael.dillon at bt.com wrote: > Actually, I think we have reached an operational > consensus. There is no right answer that suits all > situations, just a number of best practices that you > have to choose from depending on your network situation. Where I was coming from is; I'd like to review this when: - RFC 5006 gets widely accepted (or not). - DHCPv6 supports default route + prefix lengths (or not). - SLAAC gets widely accepted (or not). - Mac OS X supports DHCPv6 (or not). - RA Guard is widely implemented. - DHCPv6 Snooping is widely implemented. - SeND gets widely accepted (or not). A lot of things on the Internet (and its operations) have no right or wrong answer, but if anything has come out from this thread, it's that we are very far from an optimal auto- configuration mechanism for the LAN, particularly for operators who need things to just work and could care less about what 'ipv6-ops' is ranting about on Tuesday. In the mean time, keeping these developments updated on the ARIN IPv6 wiki (and the respective wiki's of the other RIR's, as you rightly suggest) so we can all track overall progress, from development and deployment, is most welcome. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100601/bce229d0/attachment.bin From mtinka at globaltransit.net Tue Jun 1 17:34:46 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 1 Jun 2010 23:34:46 +0800 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses" a problem anyway?) In-Reply-To: References: <201006010047.26322.mtinka@globaltransit.net> Message-ID: <201006012334.51111.mtinka@globaltransit.net> On Tuesday 01 June 2010 11:01:16 pm Benedikt Stockebrand wrote: > As far as deployment goes: If you use e.g. a BSD or > Solaris you get a lightweight RIP daemon as part of the > base system, so with these systems deployment is > actually a bit easier---you just turn it on. Then install Quagga/Zebra and run OSPF or IS-IS. > So beyond "normal" data center or medium-to-large > enterprise networks, but in environments without > specialized network admins, small enough network > diameter and modest failover time requirements, RIP does > have its niche. I'm sorry, I just don't subscribe to the idea of teaching folk to use RIP in today's networks, despite the size of their business (I hold workshops myself, I know) - because this stuff sticks. The most I tend to say about RIP - don't use it! In addition to the "other way" we we tend to describe it. > (And yes, I've seen people overextending themselves with > OSPF...) So tell them to ignore all those knobs the industry has added to the spec. They don't need (m)any of them. If you're having problems stuffing enough useful information about link state routing protocols into your tutorials, I'd, respectfully, look at working on that instead. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100601/e6a2fdd8/attachment-0001.bin From juergen.becker at gmail.com Tue Jun 1 17:47:44 2010 From: juergen.becker at gmail.com (=?iso-8859-1?Q?J=FCrgen_Becker?=) Date: Tue, 1 Jun 2010 17:47:44 +0200 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses" a problem anyway?) In-Reply-To: <201006012334.51111.mtinka@globaltransit.net> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> Message-ID: On Jun 1, 2010, at 5:34 PM, Mark Tinka wrote: > On Tuesday 01 June 2010 11:01:16 pm Benedikt Stockebrand > wrote: > >> As far as deployment goes: If you use e.g. a BSD or >> Solaris you get a lightweight RIP daemon as part of the >> base system, so with these systems deployment is >> actually a bit easier---you just turn it on. > > Then install Quagga/Zebra and run OSPF or IS-IS. > >> So beyond "normal" data center or medium-to-large >> enterprise networks, but in environments without >> specialized network admins, small enough network >> diameter and modest failover time requirements, RIP does >> have its niche. > > I'm sorry, I just don't subscribe to the idea of teaching > folk to use RIP in today's networks, despite the size of > their business (I hold workshops myself, I know) - because > this stuff sticks. > > The most I tend to say about RIP - don't use it! In addition > to the "other way" we we tend to describe it. There is one simple reason why RIP is still used and why it most likely will be used in the future: RIP is cheaper then OSPF etc., because most hardware vendor consider it basic routing and include it for free. For advanced routing you have to buy licenses and/or more expensive hardware. > >> (And yes, I've seen people overextending themselves with >> OSPF...) > > So tell them to ignore all those knobs the industry has > added to the spec. They don't need (m)any of them. > > If you're having problems stuffing enough useful information > about link state routing protocols into your tutorials, I'd, > respectfully, look at working on that instead. > > Cheers, > > Mark. Regards, J?rgen From Sam.Wilson at ed.ac.uk Tue Jun 1 17:55:51 2010 From: Sam.Wilson at ed.ac.uk (Sam Wilson) Date: Tue, 1 Jun 2010 16:55:51 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> References:

<4C0189A0.4030509@netability.ie><4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> On 1 Jun 2010, at 15:13, wrote: >> don't. What you do is that you enable router advertisements on both >> routers (and make sure they advertise the same prefixes). If you >> want, you can fiddle with their priority along the way. >> >> Then you simply leave the rest to Neighbor Unreachability Detection > > It seems to me that all of the good bits from this discussion are > the kind of thing that belongs on an IPv6 cookbook site. ... I just have a sort of feeling that this sort of thing might have been done before. Perhaps some of these need updating? and see under 'Public Deliverables' It seems odd that I can't find a link to such a document on , but I may not be looking in the right place. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From wmaton at ryouko.imsb.nrc.ca Tue Jun 1 17:58:32 2010 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Tue, 1 Jun 2010 11:58:32 -0400 (EDT) Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> Message-ID: <4C053559.8020808@foobar.org> On 01/06/2010 14:56, Benedikt Stockebrand wrote: > destination. NUD ensures that a dead router is detected at an average > 30s, plusminus 15s to avoid synchronization effects. RFC 4861 has all > the details. It kills me to add further noise to this thread, but this is probably one of the base sources of contention. It seems that you're happy with 15-45 seconds as an operationally / commercially acceptable time period for loss of service in the event of gateway failure / failover. If you accept this level of service unavailability, then RA / NUD is quite adequate. I don't accept that this is an acceptable operational / commercial proposition for my customers. Therefore RA / NUD is not viable on the networks which I deal with. Good, we've cleared something up. Nick From gbonser at seven.com Tue Jun 1 18:50:54 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 1 Jun 2010 09:50:54 -0700 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses"a problem anyway?) In-Reply-To: <201006020011.03653.mtinka@globaltransit.net> References: <201006012334.51111.mtinka@globaltransit.net> <201006020011.03653.mtinka@globaltransit.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: > On Behalf Of Mark Tinka > Sent: Tuesday, June 01, 2010 9:11 AM > To: J?rgen Becker > Cc: Benedikt Stockebrand; ipv6-ops at lists.cluenet.de > Subject: Re: The use of RIPng (was: Re: So why is "IPv4 with longer > addresses"a problem anyway?) > > On Tuesday 01 June 2010 11:47:44 pm J?rgen Becker wrote: > > > There is one simple reason why RIP is still used and why it most > > likely will be used in the future: RIP is cheaper then OSPF etc., > > because most hardware vendor consider it basic routing and include > it > > for free. > > RFC 1812, final paragraph of section 7.2.1: > > "A router that implements any routing protocol (other than > static routes) MUST IMPLEMENT OSPF (see Section [7.2.2]). > A router MAY implement additional IGPs." > > Of course we all know that what the RFC's suggest and what happens on > the ground may be vastly apart but I'd be hard- pressed to find a > decent vendor out there that won't do OSPF in some way or form. Even > Cisco's 800 series routers will happily do OSPF, and you can pick those > up off E-Bay for a couple of bucks. > > If you need more horse-power from your router, chances are it supports > OSPF. > > > For > > advanced routing you have to buy licenses and/or more expensive > > hardware. > > FUD. > > What we're seeing now is vendors that "were" charging for > IPv6 since it was considered an "advanced feature". This included > OSPFv3 (more reason to use IS-IS). However, some vendors have now put a > US$0.00 cost on IPv6 and its related features, while the rest have > began dropping back as well. > What do you mean "were"? If you own Brocade/Foundry SuperX units and want to run v6 layer 3 you need to buy special blades AND pay a premium license fee. Any networks unlucky enough to have purchased any of that kit over the past few years are suddenly feeling this burning sensation on their seat if they are considering v6 migration. I use RIPng only for "next hop" information where I redistribute connected links from my external peering connections among my BGP routers. Internally we use OSPF. From me at benedikt-stockebrand.de Tue Jun 1 19:07:40 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 17:07:40 +0000 Subject: The use of RIPng In-Reply-To: <201006012334.51111.mtinka@globaltransit.net> (Mark Tinka's message of "Tue, 1 Jun 2010 23:34:46 +0800") References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> Message-ID: Hi Mark and list, Mark Tinka writes: > On Tuesday 01 June 2010 11:01:16 pm Benedikt Stockebrand > wrote: > >> As far as deployment goes: If you use e.g. a BSD or >> Solaris you get a lightweight RIP daemon as part of the >> base system, so with these systems deployment is >> actually a bit easier---you just turn it on. > > Then install Quagga/Zebra and run OSPF or IS-IS. that's a bit of a pain involved there. Additionally, it is recommended not to run it on a machine that does anything else, mostly because the init scripts (or equivalent) and Quagga tend to interfere with each other. > I'm sorry, I just don't subscribe to the idea of teaching > folk to use RIP in today's networks, despite the size of > their business (I hold workshops myself, I know) - because > this stuff sticks. Valid point. And I agree that moving from RIP to OSPF is a rather gory business, especially if you delay the move until RIP becomes a problem rather than a solution. However, there are businesses that rarely grow to the point that they have a full-time sysadmin around, and the choices there are either static routes (which are fascinatingly prone to typos) or RIP to maintain routing tables automatically. At least here in Germany we have lots of small but IT-heavy businesses, like accounting/tax advisor shops, engineering offices and such. They usually have an external contractor to take care of everything related to computers, from buying the right type of toner cartridge to setting up and maintaining their networks (of 5--25 hosts, 2--3 routers). To them, RIP makes life easier while OSPF is an undefused bomb. > The most I tend to say about RIP - don't use it! In addition > to the "other way" we we tend to describe it. [Parse Error?] >> (And yes, I've seen people overextending themselves with >> OSPF...) > > So tell them to ignore all those knobs the industry has > added to the spec. They don't need (m)any of them. My point is on troubleshooting, not configuring things. You don't have to use areas (beyond backbone) or whatever, but it still takes quite some background to understand that the LSAs you see are wrong, figure out what they mean, why and how they mess up your routing, how to track down their source and how to get rid of them. > If you're having problems stuffing enough useful information > about link state routing protocols into your tutorials, I'd, > respectfully, look at working on that instead. Since I mostly do IPv6 tutorials I normally run into only one of two situations: - If I have participants who know about OSPFv2, then telling them about the differences between v2 and v3 is no big deal; it's mostly "router IDs are still 32 bits, so you can't just use an IPv6 address there, the authentication mechanisms have gone in favour of IPsec" and similar. - If I have participants who don't know about OSPFv2, usually because they are less routing centric, then I won't spend time on teaching elementary OSPF because there are plenty topics more relevant to them. Doing a three day course on OSPF alone is fine, but stuffing OSPF into a three day course on IPv6 is just running people into trouble. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From ted.m at ipinc.net Tue Jun 1 19:11:28 2010 From: ted.m at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Jun 2010 10:11:28 -0700 Subject: The use of RIPng In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> References: <201006012334.51111.mtinka@globaltransit.net> <201006020011.03653.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> Message-ID: <4C053F40.50704@ipinc.net> On 6/1/2010 9:50 AM, George Bonser wrote: > > >> -----Original Message----- From: On Behalf Of Mark Tinka Sent: >> Tuesday, June 01, 2010 9:11 AM To: J?rgen Becker Cc: Benedikt >> Stockebrand; ipv6-ops at lists.cluenet.de Subject: Re: The use of >> RIPng (was: Re: So why is "IPv4 with longer addresses"a problem >> anyway?) >> >> On Tuesday 01 June 2010 11:47:44 pm J?rgen Becker wrote: >> >>> There is one simple reason why RIP is still used and why it >>> most likely will be used in the future: RIP is cheaper then OSPF >>> etc., because most hardware vendor consider it basic routing and >>> include >> it >>> for free. >> >> RFC 1812, final paragraph of section 7.2.1: >> >> "A router that implements any routing protocol (other than static >> routes) MUST IMPLEMENT OSPF (see Section [7.2.2]). A router MAY >> implement additional IGPs." >> >> Of course we all know that what the RFC's suggest and what happens >> on the ground may be vastly apart but I'd be hard- pressed to find >> a decent vendor out there that won't do OSPF in some way or form. >> Even Cisco's 800 series routers will happily do OSPF, and you can >> pick those up off E-Bay for a couple of bucks. >> >> If you need more horse-power from your router, chances are it >> supports OSPF. >> >>> For advanced routing you have to buy licenses and/or more >>> expensive hardware. >> >> FUD. >> >> What we're seeing now is vendors that "were" charging for IPv6 >> since it was considered an "advanced feature". This included OSPFv3 >> (more reason to use IS-IS). However, some vendors have now put a >> US$0.00 cost on IPv6 and its related features, while the rest have >> began dropping back as well. >> > > What do you mean "were"? If you own Brocade/Foundry SuperX units and > want to run v6 layer 3 you need to buy special blades AND pay a > premium license fee. Any networks unlucky enough to have purchased > any of that kit over the past few years are suddenly feeling this > burning sensation on their seat if they are considering v6 migration. Then they were stupid. You can take that with a grain of salt because we don't own any of that stuff, but IPv6 has been out for what, the last decade? And your just now getting around to including it as a requirement in your RFPs? Those orgs are just paying the deserved "stupid tax" IMHO. Feel free to sling arrows, I'll listen to the sputtering justifications, but the fact remains you saved money by dropping what should have been a mandated spec from your RFP 5 years ago when you bought the stuff, and now your whining that they want more money. Uh huh. > I use RIPng only for "next hop" information where I redistribute > connected links from my external peering connections among my BGP > routers. Internally we use OSPF. > Yeah, well as an ISP, we have a few elderly 56K total control chassis that only speak RIP also so we have run it too - but I certainly don't run around -boasting- about it! Ted From ted.m at ipinc.net Tue Jun 1 19:14:09 2010 From: ted.m at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Jun 2010 10:14:09 -0700 Subject: The use of RIPng In-Reply-To: References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> Message-ID: <4C053FE1.6070307@ipinc.net> On 6/1/2010 10:07 AM, Benedikt Stockebrand wrote: > Hi Mark and list, > > Mark Tinka writes: > >> On Tuesday 01 June 2010 11:01:16 pm Benedikt Stockebrand >> wrote: >> >>> As far as deployment goes: If you use e.g. a BSD or >>> Solaris you get a lightweight RIP daemon as part of the >>> base system, so with these systems deployment is >>> actually a bit easier---you just turn it on. >> >> Then install Quagga/Zebra and run OSPF or IS-IS. > > that's a bit of a pain involved there. Additionally, it is > recommended not to run it on a machine that does anything else, mostly > because the init scripts (or equivalent) and Quagga tend to interfere > with each other. > >> I'm sorry, I just don't subscribe to the idea of teaching >> folk to use RIP in today's networks, despite the size of >> their business (I hold workshops myself, I know) - because >> this stuff sticks. > > Valid point. And I agree that moving from RIP to OSPF is a rather > gory business, especially if you delay the move until RIP becomes a > problem rather than a solution. > > However, there are businesses that rarely grow to the point that they > have a full-time sysadmin around, and the choices there are either > static routes (which are fascinatingly prone to typos) or RIP to > maintain routing tables automatically. > > At least here in Germany we have lots of small but IT-heavy > businesses, like accounting/tax advisor shops, engineering offices and > such. They usually have an external contractor to take care of > everything related to computers, from buying the right type of toner > cartridge to setting up and maintaining their networks (of 5--25 > hosts, 2--3 routers). To them, RIP makes life easier while OSPF is an > undefused bomb. > Why do you use 2-3 routers with a grand total of 25 hosts?!? Ted >> The most I tend to say about RIP - don't use it! In addition >> to the "other way" we we tend to describe it. > > [Parse Error?] > >>> (And yes, I've seen people overextending themselves with >>> OSPF...) >> >> So tell them to ignore all those knobs the industry has >> added to the spec. They don't need (m)any of them. > > My point is on troubleshooting, not configuring things. You don't > have to use areas (beyond backbone) or whatever, but it still takes > quite some background to understand that the LSAs you see are wrong, > figure out what they mean, why and how they mess up your routing, how > to track down their source and how to get rid of them. > >> If you're having problems stuffing enough useful information >> about link state routing protocols into your tutorials, I'd, >> respectfully, look at working on that instead. > > Since I mostly do IPv6 tutorials I normally run into only one of two > situations: > > - If I have participants who know about OSPFv2, then telling them about > the differences between v2 and v3 is no big deal; it's mostly > "router IDs are still 32 bits, so you can't just use an IPv6 address > there, the authentication mechanisms have gone in favour of IPsec" > and similar. > > - If I have participants who don't know about OSPFv2, usually because > they are less routing centric, then I won't spend time on teaching > elementary OSPF because there are plenty topics more relevant to them. > > Doing a three day course on OSPF alone is fine, but stuffing OSPF into > a three day course on IPv6 is just running people into trouble. > > > Cheers, > > Benedikt > From tedm at ipinc.net Tue Jun 1 19:25:10 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Jun 2010 10:25:10 -0700 Subject: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C053559.8020808@foobar.org> References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> <4C053559.8020808@foobar.org> Message-ID: <4C054276.5080700@ipinc.net> On 6/1/2010 9:29 AM, Nick Hilliard wrote: > On 01/06/2010 14:56, Benedikt Stockebrand wrote: >> destination. NUD ensures that a dead router is detected at an average >> 30s, plusminus 15s to avoid synchronization effects. RFC 4861 has all >> the details. > > It kills me to add further noise to this thread, but this is probably one > of the base sources of contention. It seems that you're happy with 15-45 > seconds as an operationally / commercially acceptable time period for loss > of service in the event of gateway failure / failover. If you accept this > level of service unavailability, then RA / NUD is quite adequate. > > I don't accept that this is an acceptable operational / commercial > proposition for my customers. Therefore RA / NUD is not viable on the > networks which I deal with. > I don't accept that routers routinely dying is an acceptable operational / commercial proposition for our customers. Just for grins I just checked and the last SCHEDULED reboot of our own largest and most complex BGP-running router was 50 weeks ago. The last UNSCHEDULED reboot was something like 5 YEARS ago. > Good, we've cleared something up. > Obviously. Clearly your standards for acceptable router hardware are far, far lower than a lot of peoples. I would guess that's why your so concerned with a 30 second slew time. Ted From nick at foobar.org Tue Jun 1 19:29:51 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Jun 2010 18:29:51 +0100 Subject: The use of RIPng In-Reply-To: References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> Message-ID: <4C05438F.6000200@foobar.org> On 01/06/2010 18:07, Benedikt Stockebrand wrote: > that's a bit of a pain involved there. Additionally, it is > recommended not to run it on a machine that does anything else, mostly > because the init scripts (or equivalent) and Quagga tend to interfere > with each other. lolwut?!??! >> I'm sorry, I just don't subscribe to the idea of teaching >> folk to use RIP in today's networks, despite the size of >> their business (I hold workshops myself, I know) - because >> this stuff sticks. > > Valid point. And I agree that moving from RIP to OSPF is a rather > gory business lolwut^2? > hosts, 2--3 routers). To them, RIP makes life easier while OSPF is an > undefused bomb. huh? > Doing a three day course on OSPF alone is fine, but stuffing OSPF into > a three day course on IPv6 is just running people into trouble. I have found that I don't need to understand the finer points of internal combustion mechanics, spark plug design and exhaust muffling technology in order to drive down to the shop to buy a loaf of bread. Ok, let me spell it out. If you're running a routing protocol on your end-user workstations, you're probably doing it wrong. If you're running a routing protocol on your routers, then it goes like this: RIP configuration: router rip version 2 redistribute connected redistribute static default-information originate passive-interface FastEthernetX/Y or OSPF: router ospf 1 redistribute connected subnets redistribute static subnets default-information originate network a.b.c.0 0.0.0.255 area 0 passive-interface FastEthernetX/Y The configuration parameters are similarly difficult for RIPng and OSPFv3, or if you use Quagga instead of IOS, or JunOS instead of Quagga. I'm at a loss to see why one is much more difficult than the other. Can you explain? This thread is becoming too bizarre for words, but for some reason, I can't seem to pull myself away from it. Maybe don't explain after all. Nick From me at benedikt-stockebrand.de Tue Jun 1 19:53:38 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 17:53:38 +0000 Subject: The use of RIPng In-Reply-To: <4C053FE1.6070307@ipinc.net> (Ted Mittelstaedt's message of "Tue, 01 Jun 2010 10:14:09 -0700") References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C053FE1.6070307@ipinc.net> Message-ID: Ted Mittelstaedt writes: > Why do you use 2-3 routers with a grand total of 25 hosts?!? to separate accounting from human resources from R&D from internal servers from externally visible servers from guest (W)LANs. And sometimes more. For starters, make it one dedicated router for Internet connectivity (in some cases provided and managed by their ISP), one for the "business" subnets and possibly yet another one for R&D. These sites aren't data centers, but that doesn't mean reliability and/or security isn't relevant to them. Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From bmanning at vacation.karoshi.com Tue Jun 1 20:08:01 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Jun 2010 18:08:01 +0000 Subject: The use of RIPng In-Reply-To: <4C05438F.6000200@foobar.org> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> Message-ID: <20100601180801.GD4379@vacation.karoshi.com.> Morning Nick.... On Tue, Jun 01, 2010 at 06:29:51PM +0100, Nick Hilliard wrote: > > Ok, let me spell it out. If you're running a routing protocol on your > end-user workstations, you're probably doing it wrong. If you're running a > routing protocol on your routers, then it goes like this: if you run a routing protocol on an end-station - you've turned it into a router... (much like what happens in some anycast clusters for node failover) > I'm at a loss to see why one is much more difficult than the other. Can > you explain? your looking at the configuration statements. what is the cpu/memory footprint for the two? > This thread is becoming too bizarre for words, but for some reason, I can't > seem to pull myself away from it. Maybe don't explain after all. trainwreck... can't look away! > > Nick From nick at foobar.org Tue Jun 1 20:18:50 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Jun 2010 19:18:50 +0100 Subject: The use of RIPng In-Reply-To: <20100601180801.GD4379@vacation.karoshi.com.> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> Message-ID: <4C054F0A.7090306@foobar.org> On 01/06/2010 19:08, bmanning at vacation.karoshi.com wrote: > your looking at the configuration statements. what is the cpu/memory > footprint for the two? for the scenario presented - 25 workstations (irrelevant number), 2-3 routers and a couple of LANs? I'd say approximately epsilon. >> This thread is becoming too bizarre for words, but for some reason, I can't >> seem to pull myself away from it. Maybe don't explain after all. > > trainwreck... can't look away! Dammit, I did it again! Nick From tedm at ipinc.net Tue Jun 1 20:19:07 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 01 Jun 2010 11:19:07 -0700 Subject: The use of RIPng In-Reply-To: References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C053FE1.6070307@ipinc.net> Message-ID: <4C054F1B.4060603@ipinc.net> On 6/1/2010 10:53 AM, Benedikt Stockebrand wrote: > Ted Mittelstaedt writes: > >> Why do you use 2-3 routers with a grand total of 25 hosts?!? > > to separate accounting from human resources from R&D from internal > servers from externally visible servers from guest (W)LANs. > > And sometimes more. > > For starters, make it one dedicated router for Internet connectivity > (in some cases provided and managed by their ISP), one for the > "business" subnets and possibly yet another one for R&D. > > These sites aren't data centers, but that doesn't mean reliability > and/or security isn't relevant to them. > For networks like that we use 1 decent Internet router (we -always- make any ISP that mandates an ISP-supplied CPE, set it up as a bridge or router providing a subnet) and 1 decent managed layer 3 gigabit switch - Netgear makes some really nice SOHO 24 & 48 port fully managed ones that aren't that expensive - if we have to create the same kind of network. Or, just use a flat network and MAC address filtering to prevent the different departments from seeing servers and such that they are not supposed to get to and a layer 2 switch. With fewer hardware boxes there's much less to go wrong. But rarely do we ever see that kind of need in a SOHO. Ted From jeffm at iglou.com Tue Jun 1 20:36:45 2010 From: jeffm at iglou.com (Jeff McAdams) Date: Tue, 01 Jun 2010 14:36:45 -0400 Subject: The use of RIPng In-Reply-To: <20100601180801.GD4379@vacation.karoshi.com.> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> Message-ID: <4C05533D.8000000@iglou.com> On 6/1/10 2:08 PM, bmanning at vacation.karoshi.com wrote: > On Tue, Jun 01, 2010 at 06:29:51PM +0100, Nick Hilliard wrote: >> Ok, let me spell it out. If you're running a routing protocol on your >> end-user workstations, you're probably doing it wrong. If you're running a >> routing protocol on your routers, then it goes like this: > if you run a routing protocol on an end-station - you've turned it into > a router... (much like what happens in some anycast clusters for node > failover) Uhm, no. If you run a routing protocol on an end-station - you've given that end-station a mechanism that it might learn what the network topology is in the overall network, beyond just its default next-hop. You *might* let it be a router, depending on how that routing protocol is set up and other configuration issues within the OS. ( echo 0 > /proc/sys/net/ipv4/ip_forward pretty much makes a Linux box *not* be an IPv4 router, regardless of what software is running on it (yeah, yeah, unless you start getting into user-space routing and such)) You might also give that end-station the ability to inject routes into that network topology, which could, indeed, cause problems. So, there are use cases where it could be beneficial for end-stations to have knowledge of the overall network topology by running a routing protocol. There are also, almost certainly drawbacks. I think it is possible for reasonable people to disagree (including based on their individual scenarios for use-case) on which is bigger, the benefits or the drawbacks. -- Jeff McAdams jeffm at iglou.com From bmanning at vacation.karoshi.com Tue Jun 1 20:42:30 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Jun 2010 18:42:30 +0000 Subject: The use of RIPng In-Reply-To: <4C05533D.8000000@iglou.com> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> <4C05533D.8000000@iglou.com> Message-ID: <20100601184230.GE4379@vacation.karoshi.com.> On Tue, Jun 01, 2010 at 02:36:45PM -0400, Jeff McAdams wrote: > On 6/1/10 2:08 PM, bmanning at vacation.karoshi.com wrote: > >On Tue, Jun 01, 2010 at 06:29:51PM +0100, Nick Hilliard wrote: > > >>Ok, let me spell it out. If you're running a routing protocol on your > >>end-user workstations, you're probably doing it wrong. If you're running > >>a > >>routing protocol on your routers, then it goes like this: > > > if you run a routing protocol on an end-station - you've turned it > > into > > a router... (much like what happens in some anycast clusters for > > node > > failover) > > Uhm, no. here we must part ways... sort of by definition, if there is a routing protocol running, its a router - granted (as you point out below) it may not forward packets (dependent on configuration options) but -understanding- the network topology past next-hop is a key attribute of routing. so other than defintional terms, i'm almost with you. :) --bill > > If you run a routing protocol on an end-station - you've given that > end-station a mechanism that it might learn what the network topology is > in the overall network, beyond just its default next-hop. You *might* > let it be a router, depending on how that routing protocol is set up and > other configuration issues within the OS. ( echo 0 > > /proc/sys/net/ipv4/ip_forward pretty much makes a Linux box *not* be > an IPv4 router, regardless of what software is running on it (yeah, > yeah, unless you start getting into user-space routing and such)) You > might also give that end-station the ability to inject routes into that > network topology, which could, indeed, cause problems. > > So, there are use cases where it could be beneficial for end-stations to > have knowledge of the overall network topology by running a routing > protocol. There are also, almost certainly drawbacks. I think it is > possible for reasonable people to disagree (including based on their > individual scenarios for use-case) on which is bigger, the benefits or > the drawbacks. > > -- > Jeff McAdams > jeffm at iglou.com From jeffm at iglou.com Tue Jun 1 21:58:03 2010 From: jeffm at iglou.com (Jeff McAdams) Date: Tue, 01 Jun 2010 15:58:03 -0400 Subject: The use of RIPng In-Reply-To: <20100601184230.GE4379@vacation.karoshi.com.> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> <4C05533D.8000000@iglou.com> <20100601184230.GE4379@vacation.karoshi.com.> Message-ID: <4C05664B.3050503@iglou.com> On 6/1/10 2:42 PM, bmanning at vacation.karoshi.com wrote: > here we must part ways... sort of by definition, if there is > a routing protocol running, its a router - granted (as you > point out below) it may not forward packets (dependent on > configuration options) but -understanding- the network topology > past next-hop is a key attribute of routing. > so other than defintional terms, i'm almost with you. :) Huh, I tend to think of a router as a system that, you know, routes. Call me crazy. That may, or may not, involve a routing protocol. And a routing protocol, which is used to share topology and routing information, need not be used by a system to make decisions about routing. Sure, that's by far and away the most common use of routing protocol information, but I think going from the premise of a system running a routing protocol software to that system necessarily being a router is fraught with semantic peril. There are any of a number of reasons that a system could run routing protocol software and never forward a single packet, nor even have the capability of forwarding a packet. I think calling those systems routers will lead to no end of confusion and you'll please pardon me if I think your definition of "router" leaves more than a little bit to be desired. > --bill > >> >> If you run a routing protocol on an end-station - you've given that >> end-station a mechanism that it might learn what the network topology is >> in the overall network, beyond just its default next-hop. You *might* >> let it be a router, depending on how that routing protocol is set up and >> other configuration issues within the OS. ( echo 0> >> /proc/sys/net/ipv4/ip_forward pretty much makes a Linux box *not* be >> an IPv4 router, regardless of what software is running on it (yeah, >> yeah, unless you start getting into user-space routing and such)) You >> might also give that end-station the ability to inject routes into that >> network topology, which could, indeed, cause problems. >> >> So, there are use cases where it could be beneficial for end-stations to >> have knowledge of the overall network topology by running a routing >> protocol. There are also, almost certainly drawbacks. I think it is >> possible for reasonable people to disagree (including based on their >> individual scenarios for use-case) on which is bigger, the benefits or >> the drawbacks. >> >> -- >> Jeff McAdams >> jeffm at iglou.com -- Jeff McAdams jeffm at iglou.com From gbonser at seven.com Tue Jun 1 22:34:38 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 1 Jun 2010 13:34:38 -0700 Subject: The use of RIPng In-Reply-To: <4C05664B.3050503@iglou.com> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> <4C05533D.8000000@iglou.com><20100601184230.GE4379@vacation.karoshi.com.> <4C05664B.3050503@iglou.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA4873@RWC-EX1.corp.seven.com> > > Huh, I tend to think of a router as a system that, you know, routes. > Call me crazy. That may, or may not, involve a routing protocol. And > a > routing protocol, which is used to share topology and routing > information, need not be used by a system to make decisions about > routing. Sure, that's by far and away the most common use of routing > protocol information, but I think going from the premise of a system > running a routing protocol software to that system necessarily being a > router is fraught with semantic peril. > > There are any of a number of reasons that a system could run routing > protocol software and never forward a single packet, nor even have the > capability of forwarding a packet. I think calling those systems > routers will lead to no end of confusion and you'll please pardon me if > I think your definition of "router" leaves more than a little bit to be > desired. > > > --bill Actually, having systems run OSPF is the Solaris standard for interface failover these days (OSPF-MP) which uses Quagga. The end system has two links, each are on different layer 3 subnets. A host announces its loopback IPs over both links. When an interface or upstream switch or router fails, the network uses the remaining path. Using ECMP, it also creates a reasonable alternative to Spanning Tree in the net where you push layer 3 all the way down to the hosts. Running routing protocols out to the host is becoming more common these days. From me at benedikt-stockebrand.de Tue Jun 1 22:56:46 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 20:56:46 +0000 Subject: The use of RIPng In-Reply-To: <4C05438F.6000200@foobar.org> (Nick Hilliard's message of "Tue, 01 Jun 2010 18:29:51 +0100") References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> Message-ID: Nick Hilliard writes: > On 01/06/2010 18:07, Benedikt Stockebrand wrote: >> that's a bit of a pain involved there. Additionally, it is >> recommended not to run it on a machine that does anything else, mostly >> because the init scripts (or equivalent) and Quagga tend to interfere >> with each other. > > lolwut?!??! With the vast majority of network services available on common Unixes, the default configuration listens on all interfaces, i.e. it does a listen on 0.0.0.0 or ::. In that case it doesn't really matter in which sequence services get started, and for that reason the ordering constraints for services are frequently somewhat incomplete. Now if you configure a service to listen only on a specific address, then the starting order *does* matter, because if the address from the service configuration isn't configured on an interface when the service attempts to start, the service won't come up. This is particularly painful if it happens to the sshd, which on the other hand should be started as soon as possible to give an admin a chance to fix problems remotely even if the boot sequence doesn't finish. With parallel startup mechanisms like upstart or SMF the situation gets even worse because the startup order becomes nondeterministic. >>> I'm sorry, I just don't subscribe to the idea of teaching >>> folk to use RIP in today's networks, despite the size of >>> their business (I hold workshops myself, I know) - because >>> this stuff sticks. >> >> Valid point. And I agree that moving from RIP to OSPF is a rather >> gory business > > lolwut^2? If you wait for the move from RIP to OSPF until you reach the limitations of RIP, most notably network diameter, then you have quite likely reached a point where you have to use both RIP and OSPF simultaneously for the migration phase. Redistributing routes between different routing protocols in real-world environments tends to be messy, especially if you have to manipulate the metrics, and is one of those things you don't want to do only occasionally. Having little experience with OSPF yet doesn't make things easier, either. Doing multi-protocol routing is something you want to leave to people who do very little else, so that's usually only an option if you are either an ISP/NSP, a large data center or possibly a large enterprise. >> hosts, 2--3 routers). To them, RIP makes life easier while OSPF is an >> undefused bomb. > > huh? You send one or two of your generic system/network administrators to a three to five day OSPF training. Afterwards they manage to deploy OSPF in your network. Half a year later, and with absolutely no reason to fiddle around with OSPF since the network works, something breaks. Not having touched any OSPF for months, they have forgotten much of what they've learned and the only chance they have to find and fix the problem is to dig out those old training manuscripts, trying to recall what the relevant details of have learned. All this under significant time pressure. Since you are so keen on not having a 45s loss of service, this should be a particularly alarming scenario to you. Or maybe you can find out in 45s what a type 5 LSA with OSPFv3 means? >> Doing a three day course on OSPF alone is fine, but stuffing OSPF into >> a three day course on IPv6 is just running people into trouble. > > I have found that I don't need to understand the finer points of internal > combustion mechanics, spark plug design and exhaust muffling technology in > order to drive down to the shop to buy a loaf of bread. If it is your job to keep that car working, and more importantly, to fix it again if it breaks, then you *do* need to know about it. Of course, if you are an end user, that's not a problem to you. > Ok, let me spell it out. If you're running a routing protocol on your > end-user workstations, you're probably doing it wrong. If you're running a > routing protocol on your routers, then it goes like this: > > RIP configuration: > > router rip > version 2 > redistribute connected > redistribute static > default-information originate > passive-interface FastEthernetX/Y > > or OSPF: > > router ospf 1 > redistribute connected subnets > redistribute static subnets > default-information originate > network a.b.c.0 0.0.0.255 area 0 > passive-interface FastEthernetX/Y > > The configuration parameters are similarly difficult for RIPng and OSPFv3, > or if you use Quagga instead of IOS, or JunOS instead of Quagga. > > I'm at a loss to see why one is much more difficult than the other. Can > you explain? On FreeBSD, enabling RIPng is a single line ipv6_router_enable=YES in /etc/rc.conf, while on Solaris you run # routeadm -e ipv6-routing # routeadm -u This *is* simpler than installing anything extra, sorting out potential init script issues mentioned above or any such thing. So much about running OSPF on Unix. Beyond that, your RIP configuration apparently works, but your OSPF one doesn't---maybe in the future you could try them out first, before publicly posting them. I have taken the liberty to dump your configuration into a toy 1812W, running 12.4(15)T1, just to make sure that I didn't just imagine the obvious error. But I got what I expected when I actually checked things: Router#show ip ospf 1 %OSPF: Router process 1 is not running, please configure a router-id Router# This is one of the very first things you should learn about OSPF: Be extremely careful about properly setting unique router IDs---even more so with OSPFv3, where an IP address can't be conveniently re-used as a router ID. And in a more general context it's also one of the very first things you should learn about any system or network administration in general: Always check the results. And, if possible, double and triple check. But that's still not the point. The real point is that things happen. Hardware breaks, software is buggy and, most importantly, people make mistakes. Maybe you have never had to deal with a "mission critical" system, but I have (and no, that TOP500 cluster wasn't the worst one). Fixing a problem that costs anything from 10000 Euro (or USD, whatever) per minute isn't fun, especially because very quickly you tend to have a flash mob (aka. unscheduled meeting of the board) breathing down your neck. What's worse, situations that you could cope with in a relaxed lab environment tend to turn out much more difficult to handle when they happen in production, because that's usually at 03:00 when you are dog tired, the colleague you desperatley need at the other end of the line 5000 km (3000 sm) away is down with flu and you're so pumped with adrenaline that most of whatever intelligence it leaves you can barely keep the fight or flight reflex at bay. If you are too optimistic about your skills when you set up things, then you are likely to learn about your limits and those of your colleagues and successors the hard way. > This thread is becoming too bizarre for words, but for some reason, I can't > seem to pull myself away from it. Maybe for starters you could just try to stop posting broken configurations and false statements about protocols you haven't tried out and don't understand. > Maybe don't explain after all. I'm not so much explaining but trying to help people finding your postings in search engines from getting into unnecessary trouble. Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jun 1 23:20:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 2 Jun 2010 06:50:01 +0930 Subject: The use of RIPng In-Reply-To: <20100601180801.GD4379@vacation.karoshi.com.> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> Message-ID: <20100602065001.30f0cc21@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Tue, 1 Jun 2010 18:08:01 +0000 bmanning at vacation.karoshi.com wrote: > Morning Nick.... > > > On Tue, Jun 01, 2010 at 06:29:51PM +0100, Nick Hilliard wrote: > > > > Ok, let me spell it out. If you're running a routing protocol on your > > end-user workstations, you're probably doing it wrong. If you're running a > > routing protocol on your routers, then it goes like this: > > if you run a routing protocol on an end-station - you've turned it into > a router... (much like what happens in some anycast clusters for node > failover) > > > I'm at a loss to see why one is much more difficult than the other. Can > > you explain? > > your looking at the configuration statements. what is the cpu/memory > footprint for the two? > I doesn't matter. If you think it does, then you haven't noticed the effect of Moore's law. IIRC, Cisco made a recommendation of a maximum of 50 routers and 200 links in an area many years ago. That was for *Cisco 2500s* i.e. a 25Mhz Motorolla 68030 CPU with (IIRC) a 1MB of RAM. Considering that Cisco 877s come with 400Mhz PowerPCs and a minium of 128MB of RAM, memory and CPU are of no concern in the RIP vs OSPF debate. So unless you're still running 2500s and have more than 50 routes, you won't have OSPF related CPU or memory issues - ever. I also don't think troubleshooting has much weight. In my experience, a well designed network commonly won't have failures that require protocol specific diagnosis i.e. understanding distance vector or link state methods of operation, packet traces etc. For smaller organisations, they'll be so rare that even if they do invest in that knowledge, by the time they need to use it, they'll have almost forgotten it anyway. Knowledge that isn't being used is being forgotten - that's how our brains work. It's better and quicker for those organisations to buy in that expertise on the rare occasions they need it. > > > This thread is becoming too bizarre for words, but for some reason, I can't > > seem to pull myself away from it. Maybe don't explain after all. > > trainwreck... can't look away! > > > > > Nick From me at benedikt-stockebrand.de Tue Jun 1 23:22:59 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Tue, 01 Jun 2010 21:22:59 +0000 Subject: The use of RIPng In-Reply-To: <4C054F1B.4060603@ipinc.net> (Ted Mittelstaedt's message of "Tue, 01 Jun 2010 11:19:07 -0700") References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C053FE1.6070307@ipinc.net> <4C054F1B.4060603@ipinc.net> Message-ID: Ted Mittelstaedt writes: > For networks like that we use 1 decent Internet router (we -always- > make any ISP that mandates an ISP-supplied CPE, set it up as a > bridge or router providing a subnet) and 1 decent managed layer 3 > gigabit switch - Netgear makes some really nice SOHO 24 & 48 port > fully managed ones that aren't that expensive - if we have to create > the same kind of network. I fully agree with the *decent* ISP :-) With the rest it is slightly more complex: > Or, just use a flat network and MAC address filtering to prevent the > different departments from seeing servers and such that they are not > supposed to get to and a layer 2 switch. This assumes that people don't do much fooling around, which is a reasonable assumption for a non-IT shop but not necessarily for a small software company or engineering office or such. > With fewer hardware boxes there's much less to go wrong. Agreed---as long as you still have arranged for access to spare components. It's just another variation of the "keeping complexity out where it doesn't help" theme. > But rarely do we ever see that kind of need in a SOHO. I'm not talking SoHo (as defined by what's generally sold as "SoHo equipment") here, but a bit larger. I'm thinking of the sort of people who actually need their network up and running to stay in business. If you are running an accounting/tax adviser office, then you have to deliver certain data to the German equivalent of the IRS. If you network is down the wrong day, it'll cost you. Possibly dearly. Similarly, and as a more internationally familar phenomenon, if you have agreed with a customer on some sort of penalty and can't deliver in time, things can quickly get rather ugly moneywise. Cheers Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From bmanning at vacation.karoshi.com Tue Jun 1 23:30:17 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 1 Jun 2010 21:30:17 +0000 Subject: The use of RIPng In-Reply-To: <20100602065001.30f0cc21@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <20100601180801.GD4379@vacation.karoshi.com.> <20100602065001.30f0cc21@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <20100601213017.GB5952@vacation.karoshi.com.> On Wed, Jun 02, 2010 at 06:50:01AM +0930, Mark Smith wrote: > On Tue, 1 Jun 2010 18:08:01 +0000 > bmanning at vacation.karoshi.com wrote: > > > Morning Nick.... > > > > > > On Tue, Jun 01, 2010 at 06:29:51PM +0100, Nick Hilliard wrote: > > > > > > Ok, let me spell it out. If you're running a routing protocol on your > > > end-user workstations, you're probably doing it wrong. If you're running a > > > routing protocol on your routers, then it goes like this: > > > > if you run a routing protocol on an end-station - you've turned it into > > a router... (much like what happens in some anycast clusters for node > > failover) > > > > > I'm at a loss to see why one is much more difficult than the other. Can > > > you explain? > > > > your looking at the configuration statements. what is the cpu/memory > > footprint for the two? > > > > I doesn't matter. If you think it does, then you haven't noticed the > effect of Moore's law. yes it does... particularly wrt mobile/embedded devices. cpu/memory == power == battery drain. as mentioned elsewhere - RIP is perhaps the smallest implementation of the D-V routing protocols and compared w/ link-state routing protocols (OSPF etc.), distance-vector routing protocols have less computational complexity and message overhead. ergo smaller resource constraints == more efficant. Just saying that there is a place for D-V in the world, its not just Link-state. Folks should (and do) use what works for them. As usual, YMMV. --bill From shane at time-travellers.org Wed Jun 2 09:21:56 2010 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 02 Jun 2010 15:21:56 +0800 Subject: Reliability & downtime, was Re: So why is "IPv4 with longer addresses" a problem anyway? In-Reply-To: <4C054276.5080700@ipinc.net> References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> <4C053559.8020808@foobar.org> <4C054276.5080700@ipinc.net> Message-ID: <1275463316.3658.149.camel@shane-asus-laptop> On Tue, 2010-06-01 at 10:25 -0700, Ted Mittelstaedt wrote: > > On 6/1/2010 9:29 AM, Nick Hilliard wrote: > > On 01/06/2010 14:56, Benedikt Stockebrand wrote: > >> destination. NUD ensures that a dead router is detected at an average > >> 30s, plusminus 15s to avoid synchronization effects. RFC 4861 has all > >> the details. > > > > It kills me to add further noise to this thread, but this is probably one > > of the base sources of contention. It seems that you're happy with 15-45 > > seconds as an operationally / commercially acceptable time period for loss > > of service in the event of gateway failure / failover. If you accept this > > level of service unavailability, then RA / NUD is quite adequate. > > > > I don't accept that this is an acceptable operational / commercial > > proposition for my customers. Therefore RA / NUD is not viable on the > > networks which I deal with. > > > > I don't accept that routers routinely dying is an acceptable operational > / commercial proposition for our customers. > > Just for grins I just checked and the last SCHEDULED reboot of our own > largest and most complex BGP-running router was 50 weeks ago. > > The last UNSCHEDULED reboot was something like 5 YEARS ago. Okay, that's one router... multiply that by 10 and you've got a router doing an unscheduled reboot every 6 months. See how that works? :) I think Nick was quite correct in identifying that for some operational environments (like yours apparently) RA is acceptable, but for others it doesn't fit the needs. And Ted, please try to stay nice! You are almost calling some of the other people on the list incompetent. That may be true, but I don't think you have enough information to know. ;) -- Shane From mtinka at globaltransit.net Wed Jun 2 10:06:15 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 2 Jun 2010 16:06:15 +0800 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses"a problem anyway?) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> References: <201006020011.03653.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> Message-ID: <201006021606.19401.mtinka@globaltransit.net> On Wednesday 02 June 2010 12:50:54 am George Bonser wrote: > What do you mean "were"? If you own Brocade/Foundry > SuperX units and want to run v6 layer 3 you need to buy > special blades AND pay a premium license fee. Any > networks unlucky enough to have purchased any of that > kit over the past few years are suddenly feeling this > burning sensation on their seat if they are considering > v6 migration. Those folk should have known better when purchasing kit, then. We won't buy kit or code from vendors that won't (have plans to) support IPv6. We won't buy transit from providers who won't support IPv6 (including those that won't support a full v6 routing able). I realize needs differ, but if we all voted with our feet/wallets re: IPv6, maybe we'll see the result we're all looking for. > I use RIPng only for "next hop" > information where I redistribute connected links from my > external peering connections among my BGP routers. > Internally we use OSPF. Why not set the BGP NEXT_HOP attribute to 'self' in your iBGP sessions? Or, worst case, run your peering interfaces in 'passive' mode in OSPF? I would have avoid have multiple dynamic IGP's if I could. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100602/e0a26d56/attachment.bin From michael.dillon at bt.com Wed Jun 2 10:13:55 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 2 Jun 2010 09:13:55 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: References:

<4C0189A0.4030509@netability.ie> <4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> <4C053559.8020808@foobar.org> <4C054276.5080700@ipinc.net> <1275463316.3658.149.camel@shane-asus-laptop> Message-ID: <4C06A459.6000304@dougbarton.us> On 06/02/10 00:21, Shane Kerr wrote: > I think Nick was quite correct in identifying that for some operational > environments (like yours apparently) RA is acceptable, but for others it > doesn't fit the needs. Thanks, that's my point exactly. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From nick at foobar.org Wed Jun 2 22:03:24 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 02 Jun 2010 21:03:24 +0100 Subject: The use of RIPng In-Reply-To: References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> Message-ID: <4C06B90C.9040501@foobar.org> On 01/06/2010 21:56, Benedikt Stockebrand wrote: > Beyond that, your RIP configuration apparently works, but your OSPF > one doesn't---maybe in the future you could try them out first, before > publicly posting them. I have taken the liberty to dump your > configuration into a toy 1812W, running 12.4(15)T1, just to make sure > that I didn't just imagine the obvious error. But I got what I > expected when I actually checked things: > > Router#show ip ospf 1 > %OSPF: Router process 1 is not running, please configure a router-id > Router# PRO TIP: a router with no IP address configured on any interface won't run OSPFv2. Nick From alex at digriz.org.uk Thu Jun 3 00:50:48 2010 From: alex at digriz.org.uk (Alexander Clouter) Date: Wed, 2 Jun 2010 23:50:48 +0100 Subject: The use of RIPng References: <201006020011.03653.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> <201006021606.19401.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA48B5@RWC-EX1.corp.seven.com> <667B1D57-BCD8-407F-B843-DD688E0E4422@ed.ac.uk> <4C06A0C5.2060702@ipinc.net> Message-ID: <8r3jd7-fd6.ln1@chipmunk.wormnet.eu> Ted Mittelstaedt wrote: > > Any vendor making and selling gear operates under a product > feature principle. > > This is that all features can be sorted by the number > of customers who -require- them. On top of the list are the > features considered most critical to the most number of > people, on the bottom the least critical. There is a price tag > associated with each feature. > > The lower down the list you go, the chance a feature will be > implemented is inversely proportional to it's price. > > Right now IPv6 is lower down on that feature list. The vendors > know that as time passes it will become more important and > so there is some weight to the idea of deploying IPv6 early, > but what this means economically is your able to defer some of > the cost of the IPv6 features into the future. > I would normally agree here if it was not that the feature was a L3 'thing' which is meant to be transparent to the layers above it. For example, I want a SIP based handset. There should be no reason that when SIP is implemented in the device by the vendor that it does not care about whether it is operating over IPv4 and IPv6. SSH and SNMP can also be considered similarly. I will agree things get a bit hazy when we are talking about devices that operate at or between L2 and L3, but for 'features' that live at L4 or above...I cannot understand why a vendor is not providing feature parity. There is a cost to *migrate* an existing codebase that is IPv4 only to dualstack, however for new devices/features, there is no excuse. Just my thoughts. Cheers -- Alexander Clouter .sigmonster says: Restaurant package, not for resale. From sethm at rollernet.us Thu Jun 3 04:21:17 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Jun 2010 19:21:17 -0700 Subject: "IPv6 for dummes" for sales staff? Message-ID: <4C07119D.8080002@rollernet.us> Does anyone have links or recommendations for some "IPv6 for dummies" materials suitable for marketing and sales staff? A lot of the stuff I'm finding or have used myself has a technical bent to it, which is fine for us, but confusing for sales. ~Seth From kuenzler at init7.net Thu Jun 3 07:39:02 2010 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 03 Jun 2010 07:39:02 +0200 Subject: "IPv6 for dummes" for sales staff? In-Reply-To: <4C07119D.8080002@rollernet.us> References: <4C07119D.8080002@rollernet.us> Message-ID: <4C073FF6.6010503@init7.net> Am 03.06.2010 04:21, schrieb Seth Mattinen: > Does anyone have links or recommendations for some "IPv6 for dummies" > materials suitable for marketing and sales staff? A lot of the stuff I'm > finding or have used myself has a technical bent to it, which is fine for > us, but confusing for sales. Maybe my slides from the IPv6 conference in Frankfurt two weeks ago are partly compatible for sales ... http://www.blogg.ch/uploads/IPv6-deployment-for-the-IPv4-clueful-heise-ipv6-conference.pdf Best regards, Fredy From gert at space.net Thu Jun 3 09:20:28 2010 From: gert at space.net (Gert Doering) Date: Thu, 3 Jun 2010 09:20:28 +0200 Subject: The use of RIPng In-Reply-To: <4C06B90C.9040501@foobar.org> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <4C06B90C.9040501@foobar.org> Message-ID: <20100603072028.GU99602@Space.Net> Hi, On Wed, Jun 02, 2010 at 09:03:24PM +0100, Nick Hilliard wrote: > PRO TIP: a router with no IP address configured on any interface won't run > OSPFv2. Why would anyone want OSPFv2? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 From sthaug at nethelp.no Thu Jun 3 09:36:40 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 03 Jun 2010 09:36:40 +0200 (CEST) Subject: The use of RIPng In-Reply-To: <20100603072028.GU99602@Space.Net> References: <4C06B90C.9040501@foobar.org> <20100603072028.GU99602@Space.Net> Message-ID: <20100603.093640.74705429.sthaug@nethelp.no> > > PRO TIP: a router with no IP address configured on any interface won't run > > OSPFv2. > > Why would anyone want OSPFv2? Presumably because OSPFv3 didn't use to support IPv4 (e.g. Juniper got their OSPFv3 IPv4 support in JunOS 9.2). Fortunately our backbone IGP has been IS-IS for many years. OSPFv2 or OSPFv3 has been a non-question... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tore.anderson at redpill-linpro.com Thu Jun 3 09:43:45 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 03 Jun 2010 09:43:45 +0200 Subject: The use of RIPng In-Reply-To: <20100603072028.GU99602@Space.Net> References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C05438F.6000200@foobar.org> <4C06B90C.9040501@foobar.org> <20100603072028.GU99602@Space.Net> Message-ID: <4C075D31.7040806@redpill-linpro.com> * Gert Doering > Why would anyone want OSPFv2? To run OSPFv3 on Juniper's EX series you'll need to buy a rather pricey advanced feature licence... :-( -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From gert at space.net Thu Jun 3 10:11:30 2010 From: gert at space.net (Gert Doering) Date: Thu, 3 Jun 2010 10:11:30 +0200 Subject: The use of RIPng In-Reply-To: <20100603.093640.74705429.sthaug@nethelp.no> References: <4C06B90C.9040501@foobar.org> <20100603072028.GU99602@Space.Net> <20100603.093640.74705429.sthaug@nethelp.no> Message-ID: <20100603081130.GV99602@Space.Net> Hi, On Thu, Jun 03, 2010 at 09:36:40AM +0200, sthaug at nethelp.no wrote: > > > PRO TIP: a router with no IP address configured on any interface won't run > > > OSPFv2. > > > > Why would anyone want OSPFv2? > > Presumably because OSPFv3 didn't use to support IPv4 (e.g. Juniper got > their OSPFv3 IPv4 support in JunOS 9.2). Thanks for emphasizing the point :-) - I was under the assumption that this discussion was about IPv6, not about legacy routing protocols. So "why would anyone want OSPFv2" (in an IPv6 routing protocols discussion)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100603/295f806e/attachment.bin From bmanning at vacation.karoshi.com Thu Jun 3 11:12:50 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 3 Jun 2010 09:12:50 +0000 Subject: The use of RIPng In-Reply-To: <20100603081130.GV99602@Space.Net> References: <4C06B90C.9040501@foobar.org> <20100603072028.GU99602@Space.Net> <20100603.093640.74705429.sthaug@nethelp.no> <20100603081130.GV99602@Space.Net> Message-ID: <20100603091250.GA15519@vacation.karoshi.com.> On Thu, Jun 03, 2010 at 10:11:30AM +0200, Gert Doering wrote: > Hi, > > On Thu, Jun 03, 2010 at 09:36:40AM +0200, sthaug at nethelp.no wrote: > > > > PRO TIP: a router with no IP address configured on any interface won't run > > > > OSPFv2. > > > > > > Why would anyone want OSPFv2? > > > > Presumably because OSPFv3 didn't use to support IPv4 (e.g. Juniper got > > their OSPFv3 IPv4 support in JunOS 9.2). > > Thanks for emphasizing the point :-) - I was under the assumption that > this discussion was about IPv6, not about legacy routing protocols. IPv4/6 are not routing protocols... perhaps you mean OSPF is a legacy routing protocol, and after all, who would ever run a legacy routing protocol. > So "why would anyone want OSPFv2" (in an IPv6 routing protocols discussion)? > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 150584 > > 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 From david.freedman at uk.clara.net Thu Jun 3 11:49:46 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 03 Jun 2010 10:49:46 +0100 Subject: IPv6 Infrastructure PI Message-ID: Now we have "LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites" in RIPE-481 Have been hearing talk of organisations applying for this to number their infrastructure out of it and make the space un-routable for security purposes. Would be keen to know what others think of this, here are the points I made: - That it is no different to people using IPV4 un-routed infrastructure addressing (i.e unshared RFC1918) - That I could still use ULA, pure linklocal, unnumbered /128 POS etc.. - That customer networks would still be attached to your equipment and the global addressing for their gateways are still attack vectors. - That once I know that there is some unique addressing which is trusted by your equipment, I know that if you slip up and don't filter it everywhere on ingress I can static route back to you somehow (through peering or customer connection) and impersonate your trusted hosts. I know this is not a new argument, but I'm interested to hear what others think... ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From gert at space.net Thu Jun 3 11:51:35 2010 From: gert at space.net (Gert Doering) Date: Thu, 3 Jun 2010 11:51:35 +0200 Subject: The use of RIPng In-Reply-To: <20100603091250.GA15519@vacation.karoshi.com.> References: <4C06B90C.9040501@foobar.org> <20100603072028.GU99602@Space.Net> <20100603.093640.74705429.sthaug@nethelp.no> <20100603081130.GV99602@Space.Net> <20100603091250.GA15519@vacation.karoshi.com.> Message-ID: <20100603095135.GW99602@Space.Net> Hi, On Thu, Jun 03, 2010 at 09:12:50AM +0000, bmanning at vacation.karoshi.com wrote: > > Thanks for emphasizing the point :-) - I was under the assumption that > > this discussion was about IPv6, not about legacy routing protocols. > > IPv4/6 are not routing protocols... > perhaps you mean OSPF is a legacy routing protocol, and > after all, who would ever run a legacy routing protocol. Being only useful for a legacy layer 3 protocol makes OSPFv2 a legacy routing protocol for me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100603/ef351a5a/attachment.bin From gert at space.net Thu Jun 3 12:03:06 2010 From: gert at space.net (Gert Doering) Date: Thu, 3 Jun 2010 12:03:06 +0200 Subject: IPv6 Infrastructure PI In-Reply-To: References: Message-ID: <20100603100306.GX99602@Space.Net> Hi, On Thu, Jun 03, 2010 at 10:49:46AM +0100, David Freedman wrote: > Now we have "LIRs can qualify for an IPv6 PI assignment for parts of their > own infrastructure that are not used for customer end sites" in RIPE-481 > Have been hearing talk of organisations applying for this to number their > infrastructure out of it and make the space un-routable for security > purposes. > > Would be keen to know what others think of this, here are the points I made: > > - That it is no different to people using IPV4 un-routed infrastructure > addressing (i.e unshared RFC1918) It's better than that, because the addresses are guaranteed to be unique, and you can even have reverse DNS for it. RFC1918 for "visible" infrastructure (e.g. showing up in traceroutes) violates RFC1918 and, generally, sucks. > - That I could still use ULA, pure linklocal, unnumbered /128 POS etc.. ULA would also be a workable approach. Pure link-local works, but has the disadvantage that you can't ping the individual interfaces from your network monitoring systems. > - That customer networks would still be attached to your equipment and the > global addressing for their gateways are still attack vectors. Correct for your edge systems. > - That once I know that there is some unique addressing which is trusted by > your equipment, I know that if you slip up and don't filter it everywhere on > ingress I can static route back to you somehow (through peering or customer > connection) and impersonate your trusted hosts. True as well: hack a customer PC, access your network from there... So "non-routed backbone addresses alone" isn't auto-securing your network, you also need to filter it against folks statically routing it to you or against your customers trying to get access to it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 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 From tjc at ecs.soton.ac.uk Thu Jun 3 16:03:19 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 3 Jun 2010 15:03:19 +0100 Subject: "IPv6 for dummes" for sales staff? In-Reply-To: <4C073FF6.6010503@init7.net> References: <4C07119D.8080002@rollernet.us> <4C073FF6.6010503@init7.net> Message-ID: On 3 Jun 2010, at 06:39, Fredy Kuenzler wrote: > Am 03.06.2010 04:21, schrieb Seth Mattinen: >> Does anyone have links or recommendations for some "IPv6 for dummies" >> materials suitable for marketing and sales staff? A lot of the stuff I'm >> finding or have used myself has a technical bent to it, which is fine for >> us, but confusing for sales. > > Maybe my slides from the IPv6 conference in Frankfurt two weeks ago are > partly compatible for sales ... > > http://www.blogg.ch/uploads/IPv6-deployment-for-the-IPv4-clueful-heise-ipv6-conference.pdf > There's some video e-learning material here care of 6DEPLOY: http://www.6deploy.org/index.php?page=e-learning The introduction bits may be useful for such staff, at least for a high level what/why view. Tim From tjc at ecs.soton.ac.uk Thu Jun 3 16:40:07 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 3 Jun 2010 15:40:07 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> References:

<4C0189A0.4030509@netability.ie><4C03BADF.3080902@foobar.org> <20100531134055.GV88261@ronin.4ever.de> <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk> Message-ID: On 3 Jun 2010, at 16:40, Tim Chown wrote: > > On 2 Jun 2010, at 09:13, > wrote: > >>> I do have a sense of deja-vu in a lot of instances, and all this has >>> been >>> covered before: you're correct. I also agree that existing sites >>> simply >>> need updating or new ownership just to get them pushed along. I'm >>> currently facing that as I go throw my own IPv6 planning for another >>> group. >> >> Neither the 6net or the Janet sites are "cookbooks", neither are >> wikis, >> and there is no easy way to update them. A cookbook should allow >> anyone >> to post their recipe/solution for a problem that they have faced, >> without requiring any bureaucratic process of contacting site owners. >> >> Hopefully the ARIN wiki already has links to the 6net and Janet >> resources. > > As the author of the JANET guide, and a contributor to the 6NET > Deployment Guide, I can maybe comment on both a little. > > I would say that it's unlikely the 6NET book will be updated, though > some of the original contributors have had some discussion about the > possibility. The original text was just one of 100+ deliverables/ > outputs of a project that ran from 2002-2005. Despite its age, a > surprising amount of the guide is still accurate. The 'problem' > probably lies more with what's not included, e.g. new perspectives > and solutions for IPv4/IPv6 integration (6rd, Teredo, NAT64, > etc). I am seeing if we can somehow distill the Word source into > something wikifiable - I don't believe there should be any copyright > issues on that, as it was produced largely by public funding (6NET > being an EU IST project). > > As it happens I'm updating the JANET guide this month, and in > parallel helping JANET(UK) produce some new IPv6 training material > for network administrators. Any comments on what to add to the > JANET guide are welcome by direct mail. This text would stay in > fixed PDF form though as its a JANET-branded publication (JANET > being the UK academic network). I can certainly try to rewrite > the updated bits in a more 'generalised' way to be more widely > applicable. > > Tim I'm one of the people at the RIPE NCC responsible for the IPv6 Act Now website (http://www.ipv6actnow.org). It's not a website that can be edited by users, so is probably not directly suited to the "cookbook" format (though it does have links to resources like the 6Deploy site and ARIN wiki). However, various RIRs do have a number of options that might work well for this. Michael has already mentioned the ARIN IPv6 Wiki; RIPE Labs is another site that could be a good platform for this. (http://labs.ripe.net) RIPE Labs is already hosting a couple of IPv6-related resources that users can have input to (and will shortly have a functionality upgrade that will make direct user updates even easier): The IPv6 CPE Survey: http://labs.ripe.net/content/ipv6-cpe-survey Based on work already done by Marco Hogewoning, this was published only a couple of days ago and we plan to grow it into an extensive summary of CPEs and their IPv6 ability. IPv6 Measurements: A Compilation: http://labs.ripe.net/content/ipv6-measurement-compilation A list of various IPv6 measurements from around the web. We'd be happy to to provide RIPE Labs as a platform for the cookbook, and help out, where necessary, with collating some of the information. To that end, I've started a forum topic on Labs where people could post the type of information that you would like to see included: http://labs.ripe.net/content/ipv6-cookbook-looking-ingredients Depending on the response, we can then consider how best to proceed with editing/collating the information provided. Chris From me at benedikt-stockebrand.de Thu Jun 3 18:52:08 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 03 Jun 2010 16:52:08 +0000 Subject: The use of RIPng In-Reply-To: <201006021644.24263.mtinka@globaltransit.net> (Mark Tinka's message of "Wed, 2 Jun 2010 16:44:19 +0800") References: <201006012334.51111.mtinka@globaltransit.net> <201006021644.24263.mtinka@globaltransit.net> Message-ID: Hi Mark and list, Mark Tinka writes: > But that's just me; it's a free world, you're welcome to run > whatever you like :-). if that includes running RIP that's fine with me:-) > [...] > These might probably afford to employ someone like yourself > to come in as-needed to fix problems with their link state > routing protocol. (I'm not the one coming in, but some of the people that show up in my workshops do.) The problem here is the time it takes to call someone in. That time does cost money. And yes, software developers are particularly notorious at wantonly breaking things and then making things worse by trying to fix them. Finally, I assume you are rather network/routing-centric. With my customers that's only one of many relevant topics. > If you're spending too much debugging your IGP, your probably have a > poor network design to start with. Agreed. Unfortunately there are *many* of those "historically grown" network designs around. And then there are those people who claim that you just bring in OSPF (or EIGRP) and all problems will magically go away. The problem however is if you *rarely* touch anything. When things happen you're bound to figure out how you---or somebody else---made things work months and years ago. > I think routing protocols are as relevant to IP as IP, itself, is. >From your perspective it is, and since that's what you are paid for that's how it ought to be. But there are other issues far more pressing to some people: - Will /whatever/ software work with IPv6, and if not, how do I fix it and how much work is involved there? - What about performance impacts on applications? (Two of the more unusual participants in a training asked specifically about performance impacts on the DNS. They were working for DeNIC...) - What needs to be done with regard to monitoring? - What should change about the network topology when IPv6 is deployed? - Where do I find a replacement for my current XXX stuff? I've done rather network-centric workshops, too, and I've even done a two day in-house course on IPv6 protocol internals because that's what the customer wanted, but most of the time a network-centric workshop would have a far too narrow focus for my "usual" customers. > Whatever they take in now will stick for a very long time, > and what we've seen with workshops is the hardest thing to > teach participants is how to "unlearn" the bad stuff they've > picked up from allover. It's not that I don't explain about the limitations of RIP and why OSPF may eventually become relevant. But if you are dealing with people who so far have never touched any dynamic routing at all, OSPF tends to scare them. > I really can't tell you how to do your job. Only you know it > best :-). No, but my customers do:-) > But the fact about getting down the good principles in the start, > remains, and personally, while you can't stop folk from doing what > they want to do, RIP should really not be talked about in public, > especially to virgin operators. These aren't really "virgin operators" but people who have so far stuck with static routes (think of the average Linux geek here for example) and now want to avoid those pesky typos in IPv6 routing tables. It's pretty much down to "different customers have different needs". And of course that the Internet is way too diverse for anybody to entirely imagine anymore. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From Sam.Wilson at ed.ac.uk Thu Jun 3 18:59:45 2010 From: Sam.Wilson at ed.ac.uk (Sam Wilson) Date: Thu, 3 Jun 2010 17:59:45 +0100 Subject: The use of RIPng In-Reply-To: <4C06A0C5.2060702@ipinc.net> References: <201006020011.03653.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA485A@RWC-EX1.corp.seven.com> <201006021606.19401.mtinka@globaltransit.net> <5A6D953473350C4B9995546AFE9939EE09EA48B5@RWC-EX1.corp.seven.com> <667B1D57-BCD8-407F-B843-DD688E0E4422@ed.ac.uk> <4C06A0C5.2060702@ipinc.net> Message-ID: On 2 Jun 2010, at 19:19, Ted Mittelstaedt wrote: > > > On 6/2/2010 9:45 AM, Sam Wilson wrote: >> >> On 2 Jun 2010, at 17:20, George Bonser wrote: >> >>> ... It isn't the rolling out of v6 >>> per se that is the problem. It is the lack of support tools (DNS >>> management is one example) and vendor oddities that are adding >>> additional barriers to networks who see the writing on the wall >>> but have >>> internal operational or financial barriers. This isn't going to >>> change >>> until people globally think of v6 as the standard and not some >>> "optional" requirement. >> >> We were recently invited by a supplier to provide input on a >> particular >> IPv6 feature that was missing from a new product, to justify why they >> should implement it. My text ended this way: >> >> "... As network operators we would expect to provide the same >> standard of service for IPv6 as for IPv4. For that we simply >> expect parity of features between v4 and v6. Since you already >> offer [feature X for IPv4] on these platforms, and have done >> since the [previous generation] first appeared, why *wouldn't* >> you do [feature X] for IPv6?" >> > > That's a shame that you sent that. A real shame. You lost the > opportunity to educate your supplier. If that had been all I'd said I might agree with you. As you'll see above that was how my text ended. > [snip a whole load of stuff telling me what I did and didn't do and > what I should have done] I have to say I'm really finding it difficult to write a civil response here. I'm limited in what I can say - I really don't want to trespass on the relationship we have with our suppliers. The events that led up to this were: vendor NDAs new generation of product, trumpeting that they are offering parity of features for IPv4 and IPv6 for the first time. When the datasheet is eventually made public we note that some words are omitted and ask if that means that some features are not available for IPv6. Vendor confirms that is the case. We express dissatisfaction. We are invited to say why we need that feature. Our response is to explain what we use the previous generations of the product for, saying we expect to offer the same services for IPv6 in future and expressing surprise that matching IPv6 features are (still!) missing. If the corresponding IPv4 feature hadn't been there for years I wouldn't have been making the point. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From me at benedikt-stockebrand.de Thu Jun 3 19:57:28 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 03 Jun 2010 17:57:28 +0000 Subject: The use of RIPng In-Reply-To: <201006021752.56837.mtinka@globaltransit.net> (Mark Tinka's message of "Wed, 2 Jun 2010 17:52:52 +0800") References: <4C05438F.6000200@foobar.org> <201006021752.56837.mtinka@globaltransit.net> Message-ID: Hi again, Mark Tinka writes: > Something tells me Nick is already familiar with this > requirement in OSPFv2|v3 in IOS :-), and as such, supporting > configuration was implied. right. I probably should've caught some sleep before posting, the missing router ID only turns up this way with OSPFv3. Apologies to Nick. > The highest IPv4 Loopback or major interface address becomes > the default Router-ID, and as such, does not necessarily > call for the explicit definition of the same (even though > this is not an uncommon design). That's actually the one "anti-difference" between OSPFv2 and v3: With v3 it's still "a 32 bit integer that happens to be written like an IP(v4) address", so you want to be more careful there. And since duplicated router IDs are one of my favourite exercises on basic OSPF(v3) troubleshooting... > The complaint you receive from the router is likely because > you don't have any IPv4 address configured, Correct. > a somewhat unlikely scenario for now, Depends. My larger customers frequently insist on keeping IPv4 and IPv6 on separate machines in production setups so they won't accidentially interfere with each other. As long as there is enough equipment around that has been replaced by something bigger, that approach can actually make sense, depending on the particular circumstances. > but maybe so in many years when new users/networks will never have > access to public v4 address space. That's likely to happen in less than "many years" (for suitable definitions of "many") in some contexts: There is a tendency to dual-stack nodes and subnets on a need-to-have basis only. So there's a good chance that enterprise environments will use either IPv4 or IPv6 only for individual desktop-style clients, most likely IPv4 for XP and IPv6 for Win7, with dual-stacked clients being the exception. In an ISP/Carrier context the situation is obviously going to be different. > But you probably know all this already :-). Actually, it never occurred to me to set up OSPF without first setting a router ID. Call me paranoid if you like:-) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From me at benedikt-stockebrand.de Thu Jun 3 20:20:45 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Thu, 03 Jun 2010 18:20:45 +0000 Subject: The use of RIPng In-Reply-To: <4C069989.7030105@ipinc.net> (Ted Mittelstaedt's message of "Wed, 02 Jun 2010 10:48:57 -0700") References: <201006010047.26322.mtinka@globaltransit.net> <201006012334.51111.mtinka@globaltransit.net> <4C053FE1.6070307@ipinc.net> <4C054F1B.4060603@ipinc.net> <4C069989.7030105@ipinc.net> Message-ID: Hi Ted and list, Ted Mittelstaedt writes: > Complexity like running a routing protocol on each WS? ;-) That's what we did fifteen years ago with IPv4. Then came VRRP and HSRP, plus whatever non-standardized mechanisms you would use with a stateful packet filter. Saved quite some trouble. And with IPv6, Autoconf+NUD becomes yet another option. > This does NOT mean that all cheap solutions are reliable. That's he problem: Too often you only find out after you've deployed them. As far as "buy Cisco/IBM/Microsoft/ and you're are out of trouble" goes, I think we agree that that only works if you need an excuse towards management rather than an actual solution. > Hmm, well we treat all our customers, including the residential ones, > this way. In that case you don't have those "buy cheap" people as customers. I've been working for a large ISP (then called T-Online), and with customer support showing up rather impressively on the balance sheet, no matter what you do it's eventually down to "you get what you pay for". In other words, consider yourself lucky. Small end users do have their own peculiarities, but the low-cost end user business can really drive you crazy. And no, I didn't do user support (whatever level) there. > In any case, as far as Internet connectivity goes, the Telco's > control the reliability of THAT. > [...] > Perhaps the Telco's operate differently in Germany? The people I talk about frequently have a dial-up backup solution, often with UMTS/3G as a last resort. And while the telcos are likely pretty much the same all over the world, there are smaller ISPs here who primarily target these customers. As I understand, they frequently offer fallback connectivity to business customers. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From michael.dillon at bt.com Fri Jun 4 10:50:46 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Jun 2010 09:50:46 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: References:

Message-ID: <28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> > However, various RIRs do have a number of options that > might work well for this. Michael has already mentioned the ARIN IPv6 > Wiki; RIPE Labs is another site that could be a good platform for > this. (http://labs.ripe.net) I'd prefer that RIPE *NOT* create another Ipv6 site since part of the problem is that Ipv6 information is too scattered. Intstead, since RIPE already has a good site with videos and interviews targetting technical decision makers, I would prefer to see ARIN and RIPE join together on this. The end result would be that RIPE promotes getipv6.info as the one right place to find and update operational experience and cookbook style recipes, and ARIN promotes Ipv6actnow.org as the one place for the latest IPv6 news and info. Similarly, this list should adopt the getipv6.info site and we should all register for logins and update the info from time to time. You don't need to be an Ipv6 expert to do this since often the experts don't realise how useful a particular email explanation was. I've already done something similar with the NANOG list about a year or so ago when there was a lot of Ipv6 discussion, i.e. I extracted the best bits of info and put them on getipv6.info. And, of course, we should invite APNIC, LACNIC and AfriNIC to join in as well rather than simply duplicating the same ideas and causing info to get more scattered. As for JANET and similar orgs, they will always do what they do, but the getipv6.info wiki can link to the JANET document and even include a "bopok review" of it so people know what is there. And Ipv6actnow.org could interview the author about the new guide and why it needed to be updated. Because of the working relationships between the RIRs and all network operators, I think that it is best to have these kinds of sites affiliated with one of the RIRs because a lot of people will look to the RIR for information knowing that other ISPs may have already solved a particular problem. --Michael Dillon From mohacsi at niif.hu Fri Jun 4 10:57:13 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 4 Jun 2010 10:57:13 +0200 (CEST) Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> References:

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Dear Michael, I would prefer that every who has IPv6 operational experiences share them one way or another. I don't care which portal or at which organisation. Internet is a free medium to publish documents. Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 4 Jun 2010, michael.dillon at bt.com wrote: >> However, various RIRs do have a number of options that >> might work well for this. Michael has already mentioned the ARIN IPv6 >> Wiki; RIPE Labs is another site that could be a good platform for >> this. (http://labs.ripe.net) > > I'd prefer that RIPE *NOT* create another Ipv6 site since part of the > problem is that Ipv6 information is too scattered. Intstead, since RIPE > already has a good site with videos and interviews > > targetting technical decision makers, I would prefer to see ARIN and > RIPE > join together on this. > > The end result would be that RIPE promotes getipv6.info as the one right > place to find and update operational experience and cookbook style > recipes, and ARIN promotes Ipv6actnow.org as the one place for the > latest > IPv6 news and info. > > Similarly, this list should adopt the getipv6.info site and we should > all > register for logins and update the info from time to time. You don't > need to > be an Ipv6 expert to do this since often the experts don't realise how > useful > a particular email explanation was. I've already done something similar > with > the NANOG list about a year or so ago when there was a lot of Ipv6 > discussion, > i.e. I extracted the best bits of info and put them on getipv6.info. > > And, of course, we should invite APNIC, LACNIC and AfriNIC to join in as > well > rather than simply duplicating the same ideas and causing info to get > more > scattered. > > As for JANET and similar orgs, they will always do what they do, but the > getipv6.info > wiki can link to the JANET document and even include a "bopok review" of > it so > people know what is there. And Ipv6actnow.org could interview the author > about > the new guide and why it needed to be updated. > > Because of the working relationships between the RIRs and all network > operators, > I think that it is best to have these kinds of sites affiliated with one > of the > RIRs because a lot of people will look to the RIR for information > knowing that > other ISPs may have already solved a particular problem. > > --Michael Dillon > > From michael.dillon at bt.com Fri Jun 4 11:13:59 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Jun 2010 10:13:59 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: References:

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> > I would prefer that every who has IPv6 operational > experiences share them one way or another. When there are too many places to share experiences, many people don't share at all, or only share on a one-to-one basis. > I don't care which > portal or at which organisation. Internet is a free medium to publish > documents. Then you should support having fewer places which attempt to be portals and more groups banding together to support those places. This is not about freedom to publish, because as you pointed out, everyone already is free to publish as they wish on the Internet. This is about making information easier to find, and most importantly, making the quality of information better. If everyone just publishes their experiences on their blogs, then a newcomer who tries to make use of that information on a slightly different network will run into problems. Or you will find one blog saying RA is all you need, and another telling you that you must set up DHCPv6 and patch it in a certain way. But when you get many people working together on a wiki, you get some synergy so that the page recommending RA explains when it is appropriate and when it might not be. Then the page recommending DHCPv6 will say that smaller networks need not bother with the complexity, and there will also be a page explaining how to configure RA and DHCPv6 to work together. Similarly the issue of OSPFv3 and router IDs would get explained so that people don't have surprises when they shift from dual-stack to pure Ipv6. All of this is also discussed in mailing lists, but you have to wade through the whole thread to figure out what the end result was. A good wiki will publish a summing up with the CONCLUSIONS of a discussion, so that it is easier for a learner to understand. Both mailing lists and wikis require a critical mass of people in order to be successful. My suggestions to RIPE and ARIN are about achieving that kind of critical mass. --Michael Dillon From kaeso at email.it Fri Jun 4 11:51:50 2010 From: kaeso at email.it (Luca Bruno) Date: Fri, 4 Jun 2010 11:51:50 +0200 Subject: Fw: AS 7575 announcing 2400::/12 Message-ID: <20100604115150.40e5707a.kaeso@email.it> Begin forwarded message: Date: Fri, 4 Jun 2010 12:31:42 +1000 From: Geoff Huston To: nanog list , ausnog at lists.ausnog.net Subject: AS 7575 announcing 2400::/12 Hi, As part of some ongoing collaborative research work in looking at the "dark" traffic in IPv6, APNIC has requested AARNet to originate a supernet advertisement of the IPv6 prefix 2400::/12 for the next two weeks. The originating AS is AS7575. We would appreciate it if you could adjust your routing filters to permit this advertisement if you are actively filtering IPv6 routing advertisements. Reports from previous work in the IPv4 space can be found at http://www.potaroo.net/studies/ - we hope to add to this with a report describing data collected about the level (and type) of background traffic seen in this part of IPv6. We would also be grateful if other operational lists received this notification - so please forward this as appropriate (but preferably only once!) Many thanks, Geoff Huston, George Michaelson APNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100604/9f1f2a59/attachment.bin From marcoh at marcoh.net Fri Jun 4 12:34:28 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 4 Jun 2010 12:34:28 +0200 Subject: IPv6 Infrastructure PI In-Reply-To: <20100603100306.GX99602@Space.Net> References: <20100603100306.GX99602@Space.Net> Message-ID: > It's better than that, because the addresses are guaranteed to be unique, > and you can even have reverse DNS for it. RFC1918 for "visible" > infrastructure (e.g. showing up in traceroutes) violates RFC1918 and, > generally, sucks. Using GUA, have it show up in traceroute but not route it on purpose sucks even more. It will make me wonder wether something is broken or this is by design. Groet, MarcoH From mtinka at globaltransit.net Fri Jun 4 16:51:12 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 4 Jun 2010 22:51:12 +0800 Subject: The use of RIPng In-Reply-To: References: <201006021752.56837.mtinka@globaltransit.net> Message-ID: <201006042251.13517.mtinka@globaltransit.net> On Friday 04 June 2010 01:57:28 am Benedikt Stockebrand wrote: > That's actually the one "anti-difference" between OSPFv2 > and v3: With v3 it's still "a 32 bit integer that > happens to be written like an IP(v4) address", so you > want to be more careful there. > > And since duplicated router IDs are one of my favourite > exercises on basic OSPF(v3) troubleshooting... I generally do prefer to lock-down my Router ID's (even though some feel this is too much work), but in the case of IOS, we run IS-IS anyway. > Depends. My larger customers frequently insist on > keeping IPv4 and IPv6 on separate machines in production > setups so they won't accidentially interfere with each > other. If by "interfering" you mean with regard to the routing protocols, OSPFv2 and OSPFv3 are ships-in-the-night. That said, interference is more likely in IS-IS since both IP protocols are integrated and supported by the routing protocol. This is sometimes enabled by default in some platforms, e.g., JUNOS. Lack of congruency between both IP protocols, on the wire, will lead to a disruption of adjacencies when v6 is turned up, dual-stack style. However, if by "interfering" you mean v4 and v6 traffic not playing nice with each other in a single router, that should be filed as a bug with your vendor :-). And you probably want to start finding such problems early on. > As long as there is enough equipment around that has been > replaced by something bigger, that approach can actually > make sense, depending on the particular circumstances. To each his own :-). > That's likely to happen in less than "many years" (for > suitable definitions of "many") in some contexts: I say "many" in the context of; even after the RIR's run out of v4 space, allocations which will have already been dished out will still be used for some time to build the network. However, how "many" actually is depends on how much v4 address space you end up with at the time of your last allocation, and how quickly you burn through it after that. This will vary from network to network (or not). > There > is a tendency to dual-stack nodes and subnets on a > need-to-have basis only. So there's a good chance that > enterprise environments will use either IPv4 or IPv6 > only for individual desktop-style clients, most likely > IPv4 for XP and IPv6 for Win7, with dual-stacked clients > being the exception. We currently have no data on how enterprise customers will deploy v6, in that degree of detail. But what we do in fixing the problems highlighted the long thread we had on v6 deployments in the LAN, will help determine that, moving forward. > In an ISP/Carrier context the situation is obviously > going to be different. Indeed. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100604/e5911c14/attachment.bin From mtinka at globaltransit.net Fri Jun 4 16:52:44 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 4 Jun 2010 22:52:44 +0800 Subject: The use of RIPng (was: Re: So why is "IPv4 with longer addresses"a problem anyway?) In-Reply-To: <667B1D57-BCD8-407F-B843-DD688E0E4422@ed.ac.uk> References: <5A6D953473350C4B9995546AFE9939EE09EA48B5@RWC-EX1.corp.seven.com> <667B1D57-BCD8-407F-B843-DD688E0E4422@ed.ac.uk> Message-ID: <201006042252.45153.mtinka@globaltransit.net> On Thursday 03 June 2010 12:45:52 am Sam Wilson wrote: > "... As network operators we would expect to provide > the same standard of service for IPv6 as for IPv4. For > that we simply expect parity of features between v4 and > v6. Since you already offer [feature X for IPv4] on > these platforms, and have done since the [previous > generation] first appeared, why *wouldn't* you do > [feature X] for IPv6?" Well, the standard answer would be, "Not enough software engineering resources, unless you're buying 1,000 units of the platform". Case in point, LDP support for IPv6 - 3 years and running between Cisco and Juniper? Look at when SNMP got native transport support for IPv6? We'll get there, eventually, but without pressure from more operators, movement will be relegated to cheque-book nudges. Of course, we all have different priorities, so... Keep on pushing, is all I can say. If you have more RFP's going out, use them. Will do the same on this end :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100604/b4ab9da2/attachment.bin From michael.dillon at bt.com Fri Jun 4 17:12:56 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Jun 2010 16:12:56 +0100 Subject: ARIN's new whois -- Coming Improvements to ARIN's Whois DirectoryService Message-ID: <28E139F46D45AF49A31950F88C497458063DFEA9@E03MVZ2-UKDY.domain1.systemhost.net> I don't know how widely ARIN distributes these notices, but for anyone interested in improving the whois system, there are a couple of URLs here where you can try ARIN's new whois and read some documentation about it. It would be interesting for RIPE labs to deploy a trial whois server that matches the ARIN spec to see if WHOIS-RWS is easily adaptable outside of ARIN or not. -----Original Message----- From: arin-announce-bounces at arin.net [mailto:arin-announce-bounces at arin.net] On Behalf Of Member Services Sent: 04 June 2010 16:05 To: arin-announce at arin.net Subject: [arin-announce] Coming Improvements to ARIN's Whois DirectoryService ARIN is pleased to announce that it plans to deploy an improved Whois service called Whois-RWS on 26 June 2010. Included in the deployment are the following services that provide the general public with access to ARIN's registration data. * a RESTful Web Service (RWS) * a NICNAME/WHOIS port 43 service * a user-friendly web site (http://whois.arin.net) A demo of this service has been available since October 2009. The demonstration service will be available at http://whoisrws-demo.arin.net until the production service is deployed on 26 June 2010. When using Whois-RWS you will notice some differences in behavior for certain queries and corresponding result sets on the NICNAME/WHOIS port 43 service. ARIN will make a separate announcement on 11 June when it publishes detailed documentation on these differences along with the demonstration service update. ARIN continues to welcome community participation on the Whois-RWS mailing list, and we invite you to subscribe and share your thoughts and suggestions at: http://lists.arin.net/mailman/listinfo/arin-whoisrws More detailed information on these changes and other future features that may impact the community at ARIN is available at: https://www.arin.net/features/ Regards, Mark Kosters Chief Technical Officer American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From me at benedikt-stockebrand.de Fri Jun 4 17:47:14 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Fri, 04 Jun 2010 15:47:14 +0000 Subject: The use of RIPng In-Reply-To: <201006042251.13517.mtinka@globaltransit.net> (Mark Tinka's message of "Fri, 4 Jun 2010 22:51:12 +0800") References: <201006021752.56837.mtinka@globaltransit.net> <201006042251.13517.mtinka@globaltransit.net> Message-ID: Hi Mark and list, Mark Tinka writes: > I generally do prefer to lock-down my Router ID's (even > though some feel this is too much work), So do I. And with OSPFv3/IPv6 you have to do so anyway. > but in the case of IOS, we run IS-IS anyway. Whatever gets the job done. >> Depends. My larger customers frequently insist on >> keeping IPv4 and IPv6 on separate machines in production >> setups so they won't accidentially interfere with each >> other. > > If by "interfering" you mean with regard to the routing > protocols, OSPFv2 and OSPFv3 are ships-in-the-night. No, it's not something related to routing protocols at all (despite your point about IS-IS being perfectly valid). It's more about having to upgrade production equipment to support IPv6, management and established business processes being rather restrictive about doing "unnecessary" changes on production equipment and having signed service level agreements for IPv4 but not IPv6. At least here in Germany those ISPs and hosting providers that offer IPv6 tend to offer IPv6 on a "no guarantees" basis only, giving both their customers and themselves a chance to get their hands dirty. > However, if by "interfering" you mean v4 and v6 traffic not > playing nice with each other in a single router, that should > be filed as a bug with your vendor :-). Definitely. Preferably by sending back whatever you bought from them and demanding your money back in return:-) > And you probably want to start finding such problems early on. Sure, but I'd rather not do that on production machines. > We currently have no data on how enterprise customers will > deploy v6, in that degree of detail. Well, you never know what people do when they have to get things done in a rush, but so far there's a tendency (and good reasons) not to deploy unnecessary dual-stacking at a large scale. Of course, to anybody offering public Internet access (ISPS, Internet cafes and university (W)LANs immediately come to mind), dual-stacking will be a necessity for quite some time. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From woody at pch.net Wed Jun 2 19:02:41 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 2 Jun 2010 10:02:41 -0700 Subject: IPv6 Anycast In-Reply-To: <20100602124343.GA10342@merboo.mamista.net> References: <20100602124343.GA10342@merboo.mamista.net> Message-ID: On Jun 2, 2010, at 5:43 AM, Martin Barry wrote: > I'm trying to get a good grasp of IPv6 anycast. Good luck. > It appears to me that it's not quite analogous to the concept of anycast > which has prevailed in IPv4... That's correct. > ...and has some deficiencies which would lead some > operators to prefer to continue using the old method with IPv6 unicast > addresses. That would be an understatement. To the best of my knowledge, _all_ anycast operators use actual anycast in the same way for both IPv4 and IPv6. "IPv6 Anycast" was an unfortunate misnomer dubbed by IPv6 people who didn't understand anycast, and continues to occasionally confuse people. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100602/34d4b41e/attachment.bin From spz at serpens.de Sat Jun 5 21:13:32 2010 From: spz at serpens.de (S.P.Zeidler) Date: Sat, 5 Jun 2010 21:13:32 +0200 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20100605191331.GX23124@serpens.de> Thus wrote michael.dillon at bt.com (michael.dillon at bt.com): > If everyone just publishes their experiences on their blogs, then > a newcomer who tries to make use of that information on a slightly > different network will run into problems. If everybody just wrote on one English-language wiki, a rather large audience would be left completely uninformed. May I remind you that other languages exist and not everyone running computers speaks English? regards, spz -- spz at serpens.de (S.P.Zeidler) From michael.dillon at bt.com Mon Jun 7 11:20:28 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 7 Jun 2010 10:20:28 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <20100605191331.GX23124@serpens.de> References: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> <20100605191331.GX23124@serpens.de> <28E139F46D45AF49A31950F88C497458063E0155@E03MVZ2-UKDY.domain1.systemhost.net> <20100607185410.GE23124@serpens.de> <28E139F46D45AF49A31950F88C4974580644923C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20100608093518.GI23124@serpens.de> Thus wrote michael.dillon at bt.com (michael.dillon at bt.com): > > All these don't try to tell people that they must not create resources > > in > > a different language. > > I have never seen anyone tell people that they must not create > resources in a different language. Perceptions on this differ a lot. The thread is not going to profit the list IMO, so I'm taking it off. regards, spz From mir at ripe.net Tue Jun 8 12:44:08 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 08 Jun 2010 12:44:08 +0200 Subject: ARIN's new whois -- Coming Improvements to ARIN's Whois DirectoryService In-Reply-To: <28E139F46D45AF49A31950F88C497458063DFEA9@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458063DFEA9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4C0E1EF8.7000408@ripe.net> Hi Michael, Thanks for the suggestion. The RIPE NCC has also implemented a database API in the form of a RESTful Web Service. You can find a description on RIPE Labs: Introduction to the RIPE Database API: http://labs.ripe.net/content/ripe-database-api We are working to integrate other sources into this service. Currently you can query for data originated in the APNIC and the AfriNIC database. We are now also looking to integrate data with source ARIN. Because of the different data formats this is not that trivial, but we will be working with the engineers at ARIN to find a solution. Kind Regards, Mirjam K?hne RIPE Labs at RIPE NCC ------------------------- P.S.: In addition to the announcement above, we published a number of follow-ups after that: RIPE Database Query API Including Search: http://labs.ripe.net/content/ripe-database-query-api-including-search RIPE Database Query API Update: http://labs.ripe.net/content/ripe-database-query-api-update Updates to the RIPE Database Query API and Search Clients: http://labs.ripe.net/content/updates-ripe-database-query-api-and-search-clients michael.dillon at bt.com wrote: > I don't know how widely ARIN distributes these notices, but for anyone > interested in improving the whois system, there are a couple of URLs > here where you can try ARIN's new whois and read some documentation > about it. It would be interesting for RIPE labs to deploy a trial whois > server that matches the ARIN spec to see if WHOIS-RWS is easily > adaptable outside of ARIN or not. > > > -----Original Message----- > From: arin-announce-bounces at arin.net > [mailto:arin-announce-bounces at arin.net] On Behalf Of Member Services > Sent: 04 June 2010 16:05 > To: arin-announce at arin.net > Subject: [arin-announce] Coming Improvements to ARIN's Whois > DirectoryService > > ARIN is pleased to announce that it plans to deploy an improved Whois > service called Whois-RWS on 26 June 2010. Included in the deployment are > > the following services that provide the general public with access to > ARIN's registration data. > > * a RESTful Web Service (RWS) > * a NICNAME/WHOIS port 43 service > * a user-friendly web site (http://whois.arin.net) > > A demo of this service has been available since October 2009. The > demonstration service will be available at > http://whoisrws-demo.arin.net until the production service is deployed > on 26 June 2010. > > When using Whois-RWS you will notice some differences in behavior for > certain queries and corresponding result sets on the NICNAME/WHOIS port > 43 service. ARIN will make a separate announcement on 11 June when it > publishes detailed documentation on these differences along with the > demonstration service update. > > ARIN continues to welcome community participation on the Whois-RWS > mailing list, and we invite you to subscribe and share your thoughts and > > suggestions at: > http://lists.arin.net/mailman/listinfo/arin-whoisrws > > More detailed information on these changes and other future features > that may impact the community at ARIN is available at: > https://www.arin.net/features/ > > Regards, > > Mark Kosters > Chief Technical Officer > American Registry for Internet Numbers (ARIN) > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. From mtinka at globaltransit.net Wed Jun 9 00:38:49 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 9 Jun 2010 06:38:49 +0800 Subject: The use of RIPng In-Reply-To: References: <201006042251.13517.mtinka@globaltransit.net> Message-ID: <201006090638.50089.mtinka@globaltransit.net> On Friday 04 June 2010 11:47:14 pm Benedikt Stockebrand wrote: > So do I. And with OSPFv3/IPv6 you have to do so anyway. No, you don't. The highest IPv4 (Loopback) address on the router will be used as the Router ID. Leaving it non-deterministic may be risky, but valid. > At least here in Germany those ISPs and hosting providers > that offer IPv6 tend to offer IPv6 on a "no guarantees" > basis only, giving both their customers and themselves a > chance to get their hands dirty. Gert, is this true :-) - just curious, not out to crucify, hehe? In our case, we don't offer IPv4 access to the Internet "guaranteed" anyway. We guarantee that it will work in as far as forwarding it through our network is concerned (which is easy to guarantee), but not after it leaves our network. This is well-understood across the community. In that respect, IPv6 is not different, for us. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100609/35381af5/attachment.bin From tedm at ipinc.net Wed Jun 9 02:06:23 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Jun 2010 17:06:23 -0700 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <20100605191331.GX23124@serpens.de> References: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> <20100605191331.GX23124@serpens.de> Message-ID: <4C0EDAFF.3040707@ipinc.net> On 6/5/2010 12:13 PM, S.P.Zeidler wrote: > Thus wrote michael.dillon at bt.com (michael.dillon at bt.com): > >> If everyone just publishes their experiences on their blogs, then >> a newcomer who tries to make use of that information on a slightly >> different network will run into problems. > > If everybody just wrote on one English-language wiki, a rather large > audience would be left completely uninformed. May I remind you that > other languages exist and not everyone running computers speaks English? > From 1997 University of Brunei : http://www.tribunes.com/tribune/art97/wooda.htm "...Whatever method we may use to measure the growth in science, whether it be number of journals, number of articles, number of patents, it is clear that the trend is still inexorably upwards. And increasingly the language of publication is English...." From 2004 Associated Press: http://www.msnbc.msn.com/id/4387421/ "...?English is likely to remain one of the world?s most important languages for the foreseeable future..." "...English has become the dominant language of science, with an estimated 80 percent to 90 percent of papers in scientific journals written in English, notes Scott Montgomery in a separate paper in the same issue of Science. That?s up from about 60 percent in the 1980s, he observes...." From 2008 Live Journal: http://kvarko.livejournal.com/64285.html "...Over the past 80 years, there has been a steady increase in the proportion of scientific publications written in English and a corresponding decrease in the use of all other languages for global scientific communication...." And finally from 2007 NYT: http://www.nytimes.com/2007/04/10/world/europe/10iht-engbiz.2.5212499.html "...We understand that economics is a discipline, like most scientific fields, where the research is published in English," the petition read, in apologetic tones. But it declared that it is "unacceptable" for a native French professor to teach standard courses to French-speaking students in the adopted tongue of English..." In other words, IN FRANCE, we have NATIVE FRENCH, teaching NATIVE FRENCH students - IN ENGLISH. So OK, I GET that there is this thing called Political Correctness that causes us to want to make a nod to languages other than English. But THE FACT IS THAT THE ENGLISH LANGUAGE IS EVERYONE'S CONVENIENT LANGUAGE. Like it or not, there are fundamental advantages to using a SINGLE language in the diplomatic, scientific, economic and technological realm. Nobody is saying that native languages need to go away and be replaced. But what non-English speakers have discovered is that in any relations between other non-native speakers, you have 2 choices, learn THEIR language (unacceptable since they don't have to then expend effort learning yours) or learn a 3rd party language since then they have to learn it too and your both even. English is a convenient language for this. Imagine getting a native speaker of, say Arabic, to speak Hebrew as a second language. That's why Israelis and Muslims use English when they communicate with each other. Ted From michael.dillon at bt.com Wed Jun 9 10:21:44 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 9 Jun 2010 09:21:44 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <4C0EDAFF.3040707@ipinc.net> References: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net><20100605191331.GX23124@serpens.de> <4C0EDAFF.3040707@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C4974580644991E@E03MVZ2-UKDY.domain1.systemhost.net> [irrelevant SCIENCE references deleted] > But THE FACT IS THAT THE ENGLISH LANGUAGE IS EVERYONE'S CONVENIENT > LANGUAGE. Actually, your references only demonstrate that English is convenient for the few people who form part of the scientific elite which engage in publishing research and teaching. Even that is probably still a minority of scientists. Here in the real world of network operations we see things like this If you can't read Russian, it translates as "Cisco translated into Russian its CCNA and CCENT certification programmes". > Like it or not, there are fundamental advantages to using a SINGLE > language in the diplomatic, scientific, economic and technological > realm. In the diplomatic realm English-speaking government officials make a point of using their native language with translators when they meet, such as the UN Security Council. A notable exception was when Vladimir Putin and Angela Merkel of Germany met without translators because both were fluent in German and Russian. In the technological realm, the few who can manage good English, spend some of their time translating documents into their native language or presenting at conferences in their native language. You, however, being handicapped by not speaking several languages, cannot see this even though it is blatantly obvious to the rest of us. Let's all remember that we need to get everybody to deploy IPv6 in order to achieve the network effects which make the Internet such a valuable tool. And to do that, someone needs to speak their language and teach them. Best practices should be widely available in as many languages as possible, and if we can manage to collect them in one place, and publicise the collection, then other people will do the translating work. We don't have to organize that; we just have to collect the best practices of IPv6 in the first place. --Michael Dillon From nick at foobar.org Wed Jun 9 13:30:49 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 09 Jun 2010 12:30:49 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <4C0EDAFF.3040707@ipinc.net> References: <28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>

<28E139F46D45AF49A31950F88C497458063DFA2F@E03MVZ2-UKDY.domain1.systemhost.net> <28E139F46D45AF49A31950F88C497458063DFA89@E03MVZ2-UKDY.domain1.systemhost.net> <20100605191331.GX23124@serpens.de> <4C0EDAFF.3040707@ipinc.net> Message-ID: <4C0F7B69.4020708@foobar.org> On 09/06/2010 01:06, Ted Mittelstaedt wrote: > So OK, I GET that there is this thing called Political Correctness that > causes us to want to make a nod to languages other than English. > > But THE FACT IS THAT THE ENGLISH LANGUAGE IS EVERYONE'S CONVENIENT > LANGUAGE. http://www.cafepress.com/cp/customize/product.aspx?number=454037293 Nick From me at benedikt-stockebrand.de Wed Jun 9 13:33:40 2010 From: me at benedikt-stockebrand.de (Benedikt Stockebrand) Date: Wed, 09 Jun 2010 11:33:40 +0000 Subject: The use of RIPng In-Reply-To: <201006090638.50089.mtinka@globaltransit.net> (Mark Tinka's message of "Wed, 9 Jun 2010 06:38:49 +0800") References: <201006042251.13517.mtinka@globaltransit.net> <201006090638.50089.mtinka@globaltransit.net> Message-ID: Hi Mark and list, Mark Tinka writes: > On Friday 04 June 2010 11:47:14 pm Benedikt Stockebrand > wrote: > >> So do I. And with OSPFv3/IPv6 you have to do so anyway. > > No, you don't. sorry, should have written with OSPFv3/IPv6-*only*. Thought it was obvious from the context. > The highest IPv4 (Loopback) address on the router will be > used as the Router ID. Leaving it non-deterministic may be > risky, but valid. This is a rather risky approach indeed: Eventually you disable IPv4 entirely on a machine and all of a sudden your IPv6 routing fails. Setting up these kinds of hidden dependencies sometimes helps on a short term basis but tends to cause significant trouble in the future. >> At least here in Germany those ISPs and hosting providers >> that offer IPv6 tend to offer IPv6 on a "no guarantees" >> basis only, giving both their customers and themselves a >> chance to get their hands dirty. > > In our case, we don't offer IPv4 access to the Internet > "guaranteed" anyway. I didn't write "guaranteed Internet access". There are things like fine print in standard contracts ("Allgemeine Gesch?ftsbedingungen" in German), or individually negotiated SLAs (service level agreements), or similar legal agreements, that cover various details, including various aspects of network connectivity. And in these, IPv4 and IPv6 tend to be treated rather differently. > We guarantee that it will work in as far as forwarding it through > our network is concerned (which is easy to guarantee), but not after > it leaves our network. At least here in Germany you frequently find statements there concerning "redundant (upstream) Internet connectivity" (not a legally exact translation, IANAL) in SLAs or standard fine print. That may not apply to you, though. > This is well-understood across the community. Stop treating me like an idiot. > In that respect, IPv6 is not different, for us. If you have - the same upstream connectivity - the same level of experience and skills through your entire operations team - the same levels of reliability and functionality with regard to your equipment with both IPv4 and IPv6, then IPv6 may be no different than IPv4. But these are assumptions that don't generally apply. As a consequence it is only prudent for ISPs or hosters to distinguish between IPv4 and IPv6 in whatever contracts and SLAs they sign. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/ From mir at ripe.net Wed Jun 9 14:08:46 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 09 Jun 2010 14:08:46 +0200 Subject: "IPv6 Ripeness" follow-up measurements on RIPE Labs Message-ID: <4C0F844E.7070503@ripe.net> [apologies for duplicates] Dear colleagues, As a follow-up to the IPv6 Ripeness measurements done earlier (http://labs.ripe.net/content/ipv6-ripeness), we did some more analysis and looked at the age and size of the LIRs and the industry sector they are in. Please find the details on RIPE Labs: http://labs.ripe.net/content/ipv6-ripeness-sequel As always, any comments or suggestions are welcome. You can send us email or post your comments in the forum: http://labs.ripe.net/content/ipv6-ripeness-0 Kind Regards, Mirjam K?hne RIPE NCC From js at yllq.net Wed Jun 9 15:28:29 2010 From: js at yllq.net (Mateusz Pawlowski) Date: Wed, 09 Jun 2010 14:28:29 +0100 Subject: IPv6 cookbook - was RA vs. DHCPv6 discussion In-Reply-To: <4C0EDAFF.3040707@ipinc.net> References: "<28E139F46D45AF49A31950F88C4974580637EDE9@E03MVZ2-UKDY.domain1.systemhost.net> <0B45F6CC-23BE-4DC2-9364-BCF7B7C0A5E4@ed.ac.uk> <28E139F46D45AF49A31950F88C4974580637F0CE@E03MVZ2-UKDY.domain1.systemhost.net> <302A476A-A092-4448-AB63-E7AC32303AB0@ecs.soton.ac.uk>