Re: IPv6 end user addressing
On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote: I'm sure there will be platforms that end up on both sides of this question. I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib... given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake. YES: We made a less expensive box by cutting the width of the TCAM required in half NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed. I'm sure the market will chose products from both sides of the line for the same reasons. Owen On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the slow path as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? If true, it would make /64s even more attractive. -Randy - Original Message - we assign /112 per end user vlan (or server) at this moment... works perfectly fine (and thats even a bit too big). - nobody wants to use dynamic ips on -servers- or -router links- anyway i -really- can't see why people don't just use subnets with just the required number of addresses. take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size) etc. no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;) we don't use /24's for -everything- on ipv4 now do we :P (oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Mon, 8 Aug 2011, Owen DeLong wrote: On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews ma...@isc.org wrote: So you want HE to force all their clients to renumber. No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough. Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise: There has been some rather simplistic arithmetic posted today, 300m new subnets per year, etc. with zero consideration of address/subnet utilization
Re: IPv6 end user addressing
It's at least true of how some of the Cisco platforms cope with IPv6 access lists. Owen On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote: On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote: I'm sure there will be platforms that end up on both sides of this question. I know of no asic in a switch that claims to support ipv6 that does it this way... That would tend to place you at a competitive disadvantage to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that way... it's easier I imagine to simply reduce the size of the fib... given that switches routinely have to forward to neighbors on /126 or /127 prefix links I think that would be something of a mistake. YES: We made a less expensive box by cutting the width of the TCAM required in half NO: We spared no expense and passed the costs (and a nice profit margin) on to you so that you can do whatever you like in IPv6 at wire speed. I'm sure the market will chose products from both sides of the line for the same reasons. Owen On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote: I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the slow path as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument? If true, it would make /64s even more attractive. -Randy - Original Message - we assign /112 per end user vlan (or server) at this moment... works perfectly fine (and thats even a bit too big). - nobody wants to use dynamic ips on -servers- or -router links- anyway i -really- can't see why people don't just use subnets with just the required number of addresses. take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size) etc. no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;) we don't use /24's for -everything- on ipv4 now do we :P (oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called RIP , which also only seemed to understand /24 or bigger ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Mon, 8 Aug 2011, Owen DeLong wrote: On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote: On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews ma...@isc.org wrote: So you want HE to force all their clients to renumber. No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned addressing * /48 per access customer You can simply read the last few messages in this thread to learn that his recommendations on this list are not even practical for his network today, because as Owen himself says, they are not yet able to obtain additional RIR allocations. HE certainly operates a useful, high-profile tunnel-broker service which is IMO a very great asset to the Internet at-large; but if you spend a few minutes looking at the publicly available statistics on this service, they average only around 10,000 active tunnels across all their tunnel termination boxes combined. They have not implemented the policies recommended by Owen because, as he states, a /32 is not enough. Do I think the position he advocates will cause the eventual exhaustion of IPv6? Well, let's do an exercise: There has
Re: US internet providers hijacking users' search queries
On Mon, Aug 8, 2011 at 11:52 PM, David Conrad d...@virtualized.org wrote: Chris, On Aug 8, 2011, at 2:56 PM, Christopher Morrow wrote: messing with basic plumbing will have unintended consequences, they will be bad. If the users her WANT to have this experience, there are lots of in-browser/application methods to achieve this, hijacking DNS at the resolver is really just NOT the right answer, ever. See that ship off on the horizon? It appears to have sailed... doesn't mean I can't be the cranky old man shaking my fist, right? I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective. yea... so that, so I understand, depends a lot on who's telling the tale. From one source at an ISP doing this, the revenues are not anywhere near what was promised by the vendor(s). Anyway, I'm not sure what they are, we probably won't ever know what they really are :( I suppose it'll continue as long as people consider it 'ok' to be subjected to this and don't leave their ISP for an alternative. (where available!) Oh, maybe dns-sec will help us with this problem too? nsec3 to the rescue?
Re: IPv6 end user addressing
Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam. Alternatively, if your corporate email imposes stupid policies and / or a stupid email client (note: it's possible to quote properly and not top-post with Outlook, it's just hard work), don't subscribe to mailing lists from your corporate email. Of all the mailing list communities, I'd expect this one not to struggle very much with arranging an alternative... Regards, Tim.
Re: IPv6 end user addressing
Once upon a time, Jimmy Hess mysi...@gmail.com said: If you must not have someone plugging into your server LAN without permission, you turn unused ports off, or preferably, place them in a VLAN island with no topological connection to anything. That's about what I do; unused ports are in a different VLAN. I have a separate LAN for notebooks, etc. that has DHCP (and will have a v6 /64 when I get v6 to that point). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
IPv6 Hackers mailing-list
Folks, We have created the IPv6 Hackers mailing-list for discussion of IPv6 security issues and low-level issues. The charter of the list is: cut here This list was created for the discussion of IPv6 security issues and low/packet-level issues related to the IPv6 protocols. It is meant to provide forum for IPv6 security researchers and IPv6 networking professionals to discuss low-level IPv6 networking and security issues that could eventually lead to advances and improvements in the area of IPv6 security and IPv6 networking. Discussion of unrelated networking or security topics are considered off topic. Subscription to the list is open to the community. cut here You can subscribe to the mailing-list here: http://lists.si6networks.com/listinfo/ipv6hackers/ Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: IPv6 end user addressing
On Tue, 09 Aug 2011 11:24:03 +1200, Jonathon Exley said: Silly confidentiality notices are usually enforced by silly corporate IT departments and cannot be removed by mere mortal employees. They are an unavoidable part of life, like Outlook top posting and spam. They may all three be things that we continually receive from clueless netizens. However, it is not at all difficult for anybody clued enough to get subscribed to NANOG to find ways to avoid inflicting all three on the rest of us. pgpgSTYWyhxo0.pgp Description: PGP signature
ISP support for use of 4-byte ASNs in peering
Folks - Is there a public list somewhere of service providers that do not support 4-byte autonomous system numbers when peering? (if not, should there be one?) At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. Thoughts? /John John Curran President and CEO ARIN
Re: ISP support for use of 4-byte ASNs in peering
On 09/08/2011 14:47, John Curran wrote: At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. At INEX, we see 60% of IXP connections which can handle ASN32 natively. However, INEX is a small IXP and I haven't seen similar figures from other IXPs which could validate this 60/40 split. Having said that, in the IXP world most new service providers connect into route servers, so there is often no perceived requirement for direct ASN32-ASN16 interconnection - the intersection of new service providers and ASN32 holders is quite large. And if you really want a bilateral peering relationship, there's no reason not to use AS23456. Thoughts? - interior BGP community management is great fun with an ASN32, oh yes. - i don't have much sympathy for people who whine about not being able to support ASN32 peerings. There is no good reason for this these days. - from personal experience, I understand why ASN32 is less popular. However, it's certainly usable. Nick
Re: ISP support for use of 4-byte ASNs in peering
While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support. -Michael On 8/9/2011 9:24 AM, Nick Hilliard wrote: On 09/08/2011 14:47, John Curran wrote: At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. At INEX, we see 60% of IXP connections which can handle ASN32 natively. However, INEX is a small IXP and I haven't seen similar figures from other IXPs which could validate this 60/40 split. Having said that, in the IXP world most new service providers connect into route servers, so there is often no perceived requirement for direct ASN32-ASN16 interconnection - the intersection of new service providers and ASN32 holders is quite large. And if you really want a bilateral peering relationship, there's no reason not to use AS23456. Thoughts? - interior BGP community management is great fun with an ASN32, oh yes. - i don't have much sympathy for people who whine about not being able to support ASN32 peerings. There is no good reason for this these days. - from personal experience, I understand why ASN32 is less popular. However, it's certainly usable. Nick
Re: (O.T.) The 10 Most Bizarre and Annoying Causes of Fiber Cuts
and the number 1 threat ... suprisingly no Bears! On Tue, Aug 9, 2011 at 1:17 AM, Michael Painter tvhaw...@shaka.com wrote: http://blog.level3.com/2011/08/04/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/
Re: ISP support for use of 4-byte ASNs in peering
On 09/08/2011 15:45, Michael Hare wrote: While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support. the me3400 is a metro core ethernet switch with L3 extensions. It's not intended as a border router. If you use the wrong tool for the job... Nick
Re: ISP support for use of 4-byte ASNs in peering
Aren't there still community issues with 4 byte ASN space as well that have not been resolved? -Blake
Re: ISP support for use of 4-byte ASNs in peering
On 09/08/2011 16:43, Blake Dunlap wrote: Aren't there still community issues with 4 byte ASN space as well that have not been resolved? I think I mentioned that. draft-raszuk-wide-bgp-communities will fix this, but it's unclear when we'll start seeing this rolled out in production code. Nick
Re: ISP support for use of 4-byte ASNs in peering
Granted I've never worked outside academia but the me3400 is otherwise a cost effective gig-e demarc for very simple bgp multihoming. They have made a strategic decision to not implement a simple software update support RFC4893 [it has been 4 years] and to set an artificial price point on entry. Fine, that is their choice. There are other vendors offering 4 byte ASN in simliar products at or near this price point and we'll probably have to move to them. -Michael On 8/9/2011 10:38 AM, Nick Hilliard wrote: On 09/08/2011 15:45, Michael Hare wrote: While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support. the me3400 is a metro core ethernet switch with L3 extensions. It's not intended as a border router. If you use the wrong tool for the job... Nick
v4/v6 dns thoughts?
as i'm rolling v6 into my world, i'm not sure which way to go with reverse dns conventions. for forward i'm doing things like: foo.example.coma1.1.1.1 foo.example.com1000::1.1.1.1 foo.v4.example.coma1.1.1.1 foo.v6.example.com1000::1.1.1.1 so i can use a foo.v4/v6 hostname if i need to specify transit behavior. but for reverse i'm not sure if i want to map it like: 1.1.1.1.in-addr.arpaptrfoo.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptrfoo.example.com or: 1.1.1.1.in-addr.arpaptrfoo.v4.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptrfoo.v6.example.com being able to just use foo.example.com for authentication purposes (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or v6 by just looking at the dns lookup (for tools that do reverse lookup for you) is also nice. what are you doing? which way makes more sense to you?
Re: v4/v6 dns thoughts?
On 2011-08-09 20:47 , Joe Pruett wrote: as i'm rolling v6 into my world, i'm not sure which way to go with reverse dns conventions. for forward i'm doing things like: foo.example.coma1.1.1.1 foo.example.com1000::1.1.1.1 foo.v4.example.coma1.1.1.1 foo.v6.example.com1000::1.1.1.1 You do mean: foo.example.com A 192.0.2.1 foo.example.com 2001:db8::1.1.1.1 foo.v4.example.comA 192.0.2.1 foo.v6.example.com 2001:db8::1.1.1.1 I hope, seeing that 1.1.1.1 is for the APNIC region and 1000::/8 is outside 2000::/3 and thus not defined yet, that you use the documentation prefixes when showing examples instead of abusing that address space, as that is exactly the reason why 1.1.1.1 will most likely never be allocated to anyone but researchers who are seeing all kind of fun backscatter... so i can use a foo.v4/v6 hostname if i need to specify transit behavior. People commonly use the 'ipv4' and 'ipv6' variant for this. Most network-specific tools though fortunately have -4/-6, but as indeed quite a few don't it is always handy to have the above. [..] being able to just use foo.example.com for authentication purposes (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or v6 by just looking at the dns lookup (for tools that do reverse lookup for you) is also nice. Tools that do reverse lookups should always also report the IP address as without the IP a reverse is futile unless said tool does at least a ip-reverse-forward check and then of course the hope is that that hostname does not disappear between that lookup happening and it going away again... what are you doing? which way makes more sense to you? Map it to the hostname. This as it should not matter if it is IPv4 or IPv6. For routers of course one might want to use a v4/v6 specific one as per the above reason of 'easier for the eyes in traceroute', but on the other side one could just as well use an IPv4+IPv6 per interface and thus name them based on the interface Greets, Jeroen
not operational -- call for nominations for ARIN council board
gentlefolk, ARIN is the community's self-generated steward for internet numbering resources (ip addresses and autonomous system numbers) and it is governed by volunteers from the community who serve on its advisory council and executive board. every year ARIN holds an election to fill or renew several expiring terms. candidates need not be ARIN members. please see https://www.arin.net/announcements/2011/20110725_elec.html and think about whether who you can nominate or whether you can self- nominate. paul vixie chairman, 2011 arin nomcom
Re: v4/v6 dns thoughts?
On Aug 9, 2011, at 11:47 AM, Joe Pruett wrote: as i'm rolling v6 into my world, i'm not sure which way to go with reverse dns conventions. for forward i'm doing things like: foo.example.coma1.1.1.1 foo.example.com1000::1.1.1.1 foo.v4.example.coma1.1.1.1 foo.v6.example.com1000::1.1.1.1 so i can use a foo.v4/v6 hostname if i need to specify transit behavior. but for reverse i'm not sure if i want to map it like: 1.1.1.1.in-addr.arpaptrfoo.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptrfoo.example.com or: 1.1.1.1.in-addr.arpaptrfoo.v4.example.com. 1.0.1.0.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.ip6.arpa ptrfoo.v6.example.com being able to just use foo.example.com for authentication purposes (sendmail, nfs, etc) is nice. but also knowing when incoming is v4 or v6 by just looking at the dns lookup (for tools that do reverse lookup for you) is also nice. what are you doing? which way makes more sense to you? My PTRs are all to the same host name. In any context where the protocol actually matters, you should have other ways to detect it. I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's really no advantage to do it. Most tools either have separate IPv4/IPv6 variants or have command-line switches for address-family control if you care. Owen
NANOG Board Announcement
I am sad to announce that Robert Seastrom has resigned from the NewNOG Board of Directors, effective yesterday. Rob has served on the Steering Committee, transition team, and the board for the past three years, and has provided valuable insight and assistance throughout the transition of NANOG to a standalone organization. I thank Rob for his service to the community, and look forward to his continued participation as a member. Since this creates a vacancy on the board with more than two months remaining until the next election, the Bylaws require the remaining board members to appoint a temporary replacement to serve until the election. At that time, a permanent replacement will be elected to fill the remainder of Rob's term, which ends in October 2012. Accordingly, the board has selected Michael K. Smith to fill the vacant position between now and the October Election. Mike has been serving as Communications Committee chair for a few years, as well as assisting with budgeting, technical planning, and many other behind-the-scenes tasks during the transition. Please join me in thanking Rob for his service, and in welcoming Mike to the board. Thanks, Steve Feldman, chair
Re: v4/v6 dns thoughts?
On 9 August 2011 16:36, Owen DeLong o...@delong.com wrote: My PTRs are all to the same host name. In any context where the protocol actually matters, you should have other ways to detect it. I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's really no advantage to do it. Most tools either have separate IPv4/IPv6 variants or have command-line switches for address-family control if you care. I agree that using the v4 or v6 tag in forward or reverse is pointless. One can tell it is v4 or v6 by the result of the lookup and the hostnames don't change just because they are accessible via IPv6. If a hostname is directly related to the fact that its IPv6 by all means put it in there though. -- Landon Stewart lstew...@superb.net SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more Ahead of the Rest: http://www.superbhosting.net
I'm missing 2 bytes (GRE implementation)
I'm using a GRE IPv4 tunnel between a cisco and linux machines I did some packet capture, and saw that my MTU was 1418, but the cisco was sending TCP packet with a MSS of 1380. This created a bunch of issues. When I told the cisco box to use a MSS of 1378 everything starting to work fine. So why Cisco is off by 2 Bytes? Does the GRE implementation on Linux uses 2 extra bytes compared to Cisco (or vice versa)?
Re: I'm missing 2 bytes (GRE implementation)
Everything from checksums, keys, and sequence numbers is optional. The only required fields IIRC amount to 2 bytes of overhead. Sounds like they both interpret what should be included in the GRE header slightly differently. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. - Reply message - From: Franck Martin fmar...@linkedin.com Date: Tue, Aug 9, 2011 5:57 pm Subject: I'm missing 2 bytes (GRE implementation) To: nanog@nanog.org nanog@nanog.org I'm using a GRE IPv4 tunnel between a cisco and linux machines I did some packet capture, and saw that my MTU was 1418, but the cisco was sending TCP packet with a MSS of 1380. This created a bunch of issues. When I told the cisco box to use a MSS of 1378 everything starting to work fine. So why Cisco is off by 2 Bytes? Does the GRE implementation on Linux uses 2 extra bytes compared to Cisco (or vice versa)?
RE: v4/v6 dns thoughts?
I too agree the v4/v6 stuff is pointless and slightly annoying so I have been using same name with A/ records. -Original Message- From: Landon Stewart [mailto:lstew...@superb.net] Sent: Tuesday, August 09, 2011 6:16 PM To: nanog@nanog.org Subject: Re: v4/v6 dns thoughts? On 9 August 2011 16:36, Owen DeLong o...@delong.com wrote: My PTRs are all to the same host name. In any context where the protocol actually matters, you should have other ways to detect it. I also don't recommend doing the foo.v4/foo.v6 thing in your forwards. There's really no advantage to do it. Most tools either have separate IPv4/IPv6 variants or have command-line switches for address-family control if you care. I agree that using the v4 or v6 tag in forward or reverse is pointless. One can tell it is v4 or v6 by the result of the lookup and the hostnames don't change just because they are accessible via IPv6. If a hostname is directly related to the fact that its IPv6 by all means put it in there though. -- Landon Stewart lstew...@superb.net SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more Ahead of the Rest: http://www.superbhosting.net
