Re: Diversity of IETF Leadership
On Mar 10, 2013 2:05 PM, Spencer Dawkins spen...@wonderhamster.org wrote: On 3/10/2013 2:50 PM, Scott Brim wrote: On 03/10/13 15:43, John Levine allegedly wrote: - Each of the confirming bodies (the ISOC Board for the IAB, the IAB for the IESG, and the IESG for the IAOC) could make a public statement at the beginning of each year's nominations process that they will not confirm a slate unless it contributes to increased diversity within the IETF leadership, or it is accompanied by a detailed explanation of what steps were taken to select a more diverse slate and why it was not possible to do so. That sounds a lot like quotas. Let's not go there. +1. We do not want to manage by ideology - consider how well that serves political parties. Right. So is there anything you would like for the confirming bodies to say to Nomcom, that doesn't sound like quotas? Spencer Generally this solution space is most elegantly handled by increasing the pool size from which selection is made. This generally involves actively recruiting under-represented groups to join the pool rather than directly manipulating a merit based selection process. CB
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
On Mar 6, 2013 1:03 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: A Splendid Example Of A Renumbering Disaster
On Mon, Nov 26, 2012 at 12:41 PM, Pete Resnick presn...@qti.qualcomm.com wrote: On 11/23/12 7:46 PM, Sabahattin Gucukoglu wrote: It's Friday. Time to plug IPv6 some more. :-) http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/ LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They avoided conflicts with RFC 1918 space by hijacking IPv4 space in 5/8, now actively being allocated by LIRs in Europe. When that didn't work (see link above), they moved to 25/8, allocated to the UK MoD. While I'm almost sure that they haven't got it quite so wrong this time, following the comments says that the idea was not only a very bad one to start with, it's cost a lot of people a lot of grief that IPv6 was clearly going to mitigate in renumbering. Perhaps it is why they recommend it per default, if not for the number of applications that would be broken by it. By the way, is this an application that the new shared transition space might benefit? Yes, like Benson, I am at a loss for why they do not use RFC 6598 addresses. That's what someone should tell these goofballs to do. Unfortunately, RFC1918 and RFC 6598 are not enough to number all that needs numbers. Lots of love, Goofball pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
Sent from ipv6-only Android On Nov 17, 2012 9:12 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Cameron Byrne cb.li...@gmail.com If LISP succeeds, this results in significant reduction in core table sizes for everyone. Not everyone. Only people who carry core tables. 'this results in significant reduction in core table sizes for everyone who has core tables' sounds a bit tautological, no? No. Most networks dont carry full bgp routes. Most networks is an odd definition. So, I will say my network does not carry full bgp routes. That is LISP twist, it transfers cost from a few cores to many edges. If you define 'many' is 'people who are actually trying to communicate with a given site', yes. So it has transferred costs for communicating with site X from 'everyone with a core table, everywhere in the entire network' to 'just the people who are actually trying to communicate with site X'. This is bad... how? I am not a LISP expert (ILNP sounds better to me, but we are already way OT), LISP has never passed my smell test. But the only thing I have gleaned of it is that dfz caps in size while edge sites have to buy more routers with newer functions. Which sounds good for tier 1 operators who are on the hook for dfz scaling and for router vendors who are on the hook for selling more routers. There might even be something in it for folks who who are nostalgic for ATM SVCs. There are a lot of ways to shrink the dfz. LISP, imho, is unlikely to succeed due to the economic incentives not being aligned. It requires action at edge sites for problems edge sites don't have (dfz scaling). CB (When I first quickly read your message, I thought you were making a point about the routing overhead of EIDs being carried in the global routing tables for use by legacy sites, which is an interesting point, but not the one that you make here.) Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
On Nov 16, 2012 9:27 AM, Joel M. Halpern j...@joelhalpern.com wrote: Why does any operator have a reason to carr any routes other than their paying customers? Because it provides connectivity for their customers. If we get this block allocaed, then it results in 1 extra routing entry in the global routing table to support LISP inter-working. An entry that some of their customers may use, whether the operator carrying it knows that or not. In fact, it would take significant extra work for the operator to somehow block this aggregate. If LISP fails, this is a small cost to find out. If LISP succeeds, this results in significant reduction in core tabl sizes for everyone. Not everyone. Only people who carry core tables. That is LISP twist, it transfers cost from a few cores to many edges. Associated pros and cons exist. CB Yours, Joel On 11/16/2012 11:35 AM, Brian E Carpenter wrote: Joel, On 16/11/2012 16:00, Joel M. Halpern wrote: ... With regard to interworking and deployment, there are a number of documents that deal with that. They discuss what the currently understood deployment incentives are, and what paths are currently seen. (As Noel noted, this is an experiment, and one should expect that the actual path will be different from the expectation.) Given that interworkng dives are data plane devices, altruism is clearly not a sufficient incentive to get this to scale, and the models do not depend upon that. My concern with this allocation request was not about scaling but about black holes. What are the incentives for operators not very interested in LISP to carry the routes that make it work? That's the root of many of the problems with 6to4 (and, I think, many of the problems of the MBONE, for those with long memories). Regards Brian
Re: Gender diversity in engineering
On May 1, 2012 4:08 PM, Janet P Gunn jgu...@csc.com wrote: But that leaves out all of us that started off in a different (technical) field (Math and OR in my case) and ended up here.. Furthermore, is rigorous academic STEM education highly correlated with whatever it is you are trying to measure ? CB Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From:James M. Polk jmp...@cisco.com To:IETF-Discussion list ietf@ietf.org Date:05/01/2012 04:40 PM Subject:Gender diversity in engineering Sent by:ietf-boun...@ietf.org There have been some good numbers floated on recent threads, but at least for me, they aren't enough to gain a complete (or nearly complete) picture of the issue. Having studied statistics, we need to know a starting point, and look for the reductions (or increases) from that point forward. Starting in high school is not sufficiently refined enough, as there are a lot that take advanced math (personally I'd start with trig - because that kicked my ass - but rarely is it its own class, so let's start with calculus 1) that don't go into engineering. Thus, high school is probably not a good place to measure from. Therefore, it needs to be college. We need to know % of class (based on year started) that is female in engineering (do we want to start with electrical and CS to be more applicable to our situation?) We'll call that percent 'X' then %X of drops from engineering (BS) (or just elec/CS?) over the college years before graduation? then %X that enter workforce after BS in Engineering (or just elec/CS?) into the engineering field? then %X that start graduate school (MS) in engineering (or just elec/CS)? %X that receive MS degree in engineering (or just elec/CS)? %X that enter workforce after MS in Engineering (or just elec/CS?) into the engineering field? then %X that start doctoral school (PhD.) in engineering (or just elec/CS)? %X that achieve PhD. in engineering (or just elec/CS)? then %X that enter workforce after PhD in Engineering (or just elec/CS?) into the engineering field? This will likely track those that are entering the engineering workforce, and with what level of education. From that point in the analysis - we can attempt to track at what point there are further drops out of the engineering workforce by women (i.e., after how many years). Or is it as simple as problems after childbirth to reenter the workforce (for whatever reason). As an example, if there is a significant difference from those that drop out after their BS from those that drop out MS, then maybe something should be done to encourage women to stay for the MS. comments or questions? James
Re: Variable length internet addresses in TCP/IP: history
On Feb 14, 2012 7:40 PM, Randy Bush ra...@psg.com wrote: Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. rant the routers had v6 code in the mid to late '90s. servers had the kame stack before then. etc etc etc. except for dhcp, of course, as the v6 religious zealots did not want to allow dhcp, it would make enterprise conversion too easy. what we did not have was a way to deploy around the fracking incompatibility. it was not until 2001 or so that we could even run useful dual stack, so we early deployers had two parallel networks for some years. religion has always been more important to the ietf than deployment. look at dhcpv6, the zealots are still stonewalling router discovery. look at the deprecation of nat-pt, now nat64/dns64. it is as if the ipv6 high priesthood did everything in their power to make ipv6 undeployable without very high cost. and they have succeeded admirably. so today, since the costs of ipv6 incompatibility and lack of feature parity are still high, for some folk it is easier to deploy nat4. what a win for the internet. congratulations. randy /rant But, this pig too shall fly Cb ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt
On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews ma...@isc.org wrote: In message 201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp, Martin Rex writes : Brian E Carpenter wrote: On 2012-02-14 05:51, Noel Chiappa wrote: From: Arturo Servin arturo.ser...@gmail.com Are you volunteering to buy everyone on earth a new CPE? If not, w ho do you suggest will? I suggest the ISPs, they are charging for the service, right? Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our house, both our cable modem and the router attached to it are ours. Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. (That is not hand-waving, the generation of boxes with IPv6 support is starting to appear.) Nobody, I think, is denying that there will be a long period of coexistence as a result. That is a separate question from this draft, which gives ISPs space for *growing* their IPv4 customer base. I think that is what upsets people. The problem of ISP not newly shipping CPE that is not IPv6 capable needs to be addressed by regulatory power (legistation), rather than by ignorance of the part of the IETF. ISPs *growing* their IPv4 customer base is a natural side effect whenever ISPs allow customers to use equipment that they already have (and might have been using with a different ISP before). You grow your IPv4 customer base by having new customers independent of whether they are IPv6 customers as well. I don't think there is a customer that only wants to connect to IPv6 sites. Having IPv6 doesn't even cut down on needing to supply IPv4 unless you have bleeding edge IPv6 equipment. People still need to connect to IPv4 literals and that will, for a quite a while yet, mean supplying a dual stack service. NAT64 doesn't have a way to inform the CPE on the mapping needed. It would be simple to do with DHCP but know one had written what needs to be in the option. Similarly 464XLAT doesn't provide a way for the CPE to find the prefix. Blindly performing 464XLAT has similar issues to blindly performing 6to4. 464XLAT may indeed discover the PREF64 using http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05 Running code says 464XLAT works with IPv4 literals, IPv4 referrals, and IPv4 socket APIs. CB DS-Lite only became a RFC in the second half of 2011. It will take some time for IPv6 equipment vendors to add support (hosts and routers). The vast majority of customers does not know or care about not having IPv6, because there is _very_ few equipment that is vitally dependent on IPv6, vs. huge amounts of equiment that requires IPv4. If I had a CPE that supported IPv6 (mine is from early 2006 an IPv4-only), my concern would be how to reliably switch IPv6 off, because of the unsolved security and privacy problems that IPv6 brings along. It was the IETFs very own decision to build IPv6 in a fashion that it is not transparently backwards compatible with IPv4. If the is anyone to blame for the current situation, than it is the IETF, not the consumers or the ISPs (except for those folks at ISPs who participated in the development of IPv6). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 10, 2012 4:25 PM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. +1. This is all business. Companies have made their choices. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. This is the logical path for the cgn minded. They need to deal with the challenge of renumbering users. I also oppose this draft. Cb -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ 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: class E (was: Consensus Call: draft-weil-shared-transition-space-request)
On Mon, Dec 5, 2011 at 9:46 AM, Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com wrote: On 5 December 2011 04:27, Cameron Byrne wrote: [they = the IETF] they underscored that point by not rejecting various past attempts at expanding private ipv4 space like 240/4. Sorry. S/not rejecting/rejecting/ ACK. The last state I'm aware of is that the 240/4 addresses minus one were and still are (RFC 5735) reserved for IETF experiments, did I miss some newer IETF consensus about this? -Frank http://omniplex.blogspot.com/2008/06/lost-found-268435455-free-ips.html Hi, The addresses, AFAIK, are still in a no mans land. I went on a short-lived quest to make these addresses usable in 2008, because in 2008, they were not usable and i needed addresses. Meaning, Linux, FreeBSD, Windows would not accept these addresses in configuration and Juniper and Cisco router would not only not accept these addresses as part of their configuration, they would not route the addresses in transit. Some of this may have changed, but not enough to make this a clear win. I was told, by a large vendor of network gear, an IETF direction must be made to define a purpose for these addresses, like: http://tools.ietf.org/html/draft-wilson-class-e-02 http://tools.ietf.org/html/draft-fuller-240space-02 Both failed to gain support (i assume), and thus nothing happened. My assumption is these drafts were killed as IPv4 life support RFC 5735 leaves the use of 240/4 undefined ... it could be used for public, private, multicast, some future use we never thought of, carrier pigeons ... Thus, my feeling is that the IETF implicitly said no ipv4 life support by expanding private addresses, the cost of ipv4 will go higher and higher, we can all see it like a slow moving train wreck, make your strategies wisely. Making this allocation for draft-weil is changing the rules, slowing the train wreck, going backwards of previous guidance(IPv6 is the answer to IPv4 exhaust), while at the same time increasing the amount of of damage. cb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 4, 2011 10:40 AM, Joel jaeggli joe...@bogus.com wrote: On 12/4/11 08:48 , Hadriel Kaplan wrote: Hi Victor, Yes that helps, thanks - it confirms what I had always assumed was the case but could not grok from the discussions on this list nor the draft. Because the new address space is actually seen/used by the consumer's interface, we cannot possibly pick a safe RFC 1918 address nor 240/experimental space, for the reasons I stated in my email. We *have* to allocate a new space. It's an absurdity that the clearly impossible is in fact the defacto deployment model. this is a verizon 4g card... en3: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1428 ether 64:99:5d:fd:b2:d4 inet6 fe80::6699:5dff:fefd:b2d4%en3 prefixlen 64 scopeid 0xc inet6 2600:1010:b005:c97d:6699:5dff:fefd:b2d4 prefixlen 64 autoconf inet6 2600:1010:b005:c97d:b963:23e7:3ae1:e287 prefixlen 64 autoconf temporary inet 10.170.127.207 netmask 0xffe0 broadcast 10.170.127.223 media: autoselect (1000baseT full-duplex) status: active 10.170.127.192/27 link#12UCS 20 en3 10.170.127.193 4c:47:45:56:44:58 UHLWIi422 34 en3 1197 10.170.127.207 127.0.0.1 UHS 00 lo0 An additional fact is that Verizon reuses 10/8 across their network, 10/8 per region. Net net, rfc1918 is used in cgn today. Squat space is also used in cgn today. Making an allocation creates another permutation of how cgns are deployed. Furthermore, a /10 is not a large enough allocation to be the one solution everyone can converge on. Cb Furthermore, I would suggest the draft include the following in section 4: Administrative entities other than Service Providers MUST NOT use the IPv4 address space reserved for this use. An example of why this would be a problem is if an Enterprise's internal private network used this address space and the Enterprise someday wanted to provide remote employees with VPN access to the private network, then any employees connected to any Service Provider anywhere using the same address space would not be able to VPN in to the local Enterprise because of the resulting overlap in their local device's routing table. -hadriel ___ 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: Consensus Call: draft-weil-shared-transition-space-request
On Dec 4, 2011 11:06 AM, Hadriel Kaplan hkap...@acmepacket.com wrote: Yes, I know that mobile networks have started going that way - which is why I asked the question. The reason we (the IETF) cannot possibly pick the same RFC1918 address space is because those mobile networks now have the problem I described: when you try to run your VPN client on that laptop, if your employer's Enterprise private network happens to use the same private address space as the mobile provider, it no workie. (assuming the VPN connection succeeds to begin with, of course) Started? I would say most mobile data networks started with rfc1918 at the inception of WAP mobile data services nearly 10 years ago and have stayed that way, replacing WAP proxies with CGN 5 years ago. This is not a novel problem. Regarding enterprise vpns, the client VPN abstracts the host routing to make this work. I am not sure which part you don't understand. You do know 1918 is in most home networks and most enterprises and it just works, right ? Sorry if I misunderstand your concern. Cb There is nothing the mobile provider can reasonably do about that, short of charging more money for VPN-capable connections as some hotels and access spots do. Some providers would probably be fine with such a charging model, but some providers I've talked to don't want to have such a charging model and don't want to use the 10.x.x.x address space, but don't have much choice since we haven't allocated a different one. -hadriel p.s. I didn't mean cannot possibly in the sense of it being technically impossible, I meant it in the sense of it being a very bad idea. :) On Dec 4, 2011, at 1:39 PM, Joel jaeggli wrote: On 12/4/11 08:48 , Hadriel Kaplan wrote: Hi Victor, Yes that helps, thanks - it confirms what I had always assumed was the case but could not grok from the discussions on this list nor the draft. Because the new address space is actually seen/used by the consumer's interface, we cannot possibly pick a safe RFC 1918 address nor 240/experimental space, for the reasons I stated in my email. We *have* to allocate a new space. It's an absurdity that the clearly impossible is in fact the defacto deployment model. this is a verizon 4g card... en3: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1428 ether 64:99:5d:fd:b2:d4 inet6 fe80::6699:5dff:fefd:b2d4%en3 prefixlen 64 scopeid 0xc inet6 2600:1010:b005:c97d:6699:5dff:fefd:b2d4 prefixlen 64 autoconf inet6 2600:1010:b005:c97d:b963:23e7:3ae1:e287 prefixlen 64 autoconf temporary inet 10.170.127.207 netmask 0xffe0 broadcast 10.170.127.223 media: autoselect (1000baseT full-duplex) status: active 10.170.127.192/27 link#12UCS 20 en3 10.170.127.193 4c:47:45:56:44:58 UHLWIi422 34 en3 1197 10.170.127.207 127.0.0.1 UHS 00 lo0 Furthermore, I would suggest the draft include the following in section 4: Administrative entities other than Service Providers MUST NOT use the IPv4 address space reserved for this use. An example of why this would be a problem is if an Enterprise's internal private network used this address space and the Enterprise someday wanted to provide remote employees with VPN access to the private network, then any employees connected to any Service Provider anywhere using the same address space would not be able to VPN in to the local Enterprise because of the resulting overlap in their local device's routing table. -hadriel ___ 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: Consensus Call: draft-weil-shared-transition-space-request
On Dec 4, 2011 7:10 PM, Chris Donley c.don...@cablelabs.com wrote: More seriously, the impression I've gathered from various discussions is that the 90/10 model is viable, but it's not the first choice because the 10 part involves customer service work that those interested in deploying CGN would like to avoid in order to protect their margins. I'm not sympathetic. [CD] Really? 10% of customers having problems is a viable model? Let's do the math here. Consider a 10M subscriber ISP. Your breakage model (10%) would generate at least 1 M support calls (some people may call more than once). Let's say a support call costs $50 (I don't know the exact cost, but I think this is close), so the cost of supporting a 10% failure case will be close to the $50M you keep quoting (multiply this by the number of affected ISPs). What do you think an ISP will do if faced with this option and no Shared CGN Space? Select an IETF-specified RFC1918 block of addresses and deal with $50M of support costs plus 1M upset subscribers? Acquire addresses from the RIR (or from an address broker)? Or squat on someone else's space? And if that doesn't fully answer your Which part don't you agree with? question, I doubt that even a significant portion of ISPs are going to use routable addresses internally for CGN as the value of those addresses for their intended purpose is only going to increase, and they will still need to be able to number publicly facing things after the RIRs have exhausted their supply. [CD] So you're really arguing for squat space? I have a real problem with that. I know people are already doing it, but I think it sets a bad precedent and increases risk of interoperability problems across the Internet. I believe the IETF has a vested interest in discouraging address squatting, and should act accordingly. The ietf did act. It is called ipv6. And, they underscored that point by not rejecting various past attempts at expanding private ipv4 space like 240/4. Cb ___ 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: Consensus Call: draft-weil-shared-transition-space-request
On Dec 4, 2011 7:24 PM, Cameron Byrne cb.li...@gmail.com wrote: On Dec 4, 2011 7:10 PM, Chris Donley c.don...@cablelabs.com wrote: More seriously, the impression I've gathered from various discussions is that the 90/10 model is viable, but it's not the first choice because the 10 part involves customer service work that those interested in deploying CGN would like to avoid in order to protect their margins. I'm not sympathetic. [CD] Really? 10% of customers having problems is a viable model? Let's do the math here. Consider a 10M subscriber ISP. Your breakage model (10%) would generate at least 1 M support calls (some people may call more than once). Let's say a support call costs $50 (I don't know the exact cost, but I think this is close), so the cost of supporting a 10% failure case will be close to the $50M you keep quoting (multiply this by the number of affected ISPs). What do you think an ISP will do if faced with this option and no Shared CGN Space? Select an IETF-specified RFC1918 block of addresses and deal with $50M of support costs plus 1M upset subscribers? Acquire addresses from the RIR (or from an address broker)? Or squat on someone else's space? And if that doesn't fully answer your Which part don't you agree with? question, I doubt that even a significant portion of ISPs are going to use routable addresses internally for CGN as the value of those addresses for their intended purpose is only going to increase, and they will still need to be able to number publicly facing things after the RIRs have exhausted their supply. [CD] So you're really arguing for squat space? I have a real problem with that. I know people are already doing it, but I think it sets a bad precedent and increases risk of interoperability problems across the Internet. I believe the IETF has a vested interest in discouraging address squatting, and should act accordingly. The ietf did act. It is called ipv6. And, they underscored that point by not rejecting various past attempts at expanding private ipv4 space like 240/4. Sorry. S/not rejecting/rejecting/ Cb Cb ___ 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: Consensus Call: draft-weil-shared-transition-space-request
I will add one more concern with this allocation. IPv4 address allocation is a market (supply exceeds demand in this case), and thus a strategic game (like chess) to gather limited resources . We have known for a long time how IPv4 was not an acceptable long term solution. We have known for a long time that IPv6 is the only path forward for a growing internet (more people online, more devices connected, up and to the right...) This allocation is changing the rules of the game in the last few minutes (IANA and APNIC are already out...) and is dubiously blessing an Internet model based on CGN. Changing the rules of the game towards the end to manipulate the outcome is seldom acceptable, regardless of the context. AFAIK, there have been no extenuating circumstance that have dictated a need for a change. IPv4 did not magically run out. My favorite IPv4 risk artifact should be familiar to the draft authors or other people in the ARIN region: https://www.arin.net/knowledge/about_resources/ceo_letter.pdf I understand how this allocations benefits folks in the short run, and i promise to use this allocation to my benefit (better than squat space, right?!). But, at the macroscopic level at which the IETF, IESG, and IAB should be working, this is just changing the rules of the game at the last minute because some players don't like the outcome, even though this outcome (ipv4 is out, need to use v6) has had 10+ years of runway. I do not believe this is a positive sum game where this allocation is made and everyone wins. I do believe IPv6 loses (CGN vs v6 investment*, urgency, lines on strategy diagrams...) if this allocation is made, and i do not think it is acceptable to change the rules of the game in the final moments because the outcome is costly for some. Cameron *i already have the link to your press release that your lab is ipv6 enabled, thanks! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 1, 2011 4:02 PM, Chris Donley c.don...@cablelabs.com wrote: This is not a new proposal. People have been asking for the same thing for a long time. Draft-bdgks does a good job spelling out the history (below). To say that we're trying to change the rules at the last minute is wrong. People have been asking for such an allocation considering this use case as long ago as 2004, and fairly consistently since 2008. We and the other draft authors have been following IETF process, documenting the need, documenting the tradeoffs, and documenting the challenges with CGN for quite some time. People wouldn't keep coming back to the IETF again and again for seven years or so if we had a better way to satisfy this need (although I am aware that some operators have opted for squat space rather than push for a shared pool of CGN space). I know this is not a new case. And I know efforts to make 240/4 workable are also not new. And, historically the answer is always no to new special ipv4 space. Someone else can expound why. If I had 240/4 in 2008, I would not have ipv6 now, that is a straight strategic business planning fact. Saying yes now, would be changing the rules because 'the rule' was/is 'no' new space. Cb Chris From bdgks: Proposals for additional Private space date back at least to [I-D.hain-1918bis http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.hain-1918bis] in April 2004. Some of these proposals and surrounding discussion may have considered similar use-cases as described herein. However, they were fundamentally intended to increase the size of the [RFC1918 http://tools.ietf.org/html/rfc1918] pool, whereas a defining characteristic of Shared Transition Space is that it is distinctly not part of the Private [RFC1918 http://tools.ietf.org/html/rfc1918] address pool. Rather, the Shared Transition Space is reserved for more narrow deployment scenarios, specifically for use by SPs to meet the needs of ongoing IPv4 connectivity during the period of IPv6 transition. This key feature emerged in more recent proposals such as [I-D.shirasaki-isp-shared-addr http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.shirasaki-isp-shared-addr] in June 2008 where a proposal to set aside ISP Shared Space was made. During discussion of these more recent proposals, many of the salient points where commented upon, including challenges with RFC1918 http://tools.ietf.org/html/rfc1918 in the ISP NAT Zone, Avoidance of IP Address Conflicts, and challenges with 240/4. This effort was followed up by [I-D.weil-opsawg-provider-address-space http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-opsawg-provider-address-space] in July 2010 which was re- worked in November 2010 as [I-D.weil-shared-transition-space-request http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-shared-transition-space-request]. These latter efforts continued to point out the operators' need for Shared Transition Space, with full acknowledgement that challenges may arise with NAT444 as per [I-D.donley-nat444-impacts http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.donley-nat444-impacts] and that such space does not reduce the need for IPv6 deployment. Most recently, following exhaustion of the IANA's /8 pool [NRO-IANA-exhaust http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -NRO-IANA-exhaust], this proposal has been discussed by various RIR policy development participants. As described herein, the body of ARIN policy development participants has reached consensus and recommended a Shared Address Space policy for adoption [ARIN-2011-5 http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -ARIN-2011-5]. This history shows that operators and other industry contributors have consistently identified the need for a Shared Transition Space assignment, based on pragmatic operational needs. The previous work has also described the awareness of the challenges of this space, but points to this option as the most manageable and workable solution for IPv6 transition space. Chris On 12/1/11 2:05 PM, Cameron Byrne cb.li...@gmail.com wrote: I will add one more concern with this allocation. IPv4 address allocation is a market (supply exceeds demand in this case), and thus a strategic game (like chess) to gather limited resources . We have known for a long time how IPv4 was not an acceptable long term solution. We have known for a long time that IPv6 is the only path forward for a growing internet (more people online, more devices connected, up and to the right...) This allocation is changing the rules of the game in the last few minutes (IANA and APNIC are already out...) and is dubiously
Re: Consensus Call: draft-weil-shared-transition-space-request
Would you take a check for $50 million USD instead of the /10? Sounds like they are equivalent value. http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Wed, Nov 30, 2011 at 6:57 PM, Ralph Droms rdroms.i...@gmail.com wrote: On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote: Ralph, Please note the following report: WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf) Thanks for the reference. Do you have an easy pointer to retrieve the doc? I'm curious about how the data was gathered and what conclusions are drawn. - Ralph http://member.wide.ad.jp/tr/wide-tr-kato-as112-rep-01.pdf I don't find this document to be very convincing that residential services cannot be well served by 10.64.0.0/10. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 29, 2011 9:46 PM, Mark Andrews ma...@isc.org wrote: In message m2r50q42nn.wl%ra...@psg.com, Randy Bush writes: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. 240/4 is not treated as unicast / routable by many OS. Necessity is the mother of invention. There was already an assumption that patches will be made for draft-weil, 240/4 will cut deeper for sure. Truth told, I only started ipv6 pushing after my 240/4 efforts proved fruitless with the ietf and my vendors. I hope the networks supporting draft-weil can turn that same corner. Cb i will spare you cites to the measurements of patch installation, or lack thereof. Skype, by default, will tell you when there is a patch available. Also if you don't patch you are not in a worse position than you will be when your ISP starts to hand you ambigious addresses that are not identified as such. What we do in is a way for the customers to request non-ambigious addresses in response to DHCP/PPP etc. requests along side this allocation and for the return address to be properly annotated. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Consensus Call: draft-weil-shared-transition-space-request
On Mon, Nov 28, 2011 at 3:07 PM, Fred Baker f...@cisco.com wrote: In my opinion, having a designated space is better than squat space, given that we we already know that squat space is being used. The argument that it extends the life of IPv4 is, IMHO, of limited value; yes, it allows operators to keep their IPv4 service running; given the number of CPE Routers that lack IPv6 capabilities, that will likely be necessary for the equipment lifetime of a CPE Router barring extraordinary activities on the part of vendors and operators to replace the current load of CPE Routers in favor of IPv6-capable upgrades. IMHO, the space should be allocated. On Nov 28, 2011, at 1:25 PM, Ronald Bonica wrote: On October 10, 2011, the IESG issued a last call for comments regarding draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for Shared CGN Space). While the community did not display consensus supporting the draft, it also did not display consensus against the draft. Therefore, I will submit the draft to the full IESG for its consideration at its December 1 teleconference. The draft will be published as a BCP if a sufficient number of IESG members ballot Yes or No Objection, and if no IESG member ballots Discuss. Because the decision to submit this draft to the full IESG is controversial, I will explain the decision making process. The IETF has a precedent for interpreting silence as consent. Typically, if a last call elicits no response, the draft is brought to the full IESG for consideration. The October 10 last call regarding draft-weil-shared-transition-space-request-09 evoked only two responses. One response supported publication of the draft while the other was opposed to it. The respondent voicing support for the draft offered no rationale. The respondent objecting offered many editorial comments, but almost no rationale for blocking the draft once the editorial comments are addressed. Because the October 10 last call elicited so little response, and because many community members have privately expressed strong opinions regarding this draft, I will summarize outstanding issues below. The following are arguments *against* draft-weil-shared-transition-space-request: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Arguments *supporting* draft-weil-shared-transition-space-request-09 assume that operators will deploy CGNs and will number the interfaces between CGN and CPE. If the /10 proposed by draft-weil-shared-transition-space-request is not allocated, operators will number from one of the following: - public address space - RFC 1918 address space - squat space If operators number from public address space, they will deplete an already scarce resource. If operators number from RFC 1918 space and the same RFC 1918 space is used on the customer premise, some CPE will behave badly. The consequences of numbering from squat space are determined by the squat space that is chosen. In summary, allocation of the /10 will have certain adverse effects upon the community. However, failure to allocate the /10 will have different adverse effects on the community. The IESG is being asked to choose the lesser of two evils. Given that this is not a last call but folks are weighing in anyhow, i will say i oppose this allocations. This is taking legitimate IPv4 public space from people who need it, and without SOP justification, giving it to an industry segment who has not deployed IPv6 in the 10+ years allowed to do so. IPv4 space has a market value. Making this allocation is effectively the same thing as the IETF giving these companies money to NOT deploy IPv6 and paying them to roll out CGN (feels like a farm subsidy). If there are really boxes in the ground that cannot do IPv6 (96 bits too much), then folks should spend the money to make 240/4 work. I was told the 240/4 fix was too expensive. Anyone on the black markets want to provide a spot market value of a of pristine /10 of ARIN space? I think i overheard that a /16 goes for about a million, but i dont actually know. CB ps. Just came across this HBS study on IPv4 prices and market, I have not read it yet http://www.hbs.edu/research/pdf/12-020.pdf ___ Ietf
RE: IPv6 support in hotel contract?
On Oct 21, 2011 6:07 AM, George, Wes wesley.geo...@twcable.com wrote: From: Andrew Allen [mailto:aal...@rim.com] We can put all kinds of wonderful constraints on hotels if we want to - [snip] - then we will likely never be able to meet anywhere. [WEG] I am not suggesting that this be a deal-breaker constraint. We have quite a number of nice to have items that we will ask for, but not necessarily take our business elsewhere if we do not get. The sense I get from IAOC is that dates, capacity, and cost are the constraints. IPv6 support is window dressing (or deck chairs, depending on your perspective). There is no harm in putting it in as a nice to have, and this is the type of thing makes a good tie-breaker and puts ipv6 on the radar. If the ietf cannot even make this simple request (not even a requirement), we are in a sad sad state. Cb IF IPv6 really requires IETF to use its business to influence hotels to adopt it then its a technolgy that deserves to go the way of the DoDo. IPv6 will be adopted because it is needed and brings commerical benefits to those that deploy it. [WEG] This is not an attempt to force *whether* IPv6 will be deployed, but when. Hotels are sort of an extension of the consumer space - right now, they don't know/care what IPv6 is, nor see a reason why it's necessary. It is quite unlikely that your average person will walk to the counter and say, your internet service is partially broken because it doesn't support IPv6. It is even less likely that this will happen enough times that they say, gosh, perhaps we need to look into this eye pee vee six thing... IETF has some leverage, and by definition should be on the early adopter curve, so I'm simply suggesting that they use it to accelerate the timeline a bit. From: Cullen Jennings [mailto:flu...@cisco.com] I love the taste of dog food, but v6 in the hotel is not something that I find critical to accomplish the task I come to IETF to get done. [WEG] We're working contracts for hotel venues 3+ years out at this point. How long are you willing to assume that IPv6 will not be critical to tasks that you need to do at IETF and that the IPv4 service in the hotel will be an acceptable alternative? 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: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Thu, Sep 29, 2011 at 9:46 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. Is there a dependency on the existence of IPv4 literal so as to use the v4-interface provided by NAT46 code? IOW, does every IP-only app work now on n900? Cheers, Rajiv No, not all apps will work due to ALG dependencies associated with NAT in general. If the app does not work via NAT, it still will not work. What this code provides is the ability for IPv4-only apps on IPv6-only networks to work using their normal NAT traversal techniques + IPv4 literals .. this includes, Skype, MSN, and the ability to type http://x.x.x.x into your browser. There is no panacea, except making the apps and services IPv6 native on IPv6 native networks, everything else is a hack and time to market is important ipv4 exhausted. Cameron -Original Message- From: Cameron Byrne [mailto:cb.li...@gmail.com] Sent: Wednesday, September 28, 2011 3:14 PM To: Rajiv Asati (rajiva) Cc: Mark Townsley; Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a will use a and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this dog food for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 28, 2011 2:51 AM, Hui Deng denghu...@gmail.com wrote: Hi Dan, Inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Monday, September 26, 2011 11:01 PM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Cb deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. Sorry. -d -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual- IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave- boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a will use a and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this dog food for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 26, 2011 6:58 AM, George, Wes wesley.geo...@twcable.com wrote: From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM To: Cameron Byrne Cc: IETF Discussion Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC Furthermore, I find this draft's statements about we are trying real hard to deploy ipv6 as not convincing... we are 10 years in on v6, no? I only seriously deployed ipv6 when it was clear the business had to deploy ipv6 there were no other choices. WEG] I really don’t think it’s useful to discuss penetration of “serious” IPv6 deployment based on absolute timescale for precisely that reason – until there’s a business reason, being visionary or leaders in the space doesn’t convince enough money to be shaken loose for that particular budget cycle or planning window. I think it’s more useful to look at the progress made since IANA exhaust actually happened and since some testing showed how bad CGN might be, signifying some idea of when this actually “got real” and at the next 12-18 months in terms of major last-mile providers and their rollout plans. Agreed. The ietf is trying to help these companies have a business reason for ipv6, not a business reason for nat444 ARIN is looking for the IETF to bless this because they know it's bad, they know this is a step in the wrong direction but the IETF made me do it... WEG] Well, no. ARIN is looking for the IETF to allocate this because they were told by the IAB that they couldn’t do it on their own, which sort of removes the teeth from the policy that their membership approved. I think that ARIN happened to be the first forum that the folks suggesting this (very much not new) idea found enough support to move it forward. That said, I don’t think that support for the idea is in any way specific to ARIN, it just came up at the right place and time. I think that more and more folks (myself included) are coming to the realization that the need is legitimate, and we sort of need to hold our noses and do it, and focus on making it less harmful rather than blocking it on philosophical grounds. And the step before that is that the people who now call themselves ARIN were told no before in the IETF directly, afaik. So it's the same people, same logic, but now they come to the IETF with a different name, same request, and they expext a different answer? Cb 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
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On Mon, Sep 26, 2011 at 9:41 AM, Keith Moore mo...@network-heretics.com wrote:
On Sep 26, 2011, at 10:07 AM, George, Wes wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
Of Keith Moore
Sent: Friday, September 23, 2011 10:04 PM
To: Cameron Byrne
Cc: IETF Discussion
Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt
(IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote:
So if there is going to be breakage, and folks are willing to fix it over
time because the good outweighs the bad (I personally do not believe this),
then why not dedicate 240/4 for this purpose? The 240/4 work has been shot
down multiple times ( I don't know the history ), are we now changing the
rules for the end run ?
It's hard to know for sure, but I believe there's greater risk associated
with use of 240/4 than with a /10 from existing public IPv4 space. That is,
I think more software would be needed to allow 240/4 to be used reliably.
WEG] you know, the more I think about this line of logic, the more I wonder
about it.
In essence, the 240/4 problem is that lots of host and router
implementations have one or more functions in their input validation code
that says “240/4 == invalid” thus preventing you from configuring or using
it. To my (admittedly oversimplified) view, this is a simple matter of:
1) Search source code for “240”
2) Comment out any relevant code you find
3) Recompile, test (changes only), ship
I’d be happy for one or more folks who have some experience with the
appropriate bits of Windows, Linux, MacOS, IOS, JunOS source code would
explain where I’m oversimplifying.
I think that's basically right. The problem isn't in the difficulty of
finding these changes and fixing them, for currently maintained code. The
problem is in the zillions of systems in the field that have assumptions
about 240/4 wired into them, most of which either have no automatic upgrade
mechanism, aren't set up to use it, or aren't being maintained. This is
of course, in addition to any changes that have to be made to application
software because of its wired-in assumptions about 240/4. By contrast, if a
/10 from public unicast IPv4 address space is used, only the application
software has to be changed (if the application software needs to care about
whether an address is ambiguous). That's a much smaller impact, though
probably still a significant one.
Actually it wouldn't bother me personally if the /10 were specified only for
use with DS-Lite or with some other service that provided native v6 prefixes
to customers in addition to any IPv4 service...though I don't know of any
way to enforce that.
This is the 2nd time DS-lite has come up, this comment is off topic,
but i want to make sure the inputs are right.
DS-lite would not use this space and does not need this space, DS-lite
assumes the following: RFC1918 + IPv6 public in the end-site (my home)
with a B4 tunneling home gateway, IPv6-access network (DSL/Cable
access network), and public routable space in the CGN/AFTR.
DS private IPv4 LAN -{IPv6 only access network} CGN Internet
draft-weil space is only for what draft-weil says it is for, and that
is the NAT4'4'4, the middle 4 SP access network or to facilitate
6to4-PMT (NAT66 of 6to4).
IPv4 LAN ---IPv4 access with shared space CGN --- Internet
IMHO, this allocation does not move IPv6 forward... it just makes
NAT444 more possible and fixes 6to4 so that the IPv6 part returns to
the correct IPv4 NAT network.
DS-lite does move IPv6 forward.
But, AFAIK, the draft-weil folks want a /10 so that they don't have to
spend money to upgrade their access network or associated CPE. In
this way, end points that need real unique IPv4 space are subsidizing
the upgrade deferral of these networks.
Cameron
I’m willing to write a draft about it if there are people willing to support
it, but I only have so many windmills that I can tilt at per cycle, so I’d
like to hear support either privately or publicly before I undertake it.
Honestly I'd guess that if vendors started changing their code today, it
would be 10 years before 240/4 could be widely used in the field.
Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On Sep 24, 2011 8:36 AM, Benson Schliesser (bschlies) bschl...@cisco.com wrote: On Sep 23, 2011, at 20:54, Cameron Byrne cb.li...@gmail.com wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? 240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be fixed over time in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed. For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444. This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution. Cheers, -Benson Let's avoid having yet another thread where there is no consensus but the parties continue to restate their claims over and over. I don't see anything new in what you wrote. Things happen fast when revenue is on the line. Now, if you are in the business of selling ipv4 address space on the secondary market, as folks have linked to you before on the nanog list, you must like the idea of pushing out ipv6 deployment in favor of the broken nat444 ipv4 ecosystem platitudes about ipv6 aside. Here you claim to be friends with ipv4 black-marketeers http://diswww.mit.edu/charon/nanog/139751 The ietf must stick to the guidance that ipv6 replaces ipv4, not that shady black markets and middle boxes replace ipv4. Now, my motivation -- I have taken the ietf guidance and have laid the ground work for deploying ipv6 to mass consumers in the near term. The ietf has been unequivocal that ipv6 is the path forward for years. As an ipv6 network, I am subject to Metcalfe's law... meaning, if I am the only one doing v6 I am in bad shape, but if everyone else has been listening to the ietf in good faith, then ipv6 will be deployed soon (as ipv4 depletes) and Metcalfe's law is a fortuitous cycle of compound benefits for me, ipv6 networks, and ipv6 users. And, conversely, efforts to prolong ipv4 are a direct inhibitor to my short term and medium term benefits in deploying ipv6. The IETF prolonging IPv4 with this effort is changing the rules of the game and overturning well known and long standing precedent, including not joining 240/4 with public or private pools. Governing bodies should not overturn long standing precedent and change the rules of the game at critical times where change is required. Cb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 23, 2011 1:41 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-09-23 17:21, Benson Schliesser wrote: However, I would like to make sure we don't lose sight of the need for some urgency with draft-weil. I'm a little puzzled by the claim of urgency; I remember hearing in July 2008 that doom was imminent if this was not done immediately. I thought that the urgent issue was deploying IPv6. On 2011-09-23 20:38, SM wrote: ... I suggest that ARIN publishes its policy through the Independent Stream and documents the IPv4 addresses that will be used for so-called shared transition space. What makes you think that the Independent stream would publish such an RFC, which on the face of it would be a complete end-run around the IETF process, and fly in the face of the IAB position? +1 Additionally, this network operator and ARIN member is fully opposed to any shared address draft. Real routable addresses are need for real routable systems. There is no free lunch, these efforts should be focused on making 240/4 work or doing ipv6, not ripping of really working ipv4 space. Both of the above are hard ... sorry. Cb Brian ___ 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: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 23, 2011 6:20 PM, Keith Moore mo...@network-heretics.com wrote: I already made one Last Call comment, but I neglected to state unambiguously whether I supported the proposal. I do support this proposal. I think that this question needs to be viewed as a choice between two risks: 1) the risks associated with this proposal 2) the risks associated with reuse of RFC 1918 address space by ISPs, and/or reuse of public IPv4 address space by ISPs To me it seems clear that the risks associated with this proposal are less than the other risks. Software that assumes that IPv4 space other than RFC 1918 space is unambiguous will break in either case. But at least with this proposal, there's a well-defined and easily-understood path to fix such software to minimize the breakage. It needs to be understood that at this point, there is no path that will avoid widespread breakage of much existing IPv4-based software, including some software that is widely used. Upgrades to that software will be needed in order to continue using such software on a widespread basis. Furthermore, even with such upgrades, the reliability of IPv4-based applications can generally be expected to decrease over time. There is no path to permit IPv4-based applications to continue to be used reliably, at Internet scale, over the existing Internet infrastructure. So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? The 240/4 work has been shot down multiple times ( I don't know the history ), are we now changing the rules for the end run ? For my use case, a /10 does nothing. I use tens of /8s of squat space... A /4 would really help... or having everyone really moving vendors and networks to ipv6because they have to if this draft goes through, there is clearly less business pressure to solve the numbering problem and there will be new business pressure to roll out nat444 Furthermore, I find this draft's statements about we are trying real hard to deploy ipv6 as not convincing... we are 10 years in on v6, no? I only seriously deployed ipv6 when it was clear the business had to deploy ipv6 there were no other choices. ARIN is looking for the IETF to bless this because they know it's bad, they know this is a step in the wrong direction but the IETF made me do it Cb 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: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 12, 2011 8:51 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. +1 Nat464 has been shown to overcome real world issues, it solves a real problem. Additionally the bih mapper should not have to require DNS so that ipv4 literals can be overcome Cb Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ No IPR declarations have been submitted directly on this I-D. ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ 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: [v6ops] 6to4v2 (as in ripv2)?
On Jul 28, 2011 1:08 AM, Philip Homburg pch-v6...@u-1.phicoh.com wrote: In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote: In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that. Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them. I would hope that big companies like Apple would actually do an impact analysis before removing a feature. Like how Apple does not support Flash in iOS? Just one example where a visionary drops an inferior solution to force a better one. This is also known as cracking some eggs to make an omelet. Cb Big content providers can measure how much 6to4 is enabled, so they can probably say something about trends. But that doesn't say much about how many users actually care about 6to4. Vendors seem to be best equiped to analyse the users' need for 6to4. I don't think relay operators have expressed a desire for a specific cut off date. So I guess they just figure out for themselves when to switch off the relays. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote: Masataka Ohta wrote: It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. The primary reason why the IPv4 - IPv6 transition is so painful is that it requires everyone one and everything to become multi-homed and every software to perform multi-connect, even though most devices actually just have a single interface. It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). This is largely (not entirely) achieved with nat64 / dns64. Cb. -Martin ___ 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: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011 4:32 AM, Mark Townsley m...@townsley.net wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 +1 as well as 6in4 or native v6. The full requirements of 6to4 are based on currently unrealistic requirements for no-nat (apnic is post exhaust ) and service providers to stand up relays without a reasonable business case - Mark ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011 7:20 AM, Ted Lemon ted.le...@nominum.com wrote: If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol. It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight. Cb ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011 8:16 AM, Mark Andrews ma...@isc.org wrote: In message 968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com, Ted Lemon writes : If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. You also have content owners that say no while 6to4 is tanking reliability stats. Pick your battles. Cb This seems like an easy question to answer. You'd implement and use 6to4v= 2 because it works better than the historic 6to4 protocol. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: 6to4v2 (as in ripv2)?
On Jul 27, 2011 8:30 AM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? free.fr, which is a third of the worldwide IPv6 traffic. Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. The difference is in who configures/manages it, not how it works; the 6rd code base is a superset of the 6to4. The difference is more a matter of network design than core protocol. 6rd also evolves 6to4 with a real and traceable support model. Cb Michel. ___ 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: draft-ietf-v6ops-6to4-to-historic (yet again)
I approve of this approach. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Dropping 2002::/16 considered very harmful
I, for one, am not interested talking about 6to4 anymore. On Jul 8, 2011 4:36 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-07-08 19:16, Roger Jørgensen wrote: Guess I should clearify something, the thing I am considering are to drop all 2002::/16 addresses hard, of course preferable return a correct error messages to. This is an awesomely bad idea. As explained in the approved advisory document, it makes things worse for everybody (the user, the content provider, and the unfortunate person answering calls from either of them at the help desk). On the contrary - it's in everyone's interests to have the return path working. Once a user manages to get a packet to the content provider, everybody suffers if the return path fails. (However, if you are announcing a route to 2002::/16, it must lead to a relay that will relay all 6to4 packets, with no form of ACL). Brian ___ 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: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011 12:29 AM, Keith Moore mo...@network-heretics.com wrote: On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote: Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. Mostly. Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.Both 6to4 and NAT are things that are useful in some cases and cause harm in others. Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm. Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives. Cb But it wan't a serious suggestion, just an analogy. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? I've already said on several occasions that I agree that 6to4 should be off by default. It's mostly the Historic label that I have the problem with. (I have other objections to the document also, but those are just places where I think the wording is misleading. The label is the big thing.) Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011 7:14 AM, Keith Moore mo...@network-heretics.com wrote: On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote: In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking on ipv4 ). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance. Thanks for your time and have a great weekend. Cb Saying that no new 6to4 installation should be deployed and that existing 6to4 users should migrate to other tunneling techniques assumes that all installations and users have the same needs, namely, to access content over IPv6 that is also available over IPv4. The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. The label broken 6to4 setup is misleading. Most of the time, the thing that breaks 6to4 is not the user's setup; it's an ISP somewhere that is either (a) advertising a bad relay or (b) filtering protocol 41. (If the problem were the users' setups, the providers could just say not our problem; fix your 6to4 setup) What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. From my understanding of bittorrent, it will just find other routes. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. You completely misunderstand both the situation, and the size and diversity of 6to4 users. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. 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. Welcome to the ietf indeed. Cb 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. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: 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 I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. That's not what it means to me. REAL IPv6 is a replacement for IPv4 and can address greater than 100s of billions of endpoint and is suitable for very large traffic loads. As an access network provider, i need content on native IPv6. It does not make sense to anyone in my organization or industry to deploy IPv6 unilaterally. There is no benefit in this approach vs just doing NAT444. If there is IPv6 content on a meaningful scale ( by the numbers that means for my network: Google, Facebook, Yahoo and their CDNs ...), then i have a solid business case for IPv6 access networks. Full Stop. If the content guys say 6to4 is a pain, and they do, then i need to help them find a way to solve that pain. I operate in an address exhausted world, so NAT44 is my only IPv4 tool for growth. In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Fri, Jul 1, 2011 at 12:12 PM, Joel Jaeggli joe...@bogus.com wrote: On Jul 1, 2011, at 11:55 AM, Scott Brim wrote: On Fri, Jul 1, 2011 at 14:34, Joel Jaeggli joe...@bogus.com wrote: On Jul 1, 2011, at 11:07 AM, Martin Rex wrote: james woodyatt wrote: There is nothing about NAT or dynamic subscriber IP assignment that provides any mitigation whatsoever of the risks I'm more than a little concerned by the message that you're sending here. European legislators have enacted a E-Privacy Directive also dubbed European Cookie Directive in order to protect the privacy of citizens, and you're suggesting here that the IETF should actively subvert this legislation and similar ongoing legislative initiatives in the US by assigning static IPv6 addresses to home DSL subscribers so that cookies are completely obviated and everyone can be trivially tracked based on his static IP-Address. This means you want to make IPv6 addresses and all communications with that address direct personally identifiable information, something for which a must informed beforehand, let alone an opt opt is technically impossible? The IETF has several times veered away from the deep water where internet standards cross paths with regulatory requirements. http://tools.ietf.org/html/rfc2804 We are not legal experts we are not qualified to interpret the statutory requirements of various nation states, our own or others. We need to be clear on what is in vs out of scope for IETF work. Focus on what would be percieved to be in the best interests the users and the network. Nation states will do whatever they do and sovereign by definition can impose whatever mandate they find necessary on their network operations and citizens. Joel, the issue is very clear: what the IETF does must not make privacy and confidentiality impossible. It's not just some arbitrary regulation from a committee, there are whole cultures who take this very seriously. You cite the wiretapping decision -- note we didn't make wiretapping impossible, we just didn't support it. In this case it is very easy to make privacy (the right to control personal information) and confidentiality (the right to know that private information you share with one party will be kept within that scope) impossible -- that's a position you may not take as someone making the Internet work, since the ultimate stakeholders are those humans out at the edges. See also Changes to Internet Architecture Can Collide With Privacy http://www.ietf.org/proceedings/79/slides/intarea-3.pdf for a discussion of mobility. You and I are in complete agreement when is comes to not making privacy or confidentiality impossible... Where I object strenuously is when a directive wether it comes from the EU, the USA or the PRC becomes the consideration for framing a debate. The dictates of sovereigns are likely effectively impossible to reconcile if included fully in this space. Bases some Wikipedia research, there is some regulations about browser cookies, and no mention of IP addresses. There is some mention about web servers not retaining info without an opt-out clause... My analysis is very high level, i don't have the details, but at first brush it seems like there is some conflation going on here between cookies and IP addresses and what a home network looks like vs what web servers retain in their logs. I fail to see how this an IPv4 vs IPv6 issue? Static vs Dynamic? Cameron in 2804 the summary position is quite succinct in this regard: The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards. We know therefore without equivocation where a doucment like the following fits in the IETF standards context. http://tools.ietf.org/html/rfc3924 we do not disallow the publication of such a document, in fact we should enoucorage it. but we also don't design to the soverign's requirements in the protocol specific. When you think oh right, I have to come up with a security considerations section, include privacy and confidentiality implications in your checklist of things to think about. In this context if we fail that badly we have a problem. As to the technical issues here, higher layers don't need to use IP addresses as identifiers, they have their own. The only layer that needs to care about IP addresses is the IP layer itself. Privacy addresses are well-defined and well-deployed. The only issue with using them is monitoring and logging activity. The first hop router can make the necessary correlations, but some access providers think that's expensive. Lawsuits over breach of confidentiality can be even more expensive. So is reworking protocols when a third of the world won't use them. Scott ___ Ietf mailing list Ietf@ietf.org
Re: HOMENET working group proposal
On Jun 29, 2011 7:19 PM, Fernando Gont ferna...@gont.com.ar wrote: Hi, Jari, My high level comment/question is: the proposed charter seems to stress that IPv6 is the driver behind this potential wg effort... however, I think that this deserves more discussion -- it's not clear to me why/how typical IPv6 home networks would be much different from their IPv4 counterparts. Bellow you'll find some comments/questions about the proposed charter. They are not an argument against or in favour of the creation of the aforementioned wg, but rather comments and/or requests for clarification... On 06/29/2011 05:47 AM, Jari Arkko wrote: [] o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. NAT devices involve two related but different issues: * address translation * an implicit allow only return traffic firewall-like functionality One would hope/expect that the former will be gone with IPv6. However, I don't think the latter will. As a result, even when you could address nodes that belong to the home network, you probably won't be able to get your packets to them, unless those nodes initiated the communication instance. For instance (and of the top of my head), this functionality is even proposed in the simple security requirements that had been produced by v6ops. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. I personally consider this property of end-to-end connectivity as gone. -- among other reasons, because it would require a change of mindset. I'm more of the idea that people will replicate the architecture of their IPv4 networks with IPv6, in which end-systems are not reachable from the public Internet. The opportunity for restoring e2e is one of the great opportunities of ipv6 and it is my hope this new WG will drive that with facts and take on fud. The utility of network based spi firewalls is debatable. Likely a never ending debate. Cb Thanks! -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ 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: Why ask for IETF Consensus on a WG document?
On Fri, Jun 24, 2011 at 11:53 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com I suspect that operators are *severely* under-represented on this list (ietf@ietf.org) because it is very noisy and operators have other priorities. Yes, and this thread is noise. In fact, Noel comments are specifically off-topic and should be a new thread which can get added the old thread about 6to4. Ah, operators. This would be the same group of people of whom, if the recent anecdotal reports are much to go on, many (most?) are not bothering to deploy IPv6 at all? Which operator is not actively working on IPv6 projects *right now*? Seriously, that old statement does not hold water today. (Something which would seem to be very common among smaller operators, whom one assumes, in typical long-tail fashion, form the majority of the group.) But their views are paramount? I see. Not taking the bait. Let's move. Noel ___ 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: RE: RE: one data point regarding native IPv6 support
On Jun 12, 2011 11:26 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Cameron Byrne wrote: The faint promise of yet another transition mechanism is hardly a motivation to keep 6to4 around. The data (ripe ...) overwhelming proves default-on 6to4 clients + thinly deployed relays = unreliable ipv6 and ipv6 deployment obstacle. That's the difference between a fait promise and a proven failure. The promise of IPv6 native IPv6 is going to be deployed next year has failed for 10+ years in a row. Nobody believes in it anymore; your choices are to believe in yet another transition mechanism or switch to the post-mortem camp. I believe there is data to show this time is different (iana and apnic are exhausted, successful v6day, docsis 3.0 and LTE deployment ...) Get a life. Thanks Cb Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: one data point regarding native IPv6 support
On Jun 12, 2011 6:18 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Michel Py wrote: If you were to remove 6to4 and 6RD from the picture, that would set us back 10 years ago in terms of IPv6 adoption. Doug Barton wrote: Can you explain the exact mechanism by which what you're concerned about will occur? I don't see anything in the draft which prevents an ISP from deploying 6rd. There is not. OTOH, I am not aware of any sizeable deployment of 6RD outside of AS12322; 6RD may not be for everyone, and what making 6to4 historic may prevent is: someone else using 6to4, finding out that there are some issues, and coining another highly successful 6to4 variant that would fit their needs better. The faint promise of yet another transition mechanism is hardly a motivation to keep 6to4 around. The data (ripe ...) overwhelming proves default-on 6to4 clients + thinly deployed relays = unreliable ipv6 and ipv6 deployment obstacle. Cb Michel. ___ 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: [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 Jun 7, 2011 12:16 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 7 Jun 2011, at 07:33, Gert Doering wrote: Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. +1. Let's move on and not repeat this tired discussion. Cb Tim ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
On May 16, 2011 11:41 PM, sth...@nethelp.no wrote: How much longer does this list need to be to justify choosing better labels for this v6 dual-stack transition hack? returning different sets of resource records on the basis of the orgin of a query ala split horizon is not exactly new ground. By my observation, what is being done, satisfactorily meets the dictionary definition of a whitelist. the term was uncontroversial in the dicussion leading up to the wglc. If it's really inapropiate that's cool but I'm frankly not convinced. Agreed. I see no good reason to change the use of whitelist. Let's move on. +1 for moving on Cb Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
