Re: Thoughts on best practice for naming router infrastructure in DNS
On Friday 15 June 2007 00:27, Olsen, Jason wrote: So, what practices do you folks follow? What are the up and downsides you encounter? At my previous employer, we came up with a formula that we were happy with. For reverse DNS, it involves: * defining the interface * defining the device function * defining the local location * defining the international location o device interface could be: fa-0-0-0 gi-1-0-0 s0-0-0 pos-1-0 tun0 this also takes subinterfaces into account; for cases where we've had to classify a switch VI the routes IP traffic: vlan100 o device function could be: br-gw (border router) cr-gw (core router) cr-sw (core switch) edge-gw (edge router) edge-sw (edge switch) o device local location; we normally define this using the IATA 3-letter international city/airport code: LAX (Los Angeles ABV (Abuja) DXB (Dubai) CPH (Copenhagen) MEL (Melbourne) HKG (Hong Kong) it is not uncommon to have towns or cities being abbreviated by the locals in some other way, either because they do not care for the IATA code :-), or if they do, are not included in the IATA database; in this case, you may use your imagination; for us, depending on the length of the name, we spell out the full town's name. o device international location is easily defined if your TLD is based on a country, e.g., .uk, .ae, .ke, .za, .na, e.t.c. for situations where your domain name would end in a non-region specific TLD, e.g., .com, .net, .org, e.t.c., one would prefix a state or country (in the case of a global network) to the domain name, e.g.: .uk.somelargenetwork.com .za.somelargenetwork.com things could get interesting if you setup multiple PoP's in another location that would still fall under your .com or other such TLD, but there are ways to fix that :-). So, a final example of, say, core router number 5 and edge switch number 3 located in a datacentre of a local Australian ISP in Melbourne: gi-0-0-1.cr-gw-5-mel.somenetworknetwork.com.au vlan876.edge-sw-3-mel.somenetwork.com.au Say a large network, whose home network was the US, decided to setup a single PoP in Johannesburg that included one core router and one border router, but whose domain name ended in .net, it would look something like this: pos-3-0.cr-gw-1-jnb.za.somelargenetwork.net gi-0-0-1.br-gw-1-jnb.za.somelargenetwork.net You could then use the script Joe Abley kindly posted earlier to automatically generate your entries. Of course, this was our own approach. Different folks have different strokes. Hope this helps. Cheers, Mark.
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -Original Message- From: Andy Davidson [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl [EMAIL PROTECTED] Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote: That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites? I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On Thu, 28 Jun 2007 16:00:36 BST, Alexander Harrowell said: 1. IPv4 address space is a scarce resource and it will soon be exhausted. 2. It hasn't run out already due to various efficiency improvements. 3. These are themselves limited. 4. IPv6, though, will provide abundant address space. 5. But there's no incentive to change until enough others do so to make it worthwhile. 6. Economists call this a collective action problem. Traditional solutions include legislation, market leadership, and agreements among small actors to achieve such leadership. 7. RFC2827 flame-fests on NANOG have gotten boring. Let's have them for IPv6 instead. :) pgp7Vw5gavXU5.pgp Description: PGP signature
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
multihoming is simple, you get an address block and route it to your upstreams. the policy surrounding that is another debate, possibly for another group this thread is discussing how v4 to v6 migration can operate on a network level Steve On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -Original Message- From: Andy Davidson [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl [EMAIL PROTECTED] Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote: That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites? I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. Best Regards, Christian -- Sent from my BlackBerry. -Original Message- From: Stephen Wilcox [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:55:06 To:Christian Kuhtz [EMAIL PROTECTED] Cc:Andy Davidson [EMAIL PROTECTED], [EMAIL PROTECTED], Donald Stahl [EMAIL PROTECTED], nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 multihoming is simple, you get an address block and route it to your upstreams. the policy surrounding that is another debate, possibly for another group this thread is discussing how v4 to v6 migration can operate on a network level Steve On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -Original Message- From: Andy Davidson [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl [EMAIL PROTECTED] Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote: That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites? I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
In ARIN you have a policy to request IPv6 PI. So what is the problem ? Regards, Jordi De: Christian Kuhtz [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Fri, 29 Jun 2007 13:37:23 + Para: Andy Davidson [EMAIL PROTECTED], [EMAIL PROTECTED], Donald Stahl [EMAIL PROTECTED] CC: nanog@nanog.org Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -Original Message- From: Andy Davidson [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl [EMAIL PROTECTED] Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote: That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites? I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
RE: The Choice: IPv4 Exhaustion or Transition to IPv6
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Oberman Sent: Thursday, June 28, 2007 1:15 PM To: Stephen Wilcox Cc: John Curran; nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 Date: Thu, 28 Jun 2007 17:42:47 +0100 From: Stephen Wilcox [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi John, I wasnt specifically thinking of reclamation of space, I was noting a couple of things: - that less than 50% of the v4 space is currently routed. scarcity will presumably cause these non-routed blocks to be: :- used and routes :- reclaimed and reassigned :- sold on Some of it, but a large part of the missing space belongs to the US Government, mostly the military. It is very much in use and is routed carefully such that it does not show up in the public Internet. It might be replaced with RFC1918 space, but I'm not sure that there is enough 1918 space to do the job as the address space needed is quite large. Also, some is used where 1918 space certainly could be used, but I have spoken with those responsible to ask them to move to 1918 space and the answer is an unequivocal NO, not now or ever. I don't understand this, but I know it exists. One research lab has multiple /16s and several are used by classified nets that lack any external connectivity. While these are wasted, getting them back is essentially impossible. --- Sorry for the horrid formatting, but LookOut is corp. standard. As for your claim that these are wasted, I take issue with this. I have connectivity to several different classified networks, and all of them are segregated, but they DO have gateways so that specific things can pass between them. There isn't enough 1918 space to reconcile the number to .gov and contractor sites on these networks without hitting collisions, and they can't be aggregated despite overlap (like I said at the beginning, we have several coming in...) because they aren't all at the same classification level (which is why they have strictly controlled gateways between them). Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED]
6to4 and Teredo relays deployment
Some weeks ago I started to work in documenting how to setup 6to4 and Teredo relays/servers in several platforms for the afripv6-discuss mailing list. There are many 6to4 relays already, but it becomes even more important to have them where the bandwidth is more expensive, because it avoids traffic going thru upstream links. The first message on this is here: https://lists.afrinic.net/pipermail/afripv6-discuss/2007/61.html More information about 6to4 also available at: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 Similarly for Teredo: https://lists.afrinic.net/pipermail/afripv6-discuss/2007/80.html And more info about Teredo at: http://www.ipv6tf.org/index.php?page=using/connectivity/teredo Regards, Jordi ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
steve. multihoming is simple, you get an address block and route it to your upstreams Hey, that's a very simplistic IGP point of view !! I'm afraid I disagree :) On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. steve. multihoming is simple, you get an address block and route it to your upstreams. steve. steve. the policy surrounding that is another debate, possibly for another group steve. steve. this thread is discussing how v4 to v6 migration can operate on a network level steve. steve. Steve steve. steve. On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: steve. Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. steve. -- steve. Sent from my BlackBerry. steve. steve. -Original Message- steve. From: Andy Davidson [EMAIL PROTECTED] steve. steve. Date: Fri, 29 Jun 2007 14:27:33 steve. To:Donald Stahl [EMAIL PROTECTED] steve. Cc:nanog@nanog.org steve. Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. steve. steve. steve. steve. On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. steve. That's the thing .. google's crawlers and search app runs at layer steve. 7, v6 is an addressing system that runs at layer 3. If we'd (the steve. community) got everything right with v6, it wouldn't matter to steve. Google's applications whether the content came from a site hosted steve. on a v4 address, or a v6 address, or even both. steve. If Google does not have v6 connectivity then how are they going to steve. crawl those v6 sites? steve. steve. I think we're debating from very similar positions... steve. steve. v6 isn't the ideal scenario of '96 extra bits for free', because if steve. life was so simple, we wouldn't need to ask this question. steve. steve. Andy steve. steve.
v6 multihoming (Re: The Choice: IPv4 Exhaustion or Transition to IPv6)
Hi Christian, I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 22 routes reduce to 25000. The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. So in what way is v6 destroying DFZ? Steve On Fri, Jun 29, 2007 at 02:13:50PM +, Christian Kuhtz wrote: Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. Best Regards, Christian -- Sent from my BlackBerry. -Original Message- From: Stephen Wilcox [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:55:06 To:Christian Kuhtz [EMAIL PROTECTED] Cc:Andy Davidson [EMAIL PROTECTED], [EMAIL PROTECTED], Donald Stahl [EMAIL PROTECTED], nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 multihoming is simple, you get an address block and route it to your upstreams. the policy surrounding that is another debate, possibly for another group this thread is discussing how v4 to v6 migration can operate on a network level Steve On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: Until there's a practical solution for multihoming, this whole discussion is pretty pointless. -- Sent from my BlackBerry. -Original Message- From: Andy Davidson [EMAIL PROTECTED] Date: Fri, 29 Jun 2007 14:27:33 To:Donald Stahl [EMAIL PROTECTED] Cc:nanog@nanog.org Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 On 29 Jun 2007, at 14:24, Donald Stahl wrote: That's the thing .. google's crawlers and search app runs at layer 7, v6 is an addressing system that runs at layer 3. If we'd (the community) got everything right with v6, it wouldn't matter to Google's applications whether the content came from a site hosted on a v4 address, or a v6 address, or even both. If Google does not have v6 connectivity then how are they going to crawl those v6 sites? I think we're debating from very similar positions... v6 isn't the ideal scenario of '96 extra bits for free', because if life was so simple, we wouldn't need to ask this question. Andy
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
Christian, On Jun 29, 2007, at 10:13 AM, Christian Kuhtz wrote: If you want to emulate IPv4 Given IPv6 is IPv4 with 96 more bits (or, if you prefer 16 more bits from the ISP perspective), why would you assume there is a choice? and destroy the DFZ, I'm not sure what destroy the DFZ means. The DFZ will get bigger, no question. Routing flux will go up. Routers will have to work harder. Router vendors will be happy. However, I'm not sure how that could be interpreted as destroyed. Just call it the Everglades and move on. Yes, it sucks and is painfully stupid, but we've been here before around the mid 90's. Same solutions apply. In any event, the IPv4 free pool will be exhausted soon. We're looking at gobs of NAT or vast tracts of swamp. Actually most likely both. You ready? Rgds, -drc
Re: Thoughts on best practice for naming router infrastructure in DNS
On Fri, 29 Jun 2007 16:35:09 BST, Neil J. McRae said: I remember in the past an excellent system using Sesame Street characters names. This only works in small shops. If you have more routers than muppets, you have a problem. Had a lab once where we named machines after colors. That hit some snarls when we discovered nobody in the lab could consistently spell 'fuschia', 'mauve', or 'paisley'. :) pgpK13iUeNEgu.pgp Description: PGP signature
Re: v6 multihoming (Re: The Choice: IPv4 Exhaustion or Transition to IPv6)
Hi Steve, Sure... I've never mention 3 STM4... the example said 3 carriers. OK, you may do it with communities, but if you advertise all in just one prefix, even with communities, I find it very difficult to control the trafic when it pass through 2 or more AS (it may be quite easy for the peer AS, but what about the other ASs)? Nicolas. On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. Hi Nicolas, steve. you will never make 2GB of traffic go down one STM4 or even 3x STM4! steve. steve. But you are asking me about load balancing amongst 3 upstreams... steve. steve. Deaggregation of your prefix is an ugly way to do TE. If you buy steve. from carriers that support BGP communities there are much nicer steve. ways to manage this. I've never deaggregated and I have had and do steve. have individual prefixes that generate more traffic than any steve. single GE link. steve. steve. Steve steve. steve. On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote: steve. Hi Stephen, steve. steve. Supose you have STM4 links, ok? steve. And you have 2G of trafic from your 10 ADSL customers, ok? steve. And those STM4 go to 3 dif carriers in USA. steve. Then, how you advertise only one IPv6 prefix to all and make the 2G go steve. trough one STM4 ? steve. steve. steve. On Fri, 29 Jun 2007, Stephen Wilcox wrote: steve. steve. steve. steve. steve. Hi Christian, steve. steve. I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated. steve. steve. steve. steve. If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 22 routes reduce to 25000. steve. steve. steve. steve. The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there. steve. steve. steve. steve. So in what way is v6 destroying DFZ? steve. steve. steve. steve. Steve steve. steve. steve. steve. On Fri, Jun 29, 2007 at 02:13:50PM +, Christian Kuhtz wrote: steve. steve. steve. steve. Amazink! Some things on NANOG _never_ change. Trawling for trolls I must be. steve. steve. steve. steve. If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial. And you should go ahead and plan that migration. steve. steve. steve. steve. As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem. steve. steve. steve. steve. So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting. steve. steve. steve. steve. Best Regards, steve. steve. Christian steve. steve. steve. steve. -- steve. steve. Sent from my BlackBerry. steve. steve. steve. steve. -Original Message- steve. steve. From: Stephen Wilcox [EMAIL PROTECTED] steve. steve. steve. steve. Date: Fri, 29 Jun 2007 14:55:06 steve. steve. To:Christian Kuhtz [EMAIL PROTECTED] steve. steve. Cc:Andy Davidson [EMAIL PROTECTED], [EMAIL PROTECTED], Donald Stahl [EMAIL PROTECTED], nanog@nanog.org steve. steve. Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. steve. steve. steve. steve. steve. multihoming is simple, you get an address block and route it to your upstreams. steve. steve. steve. steve. the policy surrounding that is another debate, possibly for another group steve. steve. steve. steve. this thread is discussing how v4 to v6 migration can operate on a network level steve. steve. steve. steve. Steve steve. steve. steve. steve. On Fri, Jun 29, 2007 at 01:37:23PM +, Christian Kuhtz wrote: steve. steve. Until there's a practical solution for multihoming, this whole discussion is pretty pointless. steve. steve. steve. steve. -- steve. steve. Sent from my BlackBerry. steve. steve. steve. steve. -Original Message- steve. steve. From: Andy Davidson [EMAIL PROTECTED] steve. steve. steve. steve. Date: Fri, 29 Jun 2007 14:27:33 steve. steve. To:Donald Stahl [EMAIL PROTECTED] steve. steve. Cc:nanog@nanog.org steve. steve. Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6 steve. steve. steve. steve. steve. steve. steve. steve. steve. steve. On 29 Jun 2007, at 14:24, Donald Stahl wrote: steve. steve. steve. steve.That's the thing .. google's crawlers and search app runs at layer steve. steve.7, v6 is an addressing system that runs at layer 3. If we'd (the steve. steve.community) got everything right with v6, it wouldn't matter to steve. steve.Google's applications whether the content came from a site hosted steve. steve.on a v4
