Re: IPv6 support in hotel contract?
+1 ... Whether it works or not, it's atleast worth the effort! /TJ On Oct 20, 2011 8:07 AM, George, Wes wesley.geo...@twcable.com wrote: My last message caused something else to occur to me – there has been a lot of discussion both here and at NANOG about hotels being woefully underprepared for the internet (and address) use that their guests generate when a conference full of geeks and their multiple devices per person descend upon them. Sometimes the IETF is successful at convincing the hotel to let them take over the internet service in the guest rooms, sometimes not. ** ** Perhaps we can kill two birds with one stone by starting to require IPv6 service in the guest rooms when we enter into negotiations with hotels. If they don’t have it, we’ll be happy to temporarily take over the internet service, or assist them in getting it enabled permanently in their existing network, and if neither of those options are acceptable, it provides negotiating leverage on other things. This also has the net effect of starting to make it clear to hotel management that IPv6 is going to start being mandatory for some subset of their guests before too much longer. ** ** ** ** I realize that having something in the contract doesn’t mean that we’re any more likely to get it. But the fact that it’s in the contract makes a statement in and of itself. IAOC, any reason why this couldn’t be added, especially given how far in advance you’re negotiating with venues? ** ** Thanks, ** ** Wes George ** ** -- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
To be fair - I don't think anyone is saying We should totally encourage 6to4!, even in the short-term ... or any other auto-tunneling transition mechanism, really. In fact, I think the debate here largely stems from a valid desire to discourage 6to4. Note: That goal, I am in favor of (recommending that 6to4 be disabled by default on client platforms). However, the proposals on the table seek to reclassify 6to4 as historic - something that has raised a noticeable amount of debate about 1) what historic really means and/or 2) what impact that re-classification may have on currently-functional 6to4 usage today. /TJ ... who wishes to note that 6to4 works *just fine* ... except when it doesn't. PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. On Wed, Jul 27, 2011 at 23:15, Brzozowski, John john_brzozow...@cable.comcast.com wrote: From an operators point of view, specifically one that has deployed 6to4 relays, use of the same should not be encouraged. I fully hope and expect the use of 6to4 to systematically decrease over time so the associated infrastructure can be decommissioned. While we have seen issues related to 6to4 decrease recently the deployment of the same over the years, in particular open relays, has grossly complicated deploying 6to4 in a reliable manner. I have not been able to keep up with all the emails and threads related to this topic, I apologize for this. The bottom line from my point of view is that we (the IETF) should do something to discourage the use of the same. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 7/27/11 2:18 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 27, 2011, at 3:32 AM, t.petch wrote: I oppose this action. I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' so the IETF has a responsibility to discourage its use. [...] I'd like to address the point that 6to4 damages the Internet. I do understand the content providers' argument - if 6to4 is turned on at the originator's host or network, the destination is advertising both A and records, and the record is chosen in preference to the A record, the user's experience is degraded. Sometimes the performance is degraded marginally (but the cumulative effect of lots of small delays on a web page that loads dozens of images is large). Sometimes it's degraded significantly because the 6to4 address doesn't work at all. Both cases matter, and they do provide a disincentive to content providers to just slap records onto their sites and be done with it. (There are other ways of a web site utilizing v6, but they require more work.) A lot of the arguments that I hear about 6to4 being bad in a universal sense seem to be based on the assumption that it's only access to content in the public Internet that matters. But anyone who has followed IPv6 development should know better than that. If access to content in the public Internet were all that mattered, there would have been no interest in ULAs. It remains the case that many enterprise networks have all kinds of internal resources that are useful to them even if they're not publicly addressable, and are only usable from within that network or from other networks with which they have made explicit arrangements. For better or worse, an explicit design feature of IPv6 is that hosts can have multiple addresses, and that different addresses might be needed in different contexts. A host's public address might be used when contacting a public web server, but when communicating within an enterprise network or between networks each using ULA space, the host might need to use its ULA address as a source address (the other host might not have a public address or the ability to send traffic to the public IPv6 network). I put the word feature in quotes because this can be a pain in the a** for applications and users. The default address selection rules don't really handle this case very well, nor can any set of static default rules handle this case. Essentially what having multiple addresses per host implies is that hosts or applications need to do routing in the absence of routing information. It shouldn't surprise anybody that the use of addresses that only work well (or at all) within a limited scope creates situations where a host will try to send traffic down a path that will never get it there, even when a different path would have worked. Introducing IPv6 - any kind of IPv6 - into a world of hosts that already support IPv4, creates exactly this situation. Nothing
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 15:21, Cameron Byrne cb.li...@gmail.com wrote: On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment. As a member of that small but vocal minority I think you are being a little unfair here; some of us are working quite hard in getting IPv6 deployed in a number of different places. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. And, FWIW, I have no objections to having it off by default. In fact, I welcome that. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Fri, Jun 10, 2011 at 05:55, otunte otueneh otuene...@gmail.com wrote: Dear Stefan, Thank you for the reply. I think there should be a platform where IPv4 users and IPv6 users can interface. If this link is missing then there will be problem. That kind of thing can be done - Google NAT64/DNS64 or how proxies work., However, this is *not* the ideal state. Ideally, you would be provisioned with both IPv4 and IPv6 (dual stack) and thus be able to connect to content reachable over either. Call your ISP, ask them when they will be entering the right decade (read: How soon will they offer IPv6). This may not be a critical feature right now, but if your ISP hasn't even started they probably won't be ready when you start to need it. Or they will break things trying to get there rapidly, that is fun. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Thu, Jun 9, 2011 at 13:30, Randy Presuhn randy_pres...@mindspring.comwrote: Hi - From: Rémi Després remi.desp...@free.fr To: Randy Presuhn randy_pres...@mindspring.com Cc: ietf@ietf.org Sent: Thursday, June 09, 2011 1:11 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt ... I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. RFC 1227 specified an experimental protocol. The 6to4 specification is standard track. Declaring historic a standard track specification although it still serves legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO. Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Despite that declaration, it remains in use. This despite all the good reasons that its replacement should be used instead. The point is that the historic declaration can be a statement about how the IETF wants things to be, rather than how they are. If one happens to be a user or vendor of a historic technology, the declaration might sting a little, but it's really not a big deal, IMO. Although I have already stated my position in this issue (against, for now), I have a problem with the above logic. You are effectively arguing that this move won't really impact anything ... in which case I would ask, why are we doing it? I suspect that 6to4 is a fairly unique case in that it, as pointed out earlier, relies on the good nature of others to operate relays for the public good. Marking it as historic would, I imagine, demotivate ISPs to operate those relays and thus render the connectivity even worse than we are fearing. Please don't confuse my position - I wholeheartedly believe the right answer is, and am very vocal in promoting, native IPv6 (dual stack) everywhere, for everyone. But we aren't there yet. Even though my home ISP has done more IPv6 than many|most, they aren't ready to do native here, yet. I often rely on 6to4 is _many) scenarios and simply want something that exists to keep working until the alternatives are more available. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). snip It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. Just my $.02, /TJ ... ready for world IPv6 Day? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 08:56, George, Wesley wesley.geo...@twcable.comwrote: From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George I agree with the end goal here, but for a mechanism that relies on the good will of others (relays) changing it to historic could have a more-abrupt impact on those who use the mechanism than in other cases of similar demotions. That is my concern. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Mon, Jun 6, 2011 at 13:22, Keith Moore mo...@network-heretics.comwrote: I strongly object to the proposed reclassification of these documents as Historic. *snipped lots of great thoughts/comments, solely for brevity* Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just saying this because I successfully use 6to4 on a fairly common basis ... /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: [Full-disclosure] IPv6 security myths
Perhaps I should have said deployable ... Although it is deployed in some places, and growing rapidly - I'd be surprised if your situation didn't change over then next 12-15 months ... /TJ On Oct 30, 2010 11:28 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: TJ [trej...@gmail.com] wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments On a possibly related note, IPv6 use deployed and working too ... Failure means that, I leave in the capital city of California and I can't find a single ISP that offers native IPv6. We're in the end of 2010. And no change in sight. Tunnels? Oh yes tunnels. I had that 10 years ago. You call that deployed? Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
If you mean widespread, point to point / peer to peer IPsec - yes, there is a distinct lack of (free, easy, global) PKI out there. There are steps in the right direction though, such as MS's Direct Access ... /TJ On Oct 31, 2010 12:02 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: TJ wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... Sorry for lack of clarification. My context is IPsec in the Internet, which excludes VPNs. Do you know some major application over the Internet using IPsec with transport mode? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... On a possibly related note, IPv6 use deployed and working too ... /TJ On Oct 27, 2010 12:08 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Steven Bellovin wrote: The core issue was indeed that IPsec was mandated for v6. We were *very* overoptimistic about how long it would take before roll-out started in earnest. In fact, we underestimated how long it would take to get good specs for all the important pieces. We also underestimated how long IPsec would take, though that was partially (but only partially) because IPsec version 1 (RFCs 1825-1829) had to be thrown away. Quite simply, it is merely that IPsec had totally failed long before IPv6 totally failed. FYI, total failure of IPsec is not the only reason of total failure of IPv6. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
A bit before then, Thomas Narten wrote: There are DoD networks where IPv6 is running today, and there certainly are networks where it is not. The quote above seems very precisely phrased, and as an accidental result seems a bit misleading. It appears to refer to the Defense Research Engineering Network (DREN), which is widely reported to be dual-stack IPv4 and IPv6. [e.g. see Ron Broersma's slides from the Google IPv6 Implementer's Workshop] However, the trade press and other public sources consistently indicate the DoD considers DREN to be experimental or research, rather than operational (at least for the DoD meaning of the word 'operational'). One also consistently reads that the actual operational DoD backbone (i.e. DISA's GIG-BE network) is IPv4 only, in part for security reasons and in part for lack of any business case to do otherwise, and that all other DoD operational networks are also IPv4 only. The DoD is forbidden from running native IPv6 operationally, per the STIGs and MO guidelines. MO1 and 2 get some IPv6 in place, in tunnels across the GIG ... MO3 will be the first step in native/operational IPv6, not even signed yet IIRC. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Packet mood
The TCP-Hulk option? But that is an RFC for next year ... Maybe we could work our way through all the superheroes ... the BatMan option comes with lots of other options and a smaller, brightly-clad helper option (and money!), SuperMan packets can only be stopped by Kryptonite Firewalls ... /TJ On Thu, Apr 1, 2010 at 15:11, Scott Brim scott.b...@gmail.com wrote: If you don't ack a packet, not only does it get angry, it gets _bigger_ and begins to turn green! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
FWIW - I wholeheartedly agree with If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. In fact, I think this (end nodes awareness of their real external address and port) should be one of the, if not the, biggest design goals for NAT66 ... assuming we do define it. This enables the NAT to still do its thing, while still retaining the ability for apparent end to end communications. Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow firewall pinhole creation might just be useful, with a note of concern around security of course ... /TJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore Sent: Tuesday, November 25, 2008 5:43 PM To: David Morris Cc: 'IAB'; '[EMAIL PROTECTED] WG'; 'IETF Discussion'; 'IESG IESG' Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers David Morris wrote: Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. I understand. But in practice just knowing your external address is often insufficient. You need an intermediate server that will forward traffic as well as maintain the bindings in both (nay, all) endpoints' NATs. If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. Furthermore it's not sufficient to just define a NAT with a bidirectional, algorithmic mapping (in order to avoid some of these problems) because what people have come to expect from NAT (and to rely on) is that incoming connections are denied by default. So really, to be viable, any NAT standard needs to include some amount of firewall functionality. And the firewall needs to be able to keep working even if the NAT function is turned off. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic stats
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum On 12 nov 2008, at 21:17, Danny McPherson wrote: Indeed, and according to the same stats, . 0.238% of users have useful IPv6 connectivity (and prefer IPv6) . 0.09% of users have broken IPv6 connectivity Nearly 38% of that .238% is broken... No, 0.238% is the working IPv6 users, so the total is 0.328% of which 27% is broken. I would be interested to see the OS breakdown for that 0.09%. I'm betting it's mostly Vista 6to4 users who have a public IPv4 address but are behind a firewall that blocks protocol 41. Or that, sadly, have an apparently-public IP that gets NATed to another public IP. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
