IPv6 isn't SMTP
Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP! Please explain my misunderstanding on the following: 1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like). 2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations] 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one’s own combat boots. And not particularly productive. I look forward to furthering my education. James R. Cutler james.cut...@consultant.com PGP keys at http://pgp.mit.edu signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Mon, Dec 9, 2013 at 9:49 AM, Randy Bush ra...@psg.com wrote: http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on? According to Comcast’s DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=iso=1e=0d3=1tier=-1sc=84, the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I’m not optimistic. I opted for my minimal-effort solution. I installed a Motorola SB6121 and a 5th gen Airport Extreme and turned them on. Of course I configured the Airport Extreme with a name, management password, and confirmed IPv6 was set to to configure Automatically and Native. When the Comcast drop was plugged in and Comcast authorized the modem, I had a multistacked LAN. Going on 11 months of IPv4/IPv6 service. I’ve had about 1 hour of downtime. James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 9, 2013, at 12:32 PM, Gary Buhrmaster gary.buhrmas...@gmail.com wrote: On Mon, Dec 9, 2013 at 4:51 PM, Cutler James R james.cut...@consultant.com wrote: According to Comcast’s DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=iso=1e=0d3=1tier=-1sc=84, the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I’m not optimistic. Are you sure you are looking at the correct page? The DPC3008 shows are supported with IPv6 to me, and since I am using it, it does seem to work The DPC3000, on the other hand is not supported. Oops, I slipped up or down a line scanning across the page. I am now more optimistic. Cutler signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 9, 2013, at 12:32 PM, Gary Buhrmaster gary.buhrmas...@gmail.com wrote: On Mon, Dec 9, 2013 at 4:51 PM, Cutler James R james.cut...@consultant.com wrote: I opted for my minimal-effort solution. I installed a Motorola SB6121 and a 5th gen Airport Extreme and turned them on. Of course I configured the Airport Extreme with a name, management password, and confirmed IPv6 was set to to configure Automatically and Native. When the Comcast drop was plugged in and Comcast authorized the modem, I had a multistacked LAN. Going on 11 months of IPv4/IPv6 service. I’ve had about 1 hour of downtime. Not having the device, but a friend does (who has asked about IPv6 support), does the Airport Extreme support prefix delegation with a separate guest IPv6 delegation from the non-guest address? When I looked at the Apple forums, I only saw questions, no answers regarding that support. Gary My testing on OS X Mavericks shows that an Airport5,117 with firmware 7.6.4 creates the guest wireless network: 1. With an IPv4 address from an automatically assigned RFC1918 LAN connected through NAT to WAN. 2. With NO IPv6 addressing of any kind. My conclusion is that Apple does not yet support IPv6 in any fashion for Wireless Guest networks. James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 9, 2013, at 3:37 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 9 Dec 2013, Cutler James R wrote: My conclusion is that Apple does not yet support IPv6 in any fashion for Wireless Guest networks. Works for me on 7.7.2 on the latest hardware (802.1ac version with time capsule hdd). PD and everything. -- Mikael Abrahamssonemail: swm...@swm.pp.se This is not unusual for Apple. Apple often does not support what seem to be firmware improvements on earlier hardware. For example, the first generation GB Ethernet Airport Extreme does not support native IPv6 from the WAN provider. Connection to Comcast IPv6 drove upgrading to the latest and greatest Airport Extreme available at that time. This is disappointing to me as a user but good for me as an Apple stockholder - James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 9, 2013, at 4:06 PM, Jared Mauch ja...@puck.nether.net wrote: On Dec 9, 2013, at 3:51 PM, Cutler James R james.cut...@consultant.com wrote: This is disappointing to me as a user but good for me as an Apple stockholder I stopped using their [network] hardware and shifted to using real Access-Points do perform that function. I support too many people using the Apple Ecosystem to not maintain my own instance. My only third-party tool is a configuration file analysis shell script. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ATT UVERSE Native IPv6, a HOWTO
On Dec 2, 2013, at 5:14 PM, Tony Hain alh-i...@tndh.net wrote: Ricky Beam wrote: On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom r...@seastrom.com wrote: So there really is no excuse on ATT's part for the /60s on uverse 6rd... Except for a) greed (we can *sell* larger slices) and b) demonstrable user want/need. How many residential, home networks, have you seen with more than one subnet? The typical household (esp Uverse) doesn't even customize the provided router. Even a CCIE friend of mine has made ZERO changes to his RG -- ATT turned off WiFi and added the static block at install. (I know NANOG is bad sample as we're all professionals and setup all kinds of weird configurations at home. I have 3 nets in continuous use... a legacy public subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping that network (because it's too small), and a second RFC1918 net from a second ISP) I wouldn't use the word generous, but a /60 (16 LANs) is way more than what 99% of residential deployments will need for many years. We've gotten by with a single, randomly changing, dynamic IP for decades. Until routers come out-of-the-box setup for a dozen networks, non-networking pros aren't going to need it, or even know that it's possible. (and the default firewalling policy in Windows is going to confuse a lot of people when machines start landing in different subnets can see each other.) Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4... the difference is, we won't be around when people are cursing us for the way we mismanaged early allocations. Indeed, a /64 is too little (aka bare minimum) and far too restrictive, but it works for most simple (default) setups today. Which leads to DHCPv6 PD... a /60 is adequate -- it's the minimal space for the rare cases where multiple nets are desirable or necessary. The option for /56 or even /48 should exist (esp. for business), but the need for such large address spaces are an EXCEPTION in residential settings. (and those are probably non-residential users anyway.) [FWIW, HE.net does what they do as marketing. And it works, btw.] The rant above represents a braindead short-sighted thought process. If you focus on the past as justification for current actions, you guarantee that the future will always look exactly like the past. If you even hint at a /64 as the standard for residential deployment, you will find that all the CPE vendors will hard code that, and you will never get it undone when you change your mind. All because you stated up front that they will only ever need what they have been using in the past. You don't see multi-subnet residential today from the consumer viewpoint, but they do widely exist supporting deployment of watch your dvr from any set-top, where a premise subnet handles that traffic off of the consumer lan. That one example is why there should NEVER be a /64, because you are already at 2 subnets that should be using the same shorter prefix. Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable. A /55 makes more sense for a topology with moderate constraints, but if you are already shorter than a 56, it doesn't make sense to stop there. This is a hard concept for professional network engineers, because their market place value is based on the ability to efficiently manage topologies to fit within address resource constraints. Consumers have no desire to understand the technology, they just want to plug stuff together and have it sort out what it needs to do. That unconstrained topology coupled with unmanaged device automation requires excess address resource. YES THAT IS A WASTE. But having the address space sitting on the shelf at IANA when someone comes along with a better idea in the next few hundred years is also a waste. Get over it, the address space excessively larger than we will ever deploy so it is wasted ... The only open issue is how we utilize the resource until the next thing comes along. If it sits on the shelf, you constrain innovation. If you 'waste it' by deploying it before people can really use it, you piss-off the existing engineering staff. From my perspective, the latter will die off, but stifling innovation robs future generations of capabilities they could/should have had to make the world a better place. Tony My kudos to Tony for an excellent summary. The only thing he missed is the tremendous waste of people resources involved in micro-managing
Re: ATT UVERSE Native IPv6, a HOWTO
On Dec 3, 2013, at 12:04 AM, Eric Oosting eric.oost...@gmail.com wrote: On Mon, Dec 2, 2013 at 11:11 PM, Rob Seastrom r...@seastrom.com wrote: Ricky Beam jfb...@gmail.com writes: On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom r...@seastrom.com wrote: So there really is no excuse on ATT's part for the /60s on uverse 6rd... ... Handing out /56's like Pez is just wasting address space -- someone *is* paying for that space. Yes, it's waste; giving everyone 256 networks when they're only ever likely to use one or two (or maybe four), is intentionally wasting space you could've assigned to someone else. (or **sold** to someone else :-)) IPv6 may be huge to the power of huge, but it's still finite. People like you are repeating the same mistakes from the early days of IPv4... There's finite, and then there's finite. Please complete the following math assignment so as to calibrate your perceptions before leveling further allegations of profligate waste. I know this is rhetorical, but my hobby is answering peoples rhetorical questions. Suppose that every mobile phone on the face of the planet was an end site in the classic sense and got a /48 (because miraculously, the mobile providers aren't being stingy). Very well, I'll play your silly game. 48 bits remaining. Now give such a phone to every human on the face of the earth. 33 bits should do it. That gets us to nearly 9 billion people. 15 bits remaining. Unfortunately for our conservation efforts, every person with a cell phone is actually the cousin of either Avi Freedman or Vijay Gill, and consequently actually has FIVE cell phones on active plans at any given time. 5 is inconvenient. Lets give everyone 8 mobil phones, using 3 bits. 12 bits remaining. Assume 2:1 overprovisioning of address space because per Cameron Byrne's comments on ARIN 2013-2, the cellular equipment providers can't seem to figure out how to have N+1 or N+2 redundancy rather than 2N redundancy on Home Agent hardware. 1 bit for that. 11 bits remaining. Now we're assigning space out of 2000::/3 for now ... lets keep the other 7/8ths of the ipv6 address block in reserve, using another 3 bits ... leaving ... carry the one ... 8 bits. What percentage of the total available IPv6 space have we burned through in this scenario? Show your work. If we give every man, woman, and child on the face of the earth the equivalent to (16) /48s each, we'll will have used 1/256th of the first 1/8th of the IPv6 address space. Wolfram says there have been 110 billion homo sapiens that have ever lived. We need to give every person who has literally ever lived on planet earth their own /40 before we've used up 2000::/3, and need to move on to the remaining 87.5% of the address space. (this is where someone will ding me for the misuse of literally somehow with a pointer to theoatmeal comic, right) -e -r Does this mean we can all get back to solving real IPv6 deployment and operations problems? I certainly hope you all can finally see which is the better business choice between: 1. Using up to around 10% of IPv6 space to make our network operations simpler for the next twenty years or more. 2. Continuing to spend time and money on micromanagement of addressing rather than real customer needs. One who cannot properly understand the business decision here perhaps should not be debating network policies. — “Strongly worded letter to follow. James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Reverse DNS RFCs and Recommendations
On Nov 6, 2013, at 9:02 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven¹t come to grips with it just yetŠ ;-) When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users. Jason On 11/5/13, 12:31 AM, Lee Howard l...@asgard.org wrote: http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this. Lee Dynamic DNS providers will undoubtably endeavor to make money from and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary and PTR records highly unlikely. Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users. It’s dead, Jim James R. Cutler james.cut...@consultant.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: comcast ipv6 PTR
On Oct 9, 2013, at 12:35 PM, Blair Trosper blair.tros...@gmail.com wrote: Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses? Which IPv6 addresses: 1 delegated WAN address? 2 end systems on delegated LAN prefix or with static assignments? In my experience with Comcast Business Internet: 1 the delegated WAN address does have an (almost useless) PTR record which is essentially the spelled backward. 2 PTR records for automatically configured end systems on a local LAN are a local responsibility. Static IP assignments may come with PTR entries, depending on business arrangements. Since neither Comcast or any other DNS provider has any direct knowledge of your local network configuration, you cannot expect to see any PTR DNS records for local systems unless you make some business (and technical) arrangements with a DNS provider. If you really need PTR record for your local SMTP servers, arrange for them with your DNS provider, even if that provider is you. James R. Cutler james.cut...@consultant.com
Re: minimum IPv6 announcement size
I try not to think about sinners too much when planning networks. Subnets are more interesting. Maybe many of you like spending time maintaining NAT configurations and creatively masking as determined by today's end system count on each subnet. This all, of course, in the interest of maximum address assignment efficiency, a term of only the most nebulous definition. Hogwash, I say. The days of counting end systems in order to determine addressing is GONE. And I, for one, am much pleased. Let's optimize the person instead of micro-optimizing bits. Count the subnets you really think you need, shift one or two bits left, and ask for /whatever as described by Owen. many many years is probably multiples of the two decades or so of IPv4 we have experienced. Continuing arguments on NANOG and elsewhere about /64 - Good or Bad - check one, are just wasting your time and mine. Get yourself into action and just get IPv6 deployed. Owen has the right of it. Cutler On Oct 1, 2013, at 4:20 PM, Owen DeLong o...@delong.com wrote: The original plan was to go from 32 to 64 bits total. The additional 64 bits were added purely for the sake of EUI-64 based addressing, and really, 64 bits of network number is way more than enough. The /64 a are not what justify the larger blocks. That's IPv4 think. In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. Owen On Oct 1, 2013, at 12:11, Ryan McIntosh rmcint...@nitemare.net wrote: I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol.. In all seriousness though (and after skimming some of the other responses), I absolutely understand the ideals and needs amongst conserving memory on our routers for the sake of the future of bgp and internal routing. The problem I described has nothing to do with that however, I was mearly pointing out the fact that the basis of the larger allocations are based upon the fact we're handing over /64's to each vlan/point to point/lan/etc that we're turning up. In practice, I understand, a /64 means that 64 bits can handle a unique ip for every host without having to worry about numbering them, but how many hosts do we truly think will be sitting on one network? Surely not a /64's worth, that alone would cause havoc on a neighbor table's maximum memory limit. Maybe I'm missing the connection here, but I still don't see how a /64 is justified for each individual user/host/server/etc sitting on the edge of the internet that's getting ip's from an upstream provider (not arin/ripe/etc). It's those smaller blocks that justify handing over larger ones, which I do understand there's plenty of, but how long are we going to patch the same problem and not try to fix it right? Ryan On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon larryshel...@cox.net wrote: On 9/27/2013 1:10 AM, Ryan McIntosh wrote: I don't respond to many of these threads but I have to say I've contested this one too only to have to beaten into my head that a /64 is appropriate.. it still hasn't stuck, but unfortunately rfc's for other protocols depend on the blocks to now be a /64.. It's a waste, even if we're planning for the future, no one house needs a /64 sitting on their lan.. or at least none I can sensibly think of o_O. Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: iOS 7 update traffic
On Sep 26, 2013, at 5:22 PM, Mark Lancaster markl...@gmail.com wrote: I have heard a lot of questions and debate about whether the iOS updates download automatically: “Available updates download automatically if your device is connected to Wi-Fi and a power source.” http://support.apple.com/kb/HT4623 http://support.apple.com/kb/HT4623 /mark The wording in step 2 is poorly done. The availability of updates is what is downloaded. Step 3 indicates an active user input to begin download is required.
Re: iOS 7 update traffic
On Sep 19, 2013, at 2:11 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: Why does apple feel it is okay to send every mobile device an update on a single day? Apple does not send updates. The user device must request an update. --As a side note, IOS 7 fixes/improves iDevices in multiple areas, making it a compelling upgrade. James R. Cutler james.cut...@consultant.com
Re: iOS 7 update traffic
On Sep 19, 2013, at 3:10 PM, Fred Reimer frei...@freimer.org wrote: I was making the wrong assumption that people understood how the Internet works. Absolutely! Most people understand that the internet works by use of a browser and are content with that knowledge. Much like most motor vehicle operators understand accelerator, brake, steering, and gas pump, with no knowledge of thermodynamics, much less physics or traffic laws. James R. Cutler james.cut...@consultant.com
Re: Paetec PI space?
On Jun 26, 2013, at 1:52 PM, Adam Greene maill...@webjogger.net wrote: Hi, We have a customer who was assigned some PI IPv4 space by Paetec back in mid-90's and who has continued to announce the blocks, even though their relationship with Paetec ended a long time ago. Is this a common situation? No data either way. Does the customer risk having that space reclaimed by Paetec at some point What does the contract say? , or is it safe to assume they will continue to be able to route trouble-free for years to come? It is never save to assume anything, but especially not save to assume trouble-free for years to come. Thanks, Adam
Re: looking for terminology recommendations concerning non-rooted FQDNs
A domain name without a terminal dot is a relative domain name. -- An application requesting name to address translation gets to decide if a search list is to be used, including the default of dot. A domain name with a terminal dot is a Fully Qualified Domain Name. -- An application requesting name to address translation must submit the name as received to the lookup process. These definitions have been effective of decades and do not need additional terminology. -- Faulty implementations are not an excuse for ever more complex terminology. As a side note, a hostname is usually a domain name. A domain name is never necessarily a hostname. For example, the hostname command on my mini returns minijim, while the domain name used to reach my mini locally is minijim.local, but that is not my mini's hostname. But my mini's name to address lookup mechanism uses protocols other than DNS to figure that out. But, new terminology for hostnames or domain names was never required. James R. Cutler james.cut...@consultant.com
Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....
On Jan 30, 2013, at 12:43 PM, joel jaeggli joe...@bogus.com wrote: As a product of having a motorola sb6121 and a netgear wndr3700 both of which I bought at frys I have ipv6 in my house with dhcp pd curtesy of commcast. If it was any simpler somebody else would have had to install it. Except that Apple Airport Extreme users must have one of the newer hardware versions, that is my experience as well. And, even before Comcast and new AEBS, Hurricane Electric removed all other excuses for claiming no IPv6.
Fwd: Big day for IPv6 - 1% native penetration
On 11/26/2012 03:18 PM, Dobbins, Roland wrote: Apple and Microsoft are application developers as well as OS vendors. How much of a priority do you think IPv6 capabilities are to their application development organizations? How much of a priority do you think IPv6 capabilities are to their customer bases? How much of a priority do you think IPv6 capabilities are for corporate IT departments, beyond a checklist item on RFPs in order to CYA? Where are the IPv6-only SQL Server deployments within enterprises, for example? In fact, where are the IPv6-enabled client access LANs within enterprises? Or even the *plans* for these types of deployments/capabilities? How much of a priority? I would say lots for Apple. Have you looked at the current Apple software? It pretty much just works on IPv6. IPv6 is on by default on end systems. Airport Extreme is listed as IPv6 compatible by, among other companies, Comcast. In Terminal, open an New Remote Connection to another Mac, do netstat -f inet6 and see that it is an IPv6 connection. Actually, it is more than a priority. It is pretty much a done deal. As for corporate IT departments, it depends on whether management is measured on monthly cash flow or by long term growth. I must note that many corporate IT departments have evolved from No one gets fired for buying IBM. to One might get fired for not buying Microsoft. This also automatically brings along IPv6 capabilities. DIGRESSION Elsewhere it has been said that end users don't care about IPv6. Well, that is generally true. They also don't care about IPv4, DOCSIS 3, ATM, PPPOE, and lots of other technical acronyms. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. To meet these expectations in a long term cost-effective manner, it behooves us network and content providers to remove all IPv4-forced hacks impeding easy end-system to end-system connections like all those 'wonderful' variants of NAT and artificially high pricing for IPv6. When the marketing folks begins to treat IPv6 as a sales enabler rather than a fanciful cost item, then we may see accelerated deployment of IPv6 alongside IPv4. /DIGRESSION
Re: Big day for IPv6 - 1% native penetration
On Nov 26, 2012, at 7:47 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 27, 2012, at 7:27 AM, Cutler James R wrote: Have you looked at the current Apple software? It pretty much just works on IPv6. Yes, but it doesn't do or enable anything via IPv6 that it doesn't do or enable via IPv4. This also automatically brings along IPv6 capabilities. Capabilities deployment. Again, the most energy almost all enterprise IT departments are putting into IPv6 is to include an undefined 'IPv6-capable' checkbox on RFPs. That's it. What they do care about is reliable sharing of gossip, pictures, and videos. They also care about reliable video chats with friends and family. And it is these 'killer apps' which have driven the global deployment of IPv4 and the growth of the modern commercial IPv4-based public Internet, as well as the near-universal adoption of IPv4 transport within private networks. The huge economic benefits of mobile voice and data connectivity are the reasons behind its spectacular growth and increasing ubiquity. Mobile voice and data allow people to do things that they simply couldn't do before, and to do things which they didn't even view as possibilities before. My contention is that in order for IPv6 to become widely deployed within any foreseeable time-frame, it may well prove that there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6 in order to provide the requisite economic stimulus. Well, at least you and I agree that IPv6 and IPv4 are simply Layer 3 protocols. Regarding there must be some content/services/applications which are a) greatly desired by users and b) only available via/possible with IPv6, your viewpoint ignores the millions and millions of end users/systems which will join networks around the globe in the near future. Those content/services/applications will only be reachable via IPv6 because that is all that can be deployed without truly horrendous and costly mismanagement of IPv4 address space. From a longer-than-next-month business viewpoint, it is more cost effective to deploy IPv6 than to continue the crude IPv4 hacks previously mentioned. Please note that this does not imply instant turndown of existing IPv4.
Re: Typical additional latency for CGN?
On Oct 7, 2012, at 4:56 PM, George Herbert george.herb...@gmail.com wrote: Ancedotally, for users of an e-gadget company's website, cellphone company's outbound web proxies, internet games company, and image-intensive home furnishings website, the CGNs delivered content faster than the main website could, regardless of increasing its bandwidth. Latency problems with the CGNs were less than the main websites' latency problems, on the average. There were days that was not true, and days we had to re-re-re-reset the CGN contents, and the day the @#$#@$% game programmers screwed up the CGN calls, but on the whole it was among the least performance limiting / impeding features of the sites in question. -george On Sun, Oct 7, 2012 at 1:47 PM, Tom Limoncelli t...@whatexit.org wrote: Have there been studies on how much latency CGN adds to a typical internet user? I'd also be interested in anecdotes. I've seen theoretical predictions but by now we should have measurements from early-world deployments. Thanks, Tom -- Speaking at MacTech Conference 2012. http://mactech.com/conference http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my videos Huh? I had presumed that CGN was Carrier Grade NAT, not a proxy service. Help me understand. James R. Cutler james.cut...@consultant.com
Re: IPv4 address length technical design
On Oct 6, 2012, at 2:35 PM, Barry Shein b...@world.std.com wrote, in part: We can map from host names to ip addresses to routing actions, right? So clearly they're not unrelated or independent variables. There's a smooth function from hostname-ipaddr-routing. I would suggest that this is a bit optimistic and oversimplified. The mapping between DNS names and IP addresses is not necessarily unique or commutative. One may change either arbitrarily, as long some directory service exists which contains the current mapping. In addition, multiple DNS names may map to one or more IP addresses and IP addresses do not necessarily map to unique routes or DNS names. These are not smooth functions. If names and addresses are not independent, then any change in either would predicate a change in the another. That is apparently not the experience of most network providers. The only action required for a change in network name or address is to update the directory service used to map between name and address. Is this a good use of DNS computrons? Answering DNS inquiries for every new connection for every single-routed host on the internet? Yes, it is. Most new connections are repeats of previous connections (I request mail from my IMAP servers several times each day) and the preponderance of caching resolvers make the effort and traffic trivial. Even in the absence of cached final DNS reply, putting the lookup burden on the end system rather than the routing engines should be a no-brainer. In particular, adding caching of connection destinations within routing components would not only seriously burden (read, slow down) routing engines but is also a violation of the Stupid Network. David S Isenberg said, In a Stupid Network, control passes from the center to the edge. See http://www.isen.com/papers/Dawnstupid.html, originally published as the cover story of ACM Networker 2.1, February/March 1998, pp. 24-31.
Re: IPv4 address length technical design
On Oct 4, 2012, at 4:00 PM, William Herrin b...@herrin.us wrote: On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R james.cut...@consultant.com wrote: On Oct 3, 2012, at 6:49 PM, Jimmy Hess mysi...@gmail.com wrote: In 100 years, when we start to run out of IPv6 addresses, possibly we will have learned our lesson and done two things: (1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no Netmasks, Prefix lengths, or other comingling of network addresses and host address spaces. And (2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP, with a convention of a specified length, instead of a hardwired specific limit that comes from using a permanently fixed-width field. I suggest that the DNS name space should be considered to be an hierarchical host address space thus satisfying (1) and making (2) moot. I'd suggest that too, but we'd have to throw out TCP, UDP and a good chunk of the BSD sockets API to get there. Or did you mean use DNS as it fits in the current system, which doesn't actually satisfy (1) at all since the layer 4 protocols continue to build the connection identity from the layer 3 network identity instead of the external host/service identity. Regards, Bill Herrin Yes. Why does the connection identity have to include the host identifier. Is that not a problem under the control of applications?
Re: IPv4 address length technical design
On Oct 3, 2012, at 4:17 PM, Dave Crocker d...@dcrocker.net wrote: Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? ... Actually that was preceded by RFC 760, which in turn was a derivative of IEN 123. I believe the answer to the original question is ... My theory is that there is a meta-rule to make new address spaces have 4 times as many bits as the previous generation. We have three data points to establish this for the Internet, and that's the minimum needed to run a correlation: Arpanet, IPv4, IPv6... d/ Didn't work for DecNet Phase III, Decnet Phase IV, Decnet Phase V (8, 16, 128).
Re: IPv4 address length technical design
On Oct 3, 2012, at 6:49 PM, Jimmy Hess mysi...@gmail.com wrote: On 10/3/12, Jay Ashworth j...@baylink.com wrote: So the address space for IPv8 will be... /troll In 100 years, when we start to run out of IPv6 addresses, possibly we will have learned our lesson and done two things: (1) Stopped mixing the Host identification and the Network identification into the same bit field; instead every packet gets a source network address, destination network address, AND an additional tuple of Source host address, destination host address; residing in completely separate address spaces, with no Netmasks, Prefix lengths, or other comingling of network addresses and host address spaces. And (2) The new protocol will use variable-length address for the Host portion, such as used in the addresses of CLNP, with a convention of a specified length, instead of a hardwired specific limit that comes from using a permanently fixed-width field. Need more bits? No protocol definition change required. Cheers, -- jra -- -JH I suggest that the DNS name space should be considered to be an hierarchical host address space thus satisfying (1) and making (2) moot.
Re: RFC becomes Visio
On Sep 28, 2012, at 10:41 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: SNIP/ The proper approach is to ask the vendor for RFC 1149 trasport for the BGP session, and whether it terminates in a shared cage, or if a fully private one is required. Including an 'envionmental impact statement'. Explaining that this info is required in order to produce an accurate Visio diagram. Ladies and gentlemen, it seems that we have a winner!
Re: really nasty attacks
On Sep 27, 2012, at 12:12 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Sep 27, 2012, at 11:34 , Stephane Bortzmeyer bortzme...@nic.fr wrote: On Thu, Sep 27, 2012 at 08:55:58AM -0600, Miguel Mata mm...@intercom.com.sv wrote a message of 30 lines which said: Guys, No gals on NANOG? Many. Although in fairness, some people use guys in a gender-neutral manner. See, for example, Sesame Street.
Re: RIRs give out unique addresses (Was: something has a /8! ...)
On Sep 20, 2012, at 10:56 AM, Naslund, Steve snasl...@medline.com wrote: Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I certainly would not say that. I would say that I get addresses from the RIRs to avoid address collisions with other network operators using the same approach. And, please note this well, address collisions affect more than Layer three routing. See all the previous mentions of application gateways. James R. Cutler james.cut...@consultant.com
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 19, 2012, at 9:24 AM, John Osmon jos...@rigozsaurus.com wrote: On Wed, Sep 19, 2012 at 12:07:33AM -0500, Jimmy Hess wrote: Assume you have a public IPv4 assignment, and someone else starts routing your assignment... legitimately or not, RIR allocation transferred to them, or not. There might be a record created in a database, and/or internet routing tables regarding someone else using the same range for a connected network. But your unconnected network, is unaffected. Ahh... But the network may not be unconnected. Just because *you* don't have a path to it doesn't mean others are similarly disconnected. All of those others would be affected. You are going to have a hard time getting a court to take your case, if the loss/damages to your operation are $0, because your network is unconnected, and its operation is not impaired by someone else's use, and the address ranges' appearance in the global tables. Think about a company that has thousands of private interconnects with other companies. Unique address space would remove the chance of RFC1918 space clash, and any of the bad effects of NAT. (e.g The network *works* as it was originally designed.) Such a network would not have $0 in loss/damage when the partners can't reach it due to a rogue announcement. The Internet is not the same from all viewpoints. This discussion is repeating ones heard hear in the mid 1990s. Having a block of IP addresses not seen in YOUR IP routing tables is NOT evidence of unused addresses. For example, an inter-network SMTP relay correctly forwards messages via MX DNS entries only if unique IP address exist on both sides of the relay. This is just one example of application level gateways used to isolate networks at Layer 3 that has been in use for decades. As noted above, there are many instances of private interconnects which rely on assigned integers to tag destinations in a globally unique fashion. In the case of IP addressing, IANA and the various registries provide this globally unique assignment service. Use of these unique integers for packet routing is left as an exercise for the Network Engineer. IANA and the registries are not in the business of directly policing the use of any assigned integers. Those of us who have been involved in interconnecting private networks with overlapping IP address assignments are well aware of the pitfalls, hazards, and costs of using non-unique addressing. An entity which uses its ignorance of how addresses are used internally by another entity as an excuse to ignore proper IP address assignment is deliberately contributing to network chaos and to the culture of ignoring rules because we can. The bottom line is that Connected does not mean Routable via IPv4/IPv6. This is in addition to Hidden does not mean Unused as pointed out by others.
Re: The Department of Work and Pensions, UK has an entire /8
On Sep 19, 2012, at 1:42 PM, Jo Rhett jrh...@netconsonance.com wrote: And second, have you ever worked on a private intranet that wasn't connected to the internet through a firewall? Skipping oob networks for equipment management, neither have I. Yes, for many years. External connections only via Application Level Gateways for SMTP, HTTP and Virtual Network connections. And, using assigned IPv4 addresses. And, no one willing to pay for IPv6.
Re: IPv6 Ignorance
On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com
Re: IPv6 Ignorance
On Sep 18, 2012, at 12:57 PM, Jason Baugher ja...@thebaughers.com wrote: On 9/18/2012 11:47 AM, Cutler James R wrote: On Sep 18, 2012, at 12:38 PM, Jason Baugher ja...@thebaughers.com wrote: What about network-based objects outside of our orbit? If we're talking about IPv6 in the long-term, I think we have to assume we'll have networked devices on the moon or at other locations in space. Jason Practical considerations (mostly latency issues) tend to minimize real-time point-to-point connections in these scenarios. I would expect that messaging/relay gateways would play a significant role in Really-Wide Area Networking. This would move inter-networking largely to an application layer, not the network layer. Thus, worrying about Layer 3 addressing limits is probably moot and just a fun waste of NANOG list bandwidth. James R. Cutler james.cut...@consultant.com Considering the rather extensive discussion on this list of using quantum entanglement as a possible future communications medium that would nearly eliminate latency, I don't see how my comment is moot or a waste. Jason Recent work (http://www.quantum.at/quest) has not yet established success over interplanetary distances. Other recent results from aircraft (http://www.extremetech.com/extreme/136312-first-air-to-ground-quantum-network-created-transmits-quantum-crypto-keys) show throughput results in relatively small bits per second. I'll reserve retraction for another year or so.
Re: IPv6 Ignorance
On Sep 18, 2012, at 1:55 PM, Joe Hamelin j...@nethead.com wrote: On Tue, Sep 18, 2012 at 9:47 AM, Cutler James R wrote: ...waste of NANOG list bandwidth. I sure get a chuckle when I read this on a list for people that swing around 10Gb/s pipes all day. That's why I included a word you omitted from the quote -- …fun waste of NANOG list bandwidth. Works for me. Works for you. James R. Cutler james.cut...@consultant.com
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 5:12 PM, Izaac iz...@setec.org wrote: Since tcp25 filtering has been so successful, we should deploy filters for everything except tcp80 and tcp443 and maaaybe tcp21 -- but NAT already does so much to enhance the user experience there already. And what with ISP customers using their provided DNS and mail service exclusively, there's no reason to permit udp53, tcp110, tcp143, tcp993, tcp995 either. Really, only evil people use anything but the web. Any other traffic undoubtedly a bot from which they ought to be protected. Izaac, You do realize that that the NANOG mailing is archived and some helpful person will quote you to their favorite legislator? James R. Cutler james.cut...@consultant.com
Re: IPv6 End User Fee
On Aug 3, 2012, at 3:22 PM, Otis L. Surratt, Jr. o...@ocosa.com wrote: Anyone charging end users for IPv6 space yet? :p snip/ Otis I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. James R. Cutler james.cut...@consultant.com
Re: IPv6 End User Fee
I would say that the typical usage, at least here in the US, is that an End User is the one holding an iPhone or sitting at a computer watching the Olympics, and, ultimately, paying that last mile fee. Even using your definition, the costs of connectivity (routers, wires, management) far exceeds the cost of addressing. Given the quantity of numbers available for IP addressing, it is does not make economic sense to even construct a billing mechanism for IPv6 addressing beyond those of the LIRs, RIRs, etc. Purchase IPv6 connectivity includes the assumption of IPv6 addressing included. On Aug 3, 2012, at 7:32 PM, Otis L. Surratt, Jr. o...@ocosa.com wrote: By end user I mean hosting clients (cloud, collocation, shared, dedicated, VPS, etc.) of any sort. For example you have clients that would needsay /24 for their dedicated server. If you charge a $1.00/IP which is typical then you would lose that revenue if they converted to IPv6. If you didn't charge for IPv4 then you have nothing to to lose. Otis From: Cutler James R [mailto:james.cut...@consultant.com] Sent: Fri 8/3/2012 3:48 PM To: Otis L. Surratt, Jr. Cc: NANOG list Subject: Re: IPv6 End User Fee On Aug 3, 2012, at 3:22 PM, Otis L. Surratt, Jr. o...@ocosa.com wrote: Anyone charging end users for IPv6 space yet? :p snip/ Otis I can't imagine that this would be anything but counterproductive. End users are not interested in IPv6 - most would not recognize IPv6 if it fell out of their screen. End users want working connectivity, not jargon. James R. Cutler james.cut...@consultant.com
Re: EBAY and AMAZON
Examination of the raw messages confirms phishing messages. Visible URLS do not match effective URLs. On Jun 11, 2012, at 2:07 PM, Scott Brim wrote: I think it's a troll, trying to shock you into clicking on something. James R. Cutler james.cut...@consultant.com -top posted by OS X Mail
Re: ipv6 book recommendations?
On Jun 5, 2012, at 5:23 PM, William Herrin wrote: On 6/5/12, David Hubbard dhubb...@dino.hostasaurus.com wrote: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. Hi David, Instead of going the book route, I'd suggest getting some tunneled addresses from he.net and then working through http://ipv6.he.net/certification/ . They have the basics pretty well covered, it's interactive and it's free. Some additional thoughts: 1. Anybody who tells you that there are security best practices for IPv6 is full of it. It simply hasn't seen enough use in the environment to which we're now deploying it and rudimentary technologies widely used in IPv4 (e.g. NAT/PAT to private address space) haven't yet made their transition. 2. Subnetting in v6 in a nutshell: a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) only works for /64. b. Delegations on 4-bit boundaries for reverse-DNS convenience. c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. d. Default customer assignments should be /56 or /48 depending on who you ask. /48 was the IETF's original plan. Few of your customers appear to use tens of LANS, let alone thousands. Maybe that will change but the motivations driving such a thing seem a bit pie in the sky. /56 let's the customer implement more than one LAN (e.g. wired and wireless) but burns through your address space much more slowly. /60 would do that too but nobody seems to be using it. /64 allows only one LAN, so avoid it. e. sparse allocation if you feel like it. The jury is still out on whether this is a good idea. Basically, instead of assigning address blocks linearly, you divide your largest free space in half and stick the new assignment right in the middle. Good news: if the assignment later needs to grow your can probably just change the subnet mask, keeping the number of entries in the routing table the same. Bad news: fragments the heck out of your address space so when you actually need a large address block for something, you don't have it. Trying to keep non-dynamic assignments in local or regional aggregable blocks works about as well as it did in IPv4, which is to say poorly. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 Bill's additional comments about subnetting are a concise and accurate view. They also show and overlooked benefit of IPv6 over IPv4 -- For address planning, it is no longer necessary to count individual end points, rather only the subnets must be counted. This reduces labor in planning, assigning, and tracking addresses. James R. Cutler james.cut...@consultant.com
Re: ipv6 book recommendations?
On Jun 6, 2012, at 9:53 AM, Anton Smith wrote: snip Hi all, Potentially silly question but, as Bill points out a LAN always occupies a /64. Does this imply that we would have large L2 segments with a large number of hosts on them? What about the age old discussion about keeping broadcast segments small? Or, will it be that a /64 will only typically have a similar number of hosts in it as say, a /23|4 in the IPv4 world? Cheers, Anton Now you have deduced the beauty of the scheme. The number of end points does not matter to IPv6 address planning. Said another way - my factory subnet may have a gazillion(1) little machines on one subnet while my data center boxes may have several subnets. Just count the subnets. Let the traffic/technology drive the use per subnet whilst you TRILL(2) a pretty tune. Note (1) Gazillion 2^64 Note (2) Thanks, Radia James R. Cutler james.cut...@consultant.com
Re: Common operational misconceptions
On Feb 17, 2012, at 1:35 PM, Owen DeLong wrote: On Feb 17, 2012, at 6:52 AM, -Hammer- wrote: Let me simplify that. If you are over 35 you know how to troubleshoot. Is this a statement or something to be added to the list of misconceptions that are commonplace out there? Not trying to be flip... Honestly asking the question. I can see it going either way, frankly. ;-) Owen Clearly, it is a misconception. The effect of aging on trouble-shooting skills is simply the opportunity for gaining experience. (Personal anecdotes omitted here. You are welcome.) James R. Cutler james.cut...@consultant.com
Re: Speed Test Results
On Dec 23, 2011, at 8:07 AM, Paul Stewart wrote: In my opinion they are only somewhat reliable if they are on your network or very close to your network -we operate one of the speedtest.net sites and for our own eyeball traffic find it to be a reasonable indicator of what kind of speeds the customer is getting. To put it a different way, if a customer is getting 20X1 Internet service and the speedtest shows 17 X 0.8 then case closed - if they are getting a speedtest result of 5 X 0.5 then our helpdesk will take a further look - this is really in rough terms... Paul From the consumer viewpoint: No single data point should be extrapolated to infinity, but comparing problematic behavior with normal behavior is a standard process across all fields. Speed tests from several locations done regularly give a baseline for performance. Major departure from expected numbers from a set of speed test sites can be regarded as an indicator of local loop problems. Did you know that local loops suffer from backhoe fade? And, DSLAMS fail. In my home office, speed tests are just another useful diagnostic helping to locate problem areas - just like in Paul's example. DSLReports line monitoring service is a similarly useful tool. James R. Cutler james.cut...@consultant.com
Re: Welcome to the Marketing mailing list
On Nov 17, 2011, at 3:47 PM, Jay Ashworth wrote: - Original Message - From: Richard Golodner rgolod...@infratection.com 1. Why was such a list created? 2. Why was I automatically subscribed to it? 3. Why was this done without notice to the community? This has a lot of us wondering the same as Owen. This is also not typical of how NANOG does things. Hopefully as the day progresses we will get some insight. My, but there are a lot of people, in my best friend's favorite phrase, spring loaded to the pissed-off position. I didn't think NANOGers were quite so prone to recreational indignation... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Someone once wrote,approximately, Assume the best possible intentions. Thus, bafflement .ne. spring loaded to the pissed-off position. Regards. James R. Cutler james.cut...@consultant.com smime.p7s Description: S/MIME cryptographic signature
Re: NANOGers home data centers - What's in your closet?
I have not found a fiber-to-Ethernet adapter for sufficiently low cost. If I ever do, backyard Gigabit, here I come. On Aug 12, 2011, at 9:57 PM, Chaim Rieger wrote: What nobody wired their abode with fiber ? Am i the only one here James R. Cutler james.cut...@consultant.com smime.p7s Description: S/MIME cryptographic signature
Re: FTTH CPE landscape
On Aug 4, 2011, at 7:08 PM, Dan Armstrong wrote: On 2011-08-04, at 6:43 PM, Owen DeLong o...@delong.com wrote: On Aug 4, 2011, at 2:55 PM, Dan White wrote: On 04/08/11 14:32 -0700, Owen DeLong wrote: On Aug 4, 2011, at 2:08 PM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com On Aug 4, 2011, at 8:35 AM, Jay Ashworth wrote: - Generic consumer grade NAT/Firewall Hobby horse: please make sure it support bridge mode? Those of us who want to put our own routers on the wire will hate you otherwise. Why? As long as it can be a transparent router, why would it need to be a bridge? Ask a Verizon FiOS customer who wants to run IPv4 VPNs. He didn't say IPv6 only, right? I have a couple of customers who can't get bridge mode on residence FiOS service, and therefore can't run their own routers to terminate IPsec. If they could get routed static IPv4 rather than bridge, why wouldn't they be able to terminate IPSec VPNs? Note I did say TRANSPARENT router. That would mean no NAT and routed static IPv4. For residential use, for users currently requesting one public address, that's a waste of a /30 block (sans routing tricks requiring higher end customer equipment). Multiply that by the number of residential customers you have and that's bordering on mismanagement of your address space. You say waste, I say perfectly valid use. If you're dealing with business customers, then your usage versus wasted ratio is much higher and less of a concern, but what's the point? Are you trying to cut down on a large broadcast domain? Why is it less of a waste to allocate a /30 to a business using a single public IP than it is to a residence? This makes no sense to me. I simply prefer the additional troubleshooting and other capabilities given to me in a routed environment in most cases. Owen Realistically, how many home Internet consumers terminate IPSec VPNs? It seems kind of silly to engineer a network around a tiny fraction of less than 1% of the population, doesn't it? It seems kind of silly to engineer a network against a tiny fraction of less than 1% of the population, doesn't it? James R. Cutler james.cut...@consultant.com smime.p7s Description: S/MIME cryptographic signature
Re: Spam?
On Jul 12, 2011, at 11:02 AM, Thomas Donnelly wrote: I received no spam, and had I received 2 pieces, it may have been slightly irritating. What is irritating is the sheer number of people complaining about it. Can we stop please? I think they get it. -=Tom Tom, you are one of the lucky ones -- I have received over two dozen SPAM via NANOG in the last 24 hours. And, yes, it would be gratifying to know why the change - is the new configuration less expensive? (to the list manager, not us, obviously) Also, where is the reply to header? James R. Cutler james.cut...@consultant.com
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 10:21 PM, George Herbert wrote: On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong o...@delong.com wrote: And like I said before, we have more pressing things to do than tinker some more with DHCPv6. Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal. Right. Please, everyone - this is not just an IPv4 way of thinking. This is different types of networks and network users. Just because your experience and your network don't have anything affected by these issues with DHCPv6 / RA doesn't mean that others don't. IPv6 adoption is driven by exhaustion, but it's limited by glitches like this. -- -george william herbert george.herb...@gmail.com This is different types of networks and network users and also different operational, administrative, and security domains. I am also getting frustrated with the endless discussions that could be immediately shortened by tinkering with DHCP to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity? See these quotes from 2009 and let us collectively get off the dime! On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote: В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа: OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people? After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad. OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up. Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of them are because we're masochistic idiots. -- Regards, Vasil Kolev Following on the comments above: The security domain for HOST should not overlap the security domain for ROUTER. That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! Give the router managers the NTP server addresses and their DHCP forwarding list and leave them alone to produce a robust and reliable transport facility! James R. Cutler james.cut...@consultant.com
The Business Wisdom of trying to fix DHCPv6
James R. Cutler james.cutler at consultant.com Fri Feb 6 18:00:52 UTC 2009 DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the one place in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say just hard code it make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа: OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. James R. Cutler james.cut...@consultant.com
Re: v6 Avian Carriers?
On Apr 1, 2011, at 1:28 PM, Dorn Hetzel wrote: I'm thinking both TCP and UDP, and for ICMP don't NAT's use the sequence number field to keep them separate ? SNIP/ In my experience, the Avian Carriers usually eat the NATs. James R. Cutler james.cut...@consultant.com
Re: What vexes VoIP users?
On Feb 28, 2011, at 1:29 PM, Bret Clark wrote: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I would suggest that the exponential decrease in POTS is driven by cell phones, not VOIP - I just get my cell phone from the store, any store, and use it, almost anywhere. It's just like my land line but without the wire tether. I get wireless without VOIP complications. Of course, we could discuss Long Distance rates for land lines vs cell or Skype (VOIP for almost free). But that is really another discussion. James R. Cutler james.cut...@consultant.com
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Feb 10, 2011, at 12:15 AM, Ricky Beam wrote: On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg nat...@atlasnetworks.us wrote: What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not. That's pretty much the definition of in use. If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me. In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them. --Ricky This dead horse keep coming back for another beating. The purpose of a global registry of numbers is to provide a common source for unique numbers. The definition of in use by internet registries does not require appearance in your routing tables or even in the route servers. Not only that, the users may not even want or need to exchange traffic with you. As a survivor of many network consolidations due to corporate acquisitions, I have many scars from trying to get separate RFC 1918 islands to interwork properly. That is the reason that even so-called private networks need unique IP addressing. And now, since IPv6 is actually being deployed and used, there is absolutely no economic incentive to continue to fight the IPv4 addresses not in my routing table are not 'in use' battle any more. It is a waste of time and money. James R. Cutler james.cut...@consultant.com
Re: My upstream ISP does not support IPv6
All this talk about CPE is wasted until folks like ATT have someone on the retail interface (store, phone, or, web) who even knows what is this IPv6 thing. Exploring this issue with DSL providers and Uverse is like that old exercise with combat boots. It feels much better when I stop. James R. Cutler james.cut...@consultant.com My ISP can't answer the question.
Re: quietly....
On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote: Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. Been there. Done that. Made perfect business sense. The NTP servers were ours and kept excellent time. Oh, we also included the default route. James R. Cutler james.cut...@consultant.com
Re: Network Naming
I recommend documenting your naming standard and getting buy in across your
organization before you put it into place.
This is a necessary condition for successful deployment, but not part of the
schema.
On Jan 25, 2011, at 11:32 PM, David Miller wrote:
On 1/25/2011 8:15 PM, Gary Steers wrote:
James makes a good point...
Pick a scheme which:
1. Uses simple memorable names.
2. Makes business sense to you.
3. You know how to manage (database, publication, updates, etc.
If I had to weight these criteria, I would weight 3 most heavily.
The other key thing to bear in mind is consistency and scalability... (i.e.
design a scope that can grow with your network and needs
{interface/server}.{router/vmhost}.{city}.{country}.example.net
The other thing that doesn't really have any defined list is {city}, Some
people prefer 2 letter, some 3 letter, some people use airport codes etc..
The naming schemes that I have developed that needed to be upgraded in the
past have almost always bumped up against scale, so build in much larger
scale than you ever think that you will need from the beginning. You have X
devices now in Y locations, but your naming scheme should scale to X^Z
devices in Y^Z locations.
I agree that for network gear, this is is a good place to start (slightly
simplified here from above):
{interface}.{host}.{location}.example.net
- Location
I personally prefer UN LOCODEs for country / city. The UN already went to
the trouble of giving a unique code to every country/city. Why do I use
them? LON makes perfect sense as London, England... until you have devices
in London, KY and London, OH (the LOCODES for these Londons are GB LON, US
LDN, US LOZ). In my opinion, airport codes (while certainly unique) work
well in some locales and not so well in others (so, I don't use them, YMMV).
- Host
I prefer, like many do, an acronym denoting the primary function of the
device. ES (edge switch), AR (access router), CR (core router), etc...
whatever your internal terminology is. If you will *ever* have more than 10
of a device anywhere, then I would recommend that you number out of double
digits (more than 100, then out of triple digits...). That way in a sorted
list AR03 will be right between AR02 and AR04, where you expect it to be,
instead of between AR29 and AR30. Standardizing on number length also limits
ambiguity in pressure situations and/or over noisy or less reliable
communication channels.
- Interface
Port names vary on gear from different vendors. {interface type} -
{selector}* ... where selector repeats ordered from highest to lowest level
of granularity (e.g. rack/slot/module/port) is what I use. You should use
whatever makes sense to you. Are interface speeds or vlans important to your
infrastructure? If so, then include them where appropriate. Unless you have
exactly the same gear everywhere, you are going to have to be flexible here.
I recommend documenting your naming standard and getting buy in across your
organization before you put it into place. By giving names to these
devices/interfaces at all, you are exposing information to the world. What
makes perfect sense to engineering and support may give security, management,
and/or marketing heart palpitations.
Just my $0.02 (probably overvalued).
Hope that helps!
G
---
Gary Steers
Sharedband NOC/3rd Line Support
Sharedband
UK: +44 (0)1473 287207
US: +1 206 420 0240
E: gary.ste...@sharedband.com
We have a new support system - http://support.sharedband.com
-Original Message-
From: Cutler James R [mailto:james.cut...@consultant.com]
Sent: 25 January 2011 22:41
To: nanog group
Subject: Re: Network Naming
On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote:
Whats the rule of thumb for naming gear these days
(routers,switches...etc). Or is there one?
Pick a scheme which:
1. Uses simple memorable names.
2. Makes business sense to you.
3. You know how to manage (database, publication, updates, etc.
If I had to weight these criteria, I would weight 3 most heavily.
James R. Cutler
james.cut...@consultant.com
James R. Cutler
james.cut...@consultant.com
Re: Network Naming
On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote: Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? Pick a scheme which: 1. Uses simple memorable names. 2. Makes business sense to you. 3. You know how to manage (database, publication, updates, etc. If I had to weight these criteria, I would weight 3 most heavily. James R. Cutler james.cut...@consultant.com
Re: anyone running GPS clocks in Southeastern Georgia?
On Jan 21, 2011, at 4:23 PM, Michael Holstein wrote: I'd be curious to see what effects (if any) those who use GPS-disciplined NTP references in Southeastern Georgia see from this experiment. Aren't CDMA BTS clocked off GPS? NTP isn't going to be the only ripple. Regards, Michael Holstein Cleveland State University Possibly relevant section from Agilent Designing and Testing 3GPP W-CDMA Base Transceiver Stations (Including Femtocells) Application Note 1355 1.15 Asynchronous cell site acquisition One of the W-CDMA design goals was to remove the requirement for GPS synchronization. Without dependence on GPS, the system could potentially be deployed in locations where GPS is not readily available, such as in a basement of a building or in temporary locations. W-CDMA accomplishes this asynchronous cell site operation through the use of several techniques. First, the scrambling codes in W-CDMA are Gold codes, so precise cell site time synchronization is not required. There are, however, 512 unique Gold codes allocated for cell site separation that the UE must search through. To facilitate this task, the SSC in the S-SCH channel is used to instruct the UE to search through a given set of 64 Gold codes. Each set represents a group of eight scrambling codes (64 x 8 = 512). The UE then tries each of the eight codes within each code group, in an attempt to decode the BCH. The ability to recover the BCH information (system frame number) completes the synchronization process. James R. Cutler james.cut...@consultant.com
Re: anyone running GPS clocks in Southeastern Georgia?
On Jan 21, 2011, at 4:45 PM, Gary Buhrmaster wrote: NTP isn't going to be the only ripple. Most of the brand name GPS NTP solutions have a clock with is more than stable enough to survive without GPS lock for 45 minutes(*). Some of the more expensive units with temperature controlled oscillators have hold times in the many weeks. My guess is that the NTP ripples will be limited to those NTP servers just (or recently) booted which have not yet achieved a stable clock state. Gary (*) This presumes that this test results in loss of signal lock, and not intentionally injected false information. Even if there actually was an NTP ripple, a properly designed NTP solution should rely on at least three geographically diverse sources. Given the ubiquity of the internet this is not difficult to achieve, barring extreme circumstances. James R. Cutler james.cut...@consultant.com
Re: Some truth about Comcast - WikiLeaks style
That seems to be Off Topic. The operational implications for most of us is, most likely, much more technical bookkeeping and data storage. On Dec 16, 2010, at 2:24 PM, Nathan Eisenberg wrote: What is in the best interests of the customer? Nathan James R. Cutler james.cut...@consultant.com
Re: Introducing draft-denog-v6ops-addresspartnaming
I have a quibble with this discussion. When I defined a byte as a mouthful of bits to my boss back in 1977, he nearly fired me on the spot. He did not care about PDP-10 , much less PDP-11, data constructs. By now, octet has become essentially synonymous with byte and nibble with 4-bits. Could we just refer to n octets? Cutler For Reference Only: On Nov 19, 2010, at 11:06 AM, Richard Hartmann wrote: On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? RIchard James R. Cutler james.cut...@consultant.com
Re: NTP Server
Time Service is more complicated than just having a single NTP server. But it can be useful and is not really a luxury. Two primary reasons for local time service are to reliably serve a network that is relatively or completely isolated from the general internet, and, to provide a local time source for dumb clients that is closer (less jitter) in network terms. Other reasons can include policy (everything in the network uses the same identical time service), policy (the time service is locally controlled), operational simplicity (the routers don't need to run NTP), and, separation of functions/operational responsibility (your run your servers, they run the backbone, I tell you the time. Implementing a local time service is actually fairly simple, but fewer than four servers is wasted effort. I can't explain in just a few words how the servers interact and compute delays and jitter to come to an accurate time. Take my word or ask David Mills for all that. Implementation of an internet-referenced time service involves the following: 1. Select a set of stratum one servers - pick open access servers or get permission to use limited access servers. Four to six should do. 2. Select a set local hosts on your network - DNS servers, for example. These should be well distributed. Four to six should do. The actual NTP load is small compared to DNS queries. 3. Configure the local hosts as peers using the stratum one set as servers. Use crypto authentication if you feel the need. 4. Add NTP monitoring to your network management process. 5. Advertise the local time servers to your network - DHCP, word of mouth, configuration requirements, configuration scripts, standard builds, etc. It is simple enough to do for a five node home network. It is almost that simple for a network with hundreds of thousands of client nodes. I've done both. On Oct 24, 2010, at 12:29 PM, Brandon Kim wrote: I guess what I'm trying to understand is, is having your own NTP server just a luxury? I personally would like to have my own, I just need to pitch its advantages to my company. Unless everyone here on the NANOG group clearly spells it out to me that it's a luxury. I can see it as an added service/benefit though to our customers. Date: Sun, 24 Oct 2010 17:55:22 +0200 From: eu...@leitl.org To: nanog@nanog.org Subject: Re: NTP Server On Mon, Oct 25, 2010 at 02:51:24AM +1100, Ben McGinnes wrote: How do you knew that your local NTP server knew what time it is? (for sure) By polling as many stratum 1 and 2 time servers as possible. Having your own stratum 2 server(s) beats nebulous NTP servers out in the big bad Internet every time. For those you care about that: http://leapsecond.com/time-nuts.htm = James R. Cutler james.cut...@consultant.com
Re: NTP Server
Regarding leap seconds: A modern OS kernel using the NTP daemon to control time will always experience monotonic time. Negative leap seconds should result in the local clock slowing slightly until the local time matches the NTP-derived time. This is in strong contrast to what can happen when ntpdate or similar queries are used to adjust system time, as in the following example from a popular CPE log where the local CPU clock tended to run fast: Oct 24 04:27:59 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 05:28:00 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 06:28:00 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 07:28:01 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 08:28:01 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 09:28:02 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 10:28:03 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 11:28:04 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 12:28:04 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 13:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 14:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 15:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 16:28:06 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 17:28:07 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 18:28:08 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 19:28:08 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 20:28:09 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Regarding local time servers: This is the situation in which local clients, at least those with UNIX or UNIX-like OS can take advantage of ntpd and local time servers to have consistent and monotonic time across your network with a measure of insulation from external vagaries. Yes, I have run ntpd on Windows systems, but have no quotable experience with the current Windows version (Windows 7). James R. Cutler james.cut...@consultant.com
Re: NTP Server
Routers are not a good choice for time servers as it complicates configuration and, to some extent, constrains deployment methodology for routers to be effective with time service. We don't run DNS on routers, it is a service. Time service via NTP is a service as well. The NTP daemon in a router is not implemented in hardware and requires CPU resources better dedicated to RIB management. In my experience, a reliable NTP peer group can be implemented on the same set of boxes as DNS (bind, etc.) with little or no impact on DNS performance. If you can count to four or more, you can make a reliable peer group of time servers. On Oct 24, 2010, at 8:15 PM, Brandon Kim wrote: Hi Sean: By local I meant in-house, on-site in our datacenter. As far as what applications could use our NTP service, I would leave that up to each client and what they are running. For my own personal purposes, it would just be for log purposes. (error logs, syslogs, etc etc) I have heard that routers don't make good NTP servers since they weren't designed to keep track of time. This, I have read from a Cisco source. Can't remember where though. Or maybe they were just referring to older less powerful routers like 2500 series... Brandon Date: Sun, 24 Oct 2010 14:42:24 -0400 From: s...@donelan.com To: nanog@nanog.org Subject: Re: NTP Server On Sun, 24 Oct 2010, Brandon Kim wrote: 1) How necessary do you believe in local NTP servers? Do you really need the logs to be perfectly accurate? 2) If you do have a local NTP server, is it only for local internal use, or do you provide this NTP server to your clients as an added service? 3) If you do have a local NTP server, do you have a standby local NTP server or do you use the internet as your standby server? First terminology. What do you mean by a local NTP server? Almost any Cisco/Juniper router, Unix server and some recent Windows servers have NTP server software and can synchronize clocks in your network. So you may already have a NTP server capable device. You just need to configure it, and give it a good source of time. It would be a Stratum 2 or greater NTP server because the good source of time is another NTP server. Left to itself, NTP is pretty good at keeping clocks in arbitrary networks synchronized with each other. But most people are also interested in synchronizing clocks with some official time source. The Network Time Protocol doesn't really have the notion of a standby server. It uses multiple time sources together, and works best with about four time sources. But for many end-systems, the Simple Network Time Protocol with a single time source may be sufficient. If you are in a regulated industry (stock broker, electric utility, 9-1-1 answering point, etc) there are specific time and frequency standards you must follow. On the other hand, are you are asking about a local clock receiver (radio, satellite, etc) for a stratum 1 NTP server? Clock receivers are getting cheaper, the problem is usually the antenna location. Or on the third hand, are you asking about local primary reference clock (caesium, rubium, etc) for a stratum 1 NTP server? These are still relatively expensive up to extremely expensive. Or on the fourth hand, are you a time scientist working to improve international time standards. If you are one of these folks, you already know. Most major ISPs use NTP across their router backbone, and incidently provide it to their customers. The local ISP router connected to your circuit probably has NTP enabled. Required accuracy is in the eye of the beholder. NASDAQ requires brokers to have their clocks synchronized within 3 seconds of UTC(NIST). 9-1-1 centers are required to have their clocks synchronized within 0.5 seconds of UTC. Kerberos/Active Directory requires clocks to be synchronized within 5 minutes of each other. If your log files have a resolution of 1 second, you probably won't see much benefit of sub-second clock precision or accuracy. If you are conducting distributed measurements with sub-microsecond resolution, you probably will want something more. = James R. Cutler james.cut...@consultant.com
Re: Terry Childs conviction
On Apr 29, 2010, at 4:11 PM, Olsen, Jason wrote: I'm a bit surprised that after the furor here on NANOG when the story first broke (in 2008) that there's been no discussion about the recent outcome of his trial (convicted, one count of felony network tampering). === I'm not surprised. It has little or no direct operational impact. James R. Cutler james.cut...@consultant.com
Re: Rate of growth on IPv6 not fast enough?
No. You get a different set of problems, mostly administrative. On Apr 21, 2010, at 1:53 PM, Dave Sparro wrote: On 4/21/2010 8:46 AM, Jim Burwell wrote: Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :) Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well. James R. Cutler james.cut...@consultant.com
Re: legacy /8
I also just got a fresh box of popcorn. I will sit by and wait for Jeroen to do a business analysis and tell me the return on investment. (Assuming that he can find any legal grounds for demanding return of legacy /8 allocations.) All of the analysis results I have seen mention figuratively beating oneself [..painfully..] with combat boots. Running out of IP addresses is not a soon realized scenario for IPv6. If an organization runs out of IP addresses, the difficulty is with top management, not the network or address space. I think this is a many-iterated discussion, also know by some as a rathole. On Apr 2, 2010, at 5:01 PM, Jeroen van Aart wrote: I am curious. Once we're nearing exhausting all IPv4 space will there ever come a time to ask/demand/force returning all these legacy /8 allocations? I think I understand the difficulty in that, but then running out of IPs is also a difficult issue. :-) For some reason I sooner see all IPv4 space being exhausted than IPv6 being actually implemented globally. Greetings, Jeroen James R. Cutler james.cut...@consultant.com
Re: legacy /8
The last time I discussed IP Address needs with a company the builds automobiles, they wanted forty million addresses for robots, sensors, and the like for manufacturing. A single /8, were it available, would only yield about 20% of that requirement. On Apr 2, 2010, at 6:46 PM, Owen DeLong wrote: Sure, a /8 is a lot of addresses in today's world. James R. Cutler james.cut...@consultant.com
