Re: chicago IETF IPv6 connectivity
Joel Jaeggli writes: Arnt Gulbrandsen wrote: IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. So basically, you're complaining that you came to the IETF and received production quality Internet service? I'm not complaining just yet. Mumbling. But if «production quality internet» would soon (e.g. IETF75 or -80) mean getting an IPv4 /19 when noone else can get that, I would complain. The discrepancy between the dogfood dispensed and the that eaten should not be _too_ wide. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Noel Chiappa writes: Guess that's the only way you can get people to convert to IPv6, huh - cut off their IPv4 access? Isn't that exactly what'll happen in a few years, and why IPv6 exists at all? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On 17-jul-2007, at 5:48, Keith Moore wrote: what is the problem you have with multiple-addresses-per-host problem? i never had any problem even with IPv4. it's the fact that in IPv6 if you don't select the best source and destination address to talk to a node, you might either fail to get a connection (and have to wait a long time for a timeout), or you might get a connection that performs much worse than some other source/destination address pair you could have used. this was true for IPv4 nodes with multiple interfaces also, but this was mostly solved in IPv4 by not having multiple active network interfaces. (people tried it, it didn't work well, so they stopped doing it.) In IPv6 the normal situation for hosts on multihomed networks is to have multiple addresses, and there are several pressures to have additional addresses - like for mobility, or using ULIAs for local apps on enterprise networks so that they won't be affected by renumbering. so address selection becomes more important in IPv6 than it was in IPv4. Moving topology decisions out of the hands of routing protocols and the people that build networks into hosts creates a lot of complications. BGP as we know it is pretty bad at selecting the best path, but it's fairly good at avoiding the bad ones, so it works well enough in practice. When you give a host a number of paths (as in source/dest address combinations) to choose from, it's doable (but not trivial) to avoid the non-working paths, but knowing that path X has a much higher capacity than path Y even though path Y does work is very hard, especially if we want to look further than the only easily measurable quality aspect: the RTT. But the entire existence of this problem stems from the notion that the entire communication must flow over a single path. If we let packets belonging to a single session flow over multiple paths, and then use standard windowing techniques such that paths that can accept more data get more data and paths that don't don't, we actually get to use the full aggregate capacity of the entire set of paths, and it's no longer necessary to invest complexity in discovery functions. BitTorrent already works like this to some degree by exchanging information over a large number of paths concurrently. I've also once been involved in implementing a system where we did this by hand by using several different TCP sessions. This didn't work at first because the program would round robin and block writing to the slow sessions so 10 + 100 Mbps = 20 Mbps but after fixing this 10 + 100 Mbps = 110 Mbps. Making this work well for applications that are interested in other quality aspects than aggregate throughput would be more difficult, though, but probably not as difficult as deducing QoS information from random sets of source/dest addresses. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
But the entire existence of this problem stems from the notion that the entire communication must flow over a single path. MPLS ECMP? RFC 4928? --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: i guess we are living with very different assumptions. it's just that the needs of applications vary as widely as the needs of users. it's not as if all Internet users do nothing but email and the web, and neither is it as if all Internet applications are like HTTP or ssh. if you are not under NDA, could you please be more specific? source code, RFC/draft for the protocol, whatever? i'm getting tired of this guessing games. what do you want me to do, describe in detail every distributed application that I've ever worked with? I'm not talking about any specific application, I'm generalizing from several applications that I've worked with and/or am otherwise familiar with. once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to- IPv6 looks much like SMTP relaying. true. ALGs are okay for applications that have explicit intermediaries, like SMTP. I don't like ALGs so much when they're used as interception proxies. sometimes they work okay, sometimes not. do not underestimate my paranoid-ness, i'm an OpenBSD developer somehow, I think this should be on a t-shirt, or a bumper sticker. :) [analysis of the many layers that could potentially modify traffic omitted] agree with all of those. but it sounds like you're close to arguing that because there are so many other things that can screw with DNS, it's okay for getaddrinfo() to return bogus results too. in general, things that alter or spoof network traffic are evil. they are evil whether the traffic being altered or spoofed is IP, TCP, UDP, DNS, or a higher-layer protocol; they are evil whether the altering or spoofing is being done on the wire (by modifying packets) or at the API level. all of those things make it more difficult for applications to get consistent, repeatable behavior out of the network. what is the problem you have with multiple-addresses-per-host problem? i never had any problem even with IPv4. it's the fact that in IPv6 if you don't select the best source and destination address to talk to a node, you might either fail to get a connection (and have to wait a long time for a timeout), or you might get a connection that performs much worse than some other source/destination address pair you could have used. this was true for IPv4 nodes with multiple interfaces also, but this was mostly solved in IPv4 by not having multiple active network interfaces. (people tried it, it didn't work well, so they stopped doing it.) In IPv6 the normal situation for hosts on multihomed networks is to have multiple addresses, and there are several pressures to have additional addresses - like for mobility, or using ULIAs for local apps on enterprise networks so that they won't be affected by renumbering. so address selection becomes more important in IPv6 than it was in IPv4. ok, so you are basically worried about uRPF, performance difference, and/or firewalling policy differences when you have multiple exit links. do not take it as a self-promotion, but my take on this is in RFC3178. it's not just multiple exit links, it's having multiple addresses per host for any number of reasons. (mobility, renumbering, the desire to have stable local addresses, and also the possibility of multiple active network interfaces) but things like RFC 3178 do help. if we can get back to the expectation that one address per host is the normal case, we'll make life much simpler for application writers. so i can solve problem for Skype, so i guess i can solve problem for your distributed computation system. want to hire a consultant? :-P I can solve it too, and have done so on a couple of occasions. but I don't pretend that it's easy to retro-fit every existing distributed application (or to build every new distributed application) to handle multiple realms. NATs have drastically raised the burden on applications by dividing the Internet up into multiple address realms; similarly, IPv4/IPv6 coexistence also divides the Internet up into multiple address realms. Thus a mixed IPv4/IPv6 network is almost as dysfunctional as a NATted IPv4 network. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On 2007-07-17 11:04, [EMAIL PROTECTED] wrote: ... it is not reasonable to assume that for all apps the correct model is to do a DNS lookup and then try the resulting IP addresses one at a time until a connection succeeds for one of them. For instance, applications in the global finance industry typically do not do any DNS lookups at all. Admittedly, they often have a list of destination IP addresses which they try until a connection succeeds. But the point is that IPv6 transition has to be explicitly programmed into each and every application and it has to be embedded in the operational processes as well. Which is in fact the exact same logic a dual stack application should follow after calling getaddrinfo(). Whether or not you resolve a name to get the list of addresses, you need the logic to try all available addresses in turn. otoh, I've never yet found an application programmer who found upgrading to the new socket API to be especially challenging; it's just work. As Michael says, it has to be done for each application. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
For instance, applications in the global finance industry typically do not do any DNS lookups at all. Admittedly, they often have a list of destination IP addresses which they try until a connection succeeds. But the point is that IPv6 transition has to be explicitly programmed into each and every application and it has to be embedded in the operational processes as well. Which is in fact the exact same logic a dual stack application should follow after calling getaddrinfo(). Whether or not you resolve a name to get the list of addresses, you need the logic to try all available addresses in turn. well, it depends on the application. sometimes the delay required to try all of the addresses in turn until one is found to work is not acceptable, and at other times it's very annoying... particularly when the default address selection rules don't predict which (source,destination) address pair is going to work best. otoh, I've never yet found an application programmer who found upgrading to the new socket API to be especially challenging; it's just work. the problem isn't the differences between the v4 and v6 socket API. the problem is the expectation that in IPv6 the application has to choose which address(es) to use, coupled with the high probability that the first address(es) chosen will not work well. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Your old one is 802.11B or G and you want G or N Your old one is IPv4 and you want IPv6. Does anybody believe that the transition to IPv6 at the edge is *NOT* going to require a complete replacement of gateway devices? Given that transitioning the Internet provider edge to IPv6 is going to result in a wholesale replacement of Internet gateway devices, shouldn't the IETF have some clear guidance on the capabilities of an IPv6 gateway? Such a device is not merely a router/switch, but also manages the site boundary (ULA addressing), probably should include firewalling with sensible defaults, and so on. And given that IPv6 is uncharted territory, wouldn't it make sense to specify that the software in an IPv6 gateway should be easily upgradeable? New technology washing machines use less water and power, destroy fewer clothes and clean better, but when was the last time you upgraded? Water, detergent and clothes have not changed as much as IPv6. In any case, at least one chain of stores in the UK advertises that they will take away your old appliance free if you order a new A-rated energy-saving appliance from them. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. okay. if you could name them we can try to convince people who are responsible. the people responsible for polluting the network with NATs? it's too late to punish them, I fear :) no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. you have it backwards. It is the NATs that are unfriendly to apps, not the other way around. it's easy to write a distributed app that can handle the case where all nodes are IPv4, or the case where all nodes are IPv6. it is much more difficult to write such an app that can handle the case where some nodes are IPv4, some are IPv6, some are both, and there is a need to communicate between arbitrary pairs of nodes within the app and to allow some nodes to do referrals to other nodes. DNS names are not a good way to solve this problem for reasons of performance and reliability and because a DNS name does not, in practice, uniquely bind to a particular host. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P and the rest of us are very appreciative! of course, not all of the applications that people use are those that are shipped with *BSD. and while it's quite helpful if programming languages support IPv6, that doesn't mean that the programs written in those languages will automatically work with IPv6. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. it is not reasonable to assume that for all apps the correct model is to do a DNS lookup and then try the resulting IP addresses one at a time until a connection succeeds for one of them. that, and getaddrinfo() is broken in a great many ways: it isn't tied to DNS (so if your app is defined to use DNS then you can't trust getaddrinfo() to do what your app needs); even if the implementation does use DNS, getaddrinfo() can only do A and queries, it's not asynchronous, and the whole idea that a host stack can select a source/destination address pair by trial-and-error and get good results within a reasonable time is, quite frankly, a joke. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? code then spec. no, it's not a theoretical debate. I worked with a number of distributed systems: PVM, some MPI implementations, and one of my own design that didn't become so popular. There are a lot of applications layered on top of one or the other of these. But unless you're into high-performance computing you probably aren't aware of them. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. I don't work there any more, and none of the people whom I knew that worked on those codes work there any more either. one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd love to see further development and standardization of multipath TCP - that seems like a very promising avenue) there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. ssh is not a bad protocol, but it doesn't solve the multiple-addresses-per-host problem, even if you change it to allow peers to re-connect (which would be a nice feature). please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. this isn't a multicast or broadcast problem I'm speaking of. I'm speaking of the need for the network to provide complete connectivity between arbitrary pairs of nodes in a distributed system. you have to. you cannot be that lazy. our goal in IETF should be to allow programmers to be that lazy. separation of function between the host and the network is a Good Thing. let the hosts exchange packets and
Re: chicago IETF IPv6 connectivity
i guess we are living with very different assumptions. no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. you have it backwards. It is the NATs that are unfriendly to apps, not the other way around. i guess we agree on this point, but recent IETF documents got it backwards so i worded it the way presented in the above. it's easy to write a distributed app that can handle the case where all nodes are IPv4, or the case where all nodes are IPv6. it is much more difficult to write such an app that can handle the case where some nodes are IPv4, some are IPv6, some are both, and there is a need to communicate between arbitrary pairs of nodes within the app and to allow some nodes to do referrals to other nodes. DNS names are not a good way to solve this problem for reasons of performance and reliability and because a DNS name does not, in practice, uniquely bind to a particular host. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. it is not reasonable to assume that for all apps the correct model is to do a DNS lookup and then try the resulting IP addresses one at a time until a connection succeeds for one of them. without giving out the details of your correct model we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a fact or correct model because we cannot define them. that, and getaddrinfo() is broken in a great many ways: it isn't tied to DNS (so if your app is defined to use DNS then you can't trust getaddrinfo() to do what your app needs); even if the implementation does use DNS, getaddrinfo() can only do A and queries, it's not asynchronous, if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. and the whole idea that a host stack can select a source/destination address pair by trial-and-error and get good results within a reasonable time is, quite frankly, a joke. we agree on this point. i'm having trouble understaing the entire source address selection stuff. it won't get deployed nor properly managed. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. I don't work there any more, and none of the people whom I knew that worked on those codes work there any more either. ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik nordmark/sun microsystems). there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. ssh is not a bad protocol, but it doesn't solve the multiple-addresses-per-host problem, even if you change it to allow peers to re-connect (which would be a nice feature). what is the problem you have with multiple-addresses-per-host problem? i never had any problem even with IPv4. please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. this isn't a multicast or broadcast problem I'm speaking of. I'm speaking of the need for the network to provide complete connectivity between arbitrary pairs of nodes in a distributed system. describe what is complete connectivity in your definition. are you talking about QoS? then use vendor libraries that are URL-based. my, you have a simplistic view of the application world! you did not give me the details, so i have to guessing. the last note. i guess i have a clear idea about how to make Skype dual stack. current Skype protocol is totally IPv4-only (see silver needle in skype paper), but i can make it dual stack, i mean, mixture of
Re: chicago IETF IPv6 connectivity
i guess we are living with very different assumptions. it's just that the needs of applications vary as widely as the needs of users. it's not as if all Internet users do nothing but email and the web, and neither is it as if all Internet applications are like HTTP or ssh. if you are not under NDA, could you please be more specific? source code, RFC/draft for the protocol, whatever? i'm getting tired of this guessing games. sorry, you are, too lazy. remember the days when we had bitnet, decnet and compuserve (niftyserve in japan) in email world. we had a lot of technologies, or tricks i would say, to make emails get delivered from/to arbitrary networks. in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the Internet. of course. yes, I remember those, and I also remember the problems we had trying to make all of that work well - in particular, the problem of rewriting addresses so that the mail would still be replyable after it crossed multiple gateway boundaries. (actually I wrote a thesis on the topic). I'm sure my experience with email addressing and gateways is part of why I could see the problems with NAT earlier than most people. of course, it's not as if every application in the v4/v6 world is like email. at least some of those email protocols were designed to be store-and-forward and to allow email to be transmitted across networks without end-to-end connectivity.store-and-forward isn't appropriate for every applications protocol. (and I'd even argue that it probably shouldn't be used for email anymore, at least not in the way that SMTP currently does it, because it's really hard to arrange for errors to be reliably reported to the party that needs to know about them.) well, i'm sure there still are instances of Lotus Notes running in ancient enterprises. once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to- IPv6 looks much like SMTP relaying. if you could give v6ops people your comments from your experiences, it would be helpful. i know we have been trying and tired to death, but this year is THE right time. without giving out the details of your correct model we cannot discuss. go by mathematical rules, first you give me axioms and then we talk about your theories. do not call theories a fact or correct model because we cannot define them. I don't think there is a single correct model for all apps that works in a network where hosts have multiple addresses and the performance can vary significantly depending on which address pair you choose. yup, there's no single truth. we agree on that. ideally, from the application's point-of-view, the network would always perform well enough to suit the needs of the application and it wouldn't matter which source and destination address were used. also, any address would be reachable from any point in the network. the traditional IPv4 network approximately fulfilled both conditions; the current IPv4 network with NATs still mostly fulfills the first one. having multiple addresses per host/network be the normal case in IPv6 threatens to remove the first condition, and having a mixed v4/v6 network nixes the second one. if you want PTR, MX and NS records, use res_send and stuff. use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you want DNS resolution to happen for certain. I don't recall that this guaranteed by the API specification. do not underestimate my paranoid-ness, i'm an OpenBSD developer, and i'm proud of it! i've met both Steve Mann and Richard Stallman face to face, though i don't think they remember me. - getaddrinfo/getnameinfo standards do not say a thing about DNS lookup so you cannot trust it. of course if analyze the source code, you may. - res_send/res_query are not a standard so the behavior is not defined in documents. of course if analyze the source code, you may. - even if you write code that plays with UDP/TCP socket, you are unsure if there's any tricks inside OS kernel, like host firewall blocking or rewriting your queries/responses. of course if analyze the source code, you may. - even if you trust your OS kernel, you cannot trust your router, especially when it implements NAT and you are using it with NAT disabled. of course if analyze the source code, you may, but the likelyhood of getting source code is rather low. - even if you trust your router, you would not be able to trust your ISP, or peering ISPs. now it became impossible to look at source code, and/or configuration of all the routers. - even if you trust your L3 stuff, you cannot trust DNS trees.
Re: chicago IETF IPv6 connectivity
Thus spake Keith Moore [EMAIL PROTECTED] Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. That depends on the definition you're using. Many hosts are v6-capable, though I'd still debate whether it's the majority. Very, very few of those hosts have working v6 connectivity because there's some device(s) or provider(s) between the host and the DFZ that are v4-only. agreed, but you were talking about hosts. I do not consider a host dual-stacked, regardless of whether it's v6-capable, unless it can actually talk to remote hosts via v6. That may be imprecise on my part, but it's all that matters in the end. It's humans and software, not hardware, that is generally the problem getting v6 deployed. agreed about humans - mindshare is the hardest thing to overcome. the software/hardware question is a distinction without a significant difference. if the products (you think) you need to secure your network aren't shipping, it doesn't matter much whether what you need is new hardware or a software upgrade. often, that's just a matter of packaging. Ah, but there is a difference. Hardware is purchased in a 3+ year cycle, and generally involves significant capital outlay. Most hardware is v6-capable by this point, though apparently there's still issues in the load-balancer space that are preventing major content sites from dual-stacking. OTOH, v6 software is still not available from the majority of vendors, but if they do release it, it could be a free update (perhaps within the terms of a service contract) and deployed at any time. The distinction is moot, I'll agree, in parts of the market like consumer CPE where the vendors have a history of only releasing new software on new hardware, so a v6 upgrade will require hundreds of millions of people to buy new boxes even though their existing boxes would do v6 just fine if the vendors bothered to release new code for them. There's a lot of focus on NAT-PT for v6 sites to access remote v4-only sites; I'm focusing on the case of v4-only sites using NAT-PT to access remote v6-only sites. that's certainly an important case, but there are better ways than NAT-PT for v6-only sites to provide services to v4-only users. Perhaps. However, every other model I've seen assumes that all of those v6-only sites should pay the cost of making their services v4-accessible. That puts the cost in the wrong place, since it's v4-only sites that should be penalized for being laggards -- not the v6 early adopters, and also assumes that v4 addresses will remain available for them to implement those solutions. In a few years, that will no longer be true. There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. No, the second incentive remains. Fully deploying v6 is still a good idea because it removes the problems inherent to NAT-PT, which I've already acknowledged. yes, but everyone else's NAT-PT boxes still keep you from getting most of the benefit from your upgrade to full IPv6. In the short term, yes. OTOH, if everyone deploys NAT-PT today, then tomorrow it will _appear_ that the entire Internet is v6-capable, and I can convince management that deploying v6 for real is worth the effort. Today, there is virtually nobody I can reach with v6, so management isn't interested, resulting in a chicken-and-egg problem. IETF is useless if it doesn't try to describe what will work well in the long term. We all agree on the long-term vision. What we disagree on is what is the best method to get there from where we are today. I think that NAT-PT is no less evil than the v4 NAT we're using now and will get us to a NAT-free v6-only Internet faster than other strategies proposed. The shorter the transition is, the better things will be for all of us in the end. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
From: Stephen Sprunk [EMAIL PROTECTED] parts of the market like consumer CPE where the vendors have a history of only releasing new software on new hardware, so a v6 upgrade will require hundreds of millions of people to buy new boxes even though their existing boxes would do v6 just fine if the vendors bothered to release new code for them. In fact, I wouldn't be surprised if some vendors don't actually have an incentive for *not* releasing new code for existing boxes, because in some markets (e.g. the USA), the market for these sorts of boxes is close to saturated (as in, a high percentage of potential buyers already have one). So, the only way for these vendors to make a major sale (since people are unlikely to want to pay significant $$$ for a code upgrade - plus to which most people aren't going to want to fuss with upgrading anyway) is to obsolete the old boxes, forcing purchase of a new one... We all agree on the long-term vision. Not necessarily. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Noel Chiappa wrote: In fact, I wouldn't be surprised if some vendors don't actually have an incentive for *not* releasing new code for existing boxes, because in some markets (e.g. the USA), the market for these sorts of boxes is close to saturated (as in, a high percentage of potential buyers already have one). So, the only way for these vendors to make a major sale (since people are unlikely to want to pay significant $$$ for a code upgrade - plus to which most people aren't going to want to fuss with upgrading anyway) is to obsolete the old boxes, forcing purchase of a new one... Like desktop computers These products are being marketed on the basis of improved features to people who already have one... You got a new one because: Your dsl provider cpe is so flakey you want to chuck it. You've switched from dsl to cable. Your dsl cpe has only one ethernet jack on the back. Your cable cpe doesn't nat all your machines and your printer keeps crashing due to all the broadcast/probe traffic on your local segment. Your old one is 802.11B or G and you want G or N You want a gigabit ethernet switch included instead of 100Mb/s your old router had. The current one offers inadequate wireless coverage. You signed a contract for the the foo service offering from your cable/dsl/fixed wireless/cellular carrier and it came in the mail. We all agree on the long-term vision. It is hard to get people to desire a software feature on the device that they turn on and forget about and that it is worth running out and buying an upgrade especially if the one they have is still nominally working... New technology washing machines use less water and power, destroy fewer clothes and clean better, but when was the last time you upgraded? Not necessarily. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: 1) It eliminates the need for all sites to dual-stack their hosts between the time v4 exhaustion hits and the last v4-only site disappears, which could be a decade or more. There's also no sign this will actually happen in time without NAT-PT, leading to fragmentation of the Internet into v4-only and v6-only parts that can't talk to each other. 2) It may eliminate the need to dual-stack entirely; NAT-PT allows a site to flash cut from v4 to v6 without a long transition period. This would provide substantial cost savings to leaf site operators, many of whom are not deploying v6 today due to the perceived cost of dual-stacking. We remember the days of having to manage IP(v4), IPX, AppleTalk, DECnet, etc. all on the same network and aren't looking forward to returning to that mess. 3) Deployment of NAT-PT would instantly provide hundreds of millions of hosts that _appeared_ to be dual-stacked, accelerating the deployment of v6 and bringing forward the day we can turn off v4 in the DFZ (even if individual leaf sites are still v4-only internally). If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. Well, at least those that aren't actually caused by having a stateful firewall... Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. All of this applications for v6 aren't designed to cope with NAT stuff is bunk. Applications are designed to use both v4 and v6 because there's no market for v6-only apps. Apps have already paid the cost of dealing with NAT (if it affects them) and so will future apps until we can manage to drop v4 entirely. If NAT-PT allows us to drop v4 sooner, it's that much sooner app developers can stop paying that cost, and that's good for everyone. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: (snip) cannot agree more. i do not care if it is based on TCP/UDP relaying (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators have its own benefits. and of course drawbacks, but the drawback is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape plan (use native IPv6). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Stephen Sprunk wrote: Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: [arguments about NAT-PT avoiding the need to dual-stack hosts deleted] Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. Adapting existing networks to IPv6 is somewhat painful, but most of the deployed hardware supports it. On the other hand, adapting existing security policies, traffic filters, network intrusion detection systems, explicit and interception proxies is much harder. In some cases the products or upgrades don't even exist for IPv6, and when they do, they're not mature. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. That's like saying that if you are a IPv4 software developer and your applications won't work at your customers' sites because they have NATs, all you have to do is get rid of your own NAT and your customers' problems will go away. It simply doesn't work that way. NATs create problems even for people who don't use them. Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. All of this applications for v6 aren't designed to cope with NAT stuff is bunk. Applications are designed to use both v4 and v6 because there's no market for v6-only apps. Apps have already paid the cost of dealing with NAT (if it affects them) and so will future apps until we can manage to drop v4 entirely. If NAT-PT allows us to drop v4 sooner, it's that much sooner app developers can stop paying that cost, and that's good for everyone. All of these gross generalizations about applications are bunk. The patterns of interaction between nodes of an application, and the effect that NATs have on them, vary widely from one application to another. Any generalization of the form applications do X is dubious on its face. There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: (snip) cannot agree more. i do not care if it is based on TCP/UDP relaying (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators have its own benefits. and of course drawbacks, but the drawback is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape plan (use native IPv6). translators do have benefits, and can be mostly harmless with applied judiciously. the problems result from imposing translators in the signal path to/from a significant number of hosts that are running arbitrary applications. NAT-PT style translators can be just fine when used with a small number of specific hosts for which it is known that the applications on those hosts won't be harmed by the interposition of NAT-PT. though frankly, most users aren't capable of doing such analysis - just like most users don't understand the harm that NAT does. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On 13-jul-2007, at 19:08, Jun-ichiro itojun Hagino wrote: NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: cannot agree more. i do not care if it is based on TCP/UDP relaying (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators have its own benefits. and of course drawbacks, but the drawback is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape plan (use native IPv6). It seems like the discussion I was trying to start in v6ops is happening here instead... http://psg.com/lists/v6ops/v6ops.2007/ msg00467.html I don't think NAT-PT or transport relay are the best choices to allow IPv6 hosts to talk to IPv4 hosts, because they both require the insertion of boxes with very non-standard behavior in the network and a DNS ALG to get the packets to those boxes. Using existing proxies is easier, because they don't create DNS pollution or strange boxes, they're simply applications running on a server, like so many other applications. The fact that proxies are already widely deployed doesn't hurt, of course. (NAT-PT/transport relay require the host to do DNS lookups over IPv6 or have IPv4 connectivity for the DNS lookups, while proxying is even possible if the host doesn't have access to the DNS. Example: set up proxying towards an [IPv6 address] in IE7 on Win XP, which can't do DNS over IPv6 transport.) But we can't stop here, we need to provide a way to handle applications that have more extensive needs than those that can be met by a proxy as well, or the effect will be NAT/ALG stuff in IPv6. In my opinion, the easiest way to do this is to tunnel IPv4 over IPv6 on demand. I gather the softwires wg is working on that. So if we add some glue in the form of an API or logic that knows when to switch from proxying to real tunneled IPv4 connectivity and discovery / automatic setup we're in good shape and people can start removing IPv4 from their networks except at the borders where the translation happens. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
cannot agree more. i do not care if it is based on TCP/UDP relaying (per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators have its own benefits. and of course drawbacks, but the drawback is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape plan (use native IPv6). translators do have benefits, and can be mostly harmless with applied judiciously. the problems result from imposing translators in the signal path to/from a significant number of hosts that are running arbitrary applications. NAT-PT style translators can be just fine when used with a small number of specific hosts for which it is known that the applications on those hosts won't be harmed by the interposition of NAT-PT. though frankly, most users aren't capable of doing such analysis - just like most users don't understand the harm that NAT does. how many applications do you have that does not run across NATs? how many of them have hardcoded 32bit address field in the payload? in fact, as posted a couple of weeks ago i got an IPv6-only wireless network which works just fine for me. the only applications that does not go through it are: - Skype (MacOS X) - Software Update (MacOS X) - .Mac Sync (MacOS X) - NFS (any OS) caveat: i'm not a heavy user of multi-media apps nor BitTorrent. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
how many applications do you have that does not run across NATs? that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. at my last job, where we worked on distributed computing systems? several more than that. how many of them have hardcoded 32bit address field in the payload? hard to say. I tried to promote IPv6-awareness at my last job and to get developers to stop assuming that an address was 32 bits. but the bigger problem isn't the hard-coded address size - it's the conflict between the application writer's desire that the network provide complete connectivity (imagine having a network that actually provided best-effort packet delivery!), and the various things that exist to split the network up into realms with arbitrary constraints on how traffic can be routed between those realms. having multiple address realms of any kind - be they private address realms behind NATs, or IPv4/IPv6, or whatever - basically forces apps to implement their own routing, and sometimes, their own addressing. and requiring apps to have their own routing is tantamount to requiring them to have their own infrastructure that is rooted in the public Internet (probably on port 80) where all nodes can presumably reach them. it's much simpler to write a distributed app that is either entirely IPv4 or entirely IPv6 than to write one that supports both. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
how many applications do you have that does not run across NATs? that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. okay. if you could name them we can try to convince people who are responsible. at my last job, where we worked on distributed computing systems? several more than that. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P how many of them have hardcoded 32bit address field in the payload? hard to say. I tried to promote IPv6-awareness at my last job and to get developers to stop assuming that an address was 32 bits. but the bigger problem isn't the hard-coded address size - it's the conflict between the application writer's desire that the network provide complete connectivity (imagine having a network that actually provided best-effort packet delivery!), and the various things that exist to split the network up into realms with arbitrary constraints on how traffic can be routed between those realms. having multiple address realms of any kind - be they private address realms behind NATs, or IPv4/IPv6, or whatever - basically forces apps to implement their own routing, and sometimes, their own addressing. and requiring apps to have their own routing is tantamount to requiring them to have their own infrastructure that is rooted in the public Internet (probably on port 80) where all nodes can presumably reach them. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? code then spec. one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. i have been trying to persuade openssh coders to have functionality to re-connect ssh session even when TCP session go down. if you tunnel everything over ssh, you won. it's much simpler to write a distributed app that is either entirely IPv4 or entirely IPv6 than to write one that supports both. you have to. you cannot be that lazy. or .Net framework (Windows) or CFNetwork (MacOS X) can handle it for you inside the library. http://www.amazon.com/exec/obidos/ASIN/(A183180(B itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Perhaps one of the Cisco employees could explain whether the change in the IETF status will cause this product to go to end of life or end of sales? http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_natpt.htm If the answer is 'no' then this entire line of argument is bunk. The Internet is going to be built by real engineers solving real engineering problems with running code. From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Fri 13/07/2007 1:10 PM To: Stephen Sprunk Cc: ietf@ietf.org; Paul Hoffman Subject: Re: chicago IETF IPv6 connectivity Stephen Sprunk wrote: Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: [arguments about NAT-PT avoiding the need to dual-stack hosts deleted] Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. Adapting existing networks to IPv6 is somewhat painful, but most of the deployed hardware supports it. On the other hand, adapting existing security policies, traffic filters, network intrusion detection systems, explicit and interception proxies is much harder. In some cases the products or upgrades don't even exist for IPv6, and when they do, they're not mature. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. That's like saying that if you are a IPv4 software developer and your applications won't work at your customers' sites because they have NATs, all you have to do is get rid of your own NAT and your customers' problems will go away. It simply doesn't work that way. NATs create problems even for people who don't use them. Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. All of this applications for v6 aren't designed to cope with NAT stuff is bunk. Applications are designed to use both v4 and v6 because there's no market for v6-only apps. Apps have already paid the cost of dealing with NAT (if it affects them) and so will future apps until we can manage to drop v4 entirely. If NAT-PT allows us to drop v4 sooner, it's that much sooner app developers can stop paying that cost, and that's good for everyone. All of these gross generalizations about applications are bunk. The patterns of interaction between nodes of an application, and the effect that NATs have on them, vary widely from one application to another. Any generalization of the form applications do X is dubious on its face. There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake Keith Moore [EMAIL PROTECTED] Stephen Sprunk wrote: Thus spake Keith Moore [EMAIL PROTECTED] NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: [arguments about NAT-PT avoiding the need to dual-stack hosts deleted] Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. That depends on the definition you're using. Many hosts are v6-capable, though I'd still debate whether it's the majority. Very, very few of those hosts have working v6 connectivity because there's some device(s) or provider(s) between the host and the DFZ that are v4-only. Even with Vista supporting v6 by default, the vast majority of Vista machines are behind NAT boxes that only support v4. In the case of enterprise networks, the internal network is also v4 only, limited by one or more of hardware, software, and motivation. Many ISPs, particularly consumer ones, don't offer v6 service at all, though that's improving daily and one can work around it with 6to4. Dual-stacking a network, even a home network, is _not_ a non-problem. Adapting existing networks to IPv6 is somewhat painful, but most of the deployed hardware supports it. It's humans and software, not hardware, that is generally the problem getting v6 deployed. On the other hand, adapting existing security policies, traffic filters, network intrusion detection systems, explicit and interception proxies is much harder. In some cases the products or upgrades don't even exist for IPv6, and when they do, they're not mature. So put the NAT-PT device on the outside of those security boxes. Presto, instant access from your v4 network to every v6-only host out there and vice versa, without any compromise of security. There is a compromise of functionality, but it's no worse than what you've got for v4 connectivity because you're behind a NAT for that too... There's a lot of focus on NAT-PT for v6 sites to access remote v4-only sites; I'm focusing on the case of v4-only sites using NAT-PT to access remote v6-only sites. That is the case that's going to go critical in 2-4 years when exhaustion hits. After that, folks can deploy real v6 internally (or even flash cut) when they see that a significant fraction of their outbound traffic is v6 -- or when the slower vendors finally get around to fixing their products. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. That's like saying that if you are a IPv4 software developer and your applications won't work at your customers' sites because they have NATs, all you have to do is get rid of your own NAT and your customers' problems will go away. That's not the same thing at all. It simply doesn't work that way. NATs create problems even for people who don't use them. Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. I must have ESP (and not the IPsec kind), because I already responded to that point... There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. No, the second incentive remains. Fully deploying v6 is still a good idea because it removes the problems inherent to NAT-PT, which I've already acknowledged. However, the alternative is worse. If you're still stuck on v4 because your vendors and/or management won't allow you to deploy v6, and v6-only sites start appearing, you can't contact those folks _at all_. Connectivity to those sites via NAT is better than no connectivity at all. Do _you_ want to be the first v6-only site on the Internet, unable to talk to 99% of other hosts out there? And, as Phillip says, it's a moot point because vendors are shipping NAT-PT anyways. The IETF can deprecate whatever it wants, but the market will provide what is needed. The IETF hasn't been very successful at eliminating v4 NAT either... S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: how many applications do you have that does not run across NATs? that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. okay. if you could name them we can try to convince people who are responsible. the people responsible for polluting the network with NATs? it's too late to punish them, I fear :) at my last job, where we worked on distributed computing systems? several more than that. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P and the rest of us are very appreciative! of course, not all of the applications that people use are those that are shipped with *BSD. and while it's quite helpful if programming languages support IPv6, that doesn't mean that the programs written in those languages will automatically work with IPv6. how many of them have hardcoded 32bit address field in the payload? hard to say. I tried to promote IPv6-awareness at my last job and to get developers to stop assuming that an address was 32 bits. but the bigger problem isn't the hard-coded address size - it's the conflict between the application writer's desire that the network provide complete connectivity (imagine having a network that actually provided best-effort packet delivery!), and the various things that exist to split the network up into realms with arbitrary constraints on how traffic can be routed between those realms. having multiple address realms of any kind - be they private address realms behind NATs, or IPv4/IPv6, or whatever - basically forces apps to implement their own routing, and sometimes, their own addressing. and requiring apps to have their own routing is tantamount to requiring them to have their own infrastructure that is rooted in the public Internet (probably on port 80) where all nodes can presumably reach them. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? code then spec. no, it's not a theoretical debate. I worked with a number of distributed systems: PVM, some MPI implementations, and one of my own design that didn't become so popular. There are a lot of applications layered on top of one or the other of these. But unless you're into high-performance computing you probably aren't aware of them. one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd love to see further development and standardization of multipath TCP - that seems like a very promising avenue) i have been trying to persuade openssh coders to have functionality to re-connect ssh session even when TCP session go down. if you tunnel everything over ssh, you won. sigh. yes that would be valuable functionality, but somehow I don't think that the answer to every problem imposed by shortsighted hacks in the network is to push things down another layer. and this kind of solution only solves the problem for two-node applications. it's much simpler to write a distributed app that is either entirely IPv4 or entirely IPv6 than to write one that supports both. you have to. you cannot be that lazy. our goal in IETF should be to allow programmers to be that lazy. separation of function between the host and the network is a Good Thing. let the hosts exchange packets and the network route them. the goal is certainly not to keep increasing complexity of the network and to keep making programmers' jobs more difficult. or .Net framework (Windows) or CFNetwork (MacOS X) can handle it for you inside the library. only if you want your application to be crippled in other ways. (my, you have a simplistic view of the application world!) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Hallam-Baker, Phillip wrote: Perhaps one of the Cisco employees could explain whether the change in the IETF status will cause this product to go to end of life or end of sales? http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_natpt.htm If the answer is 'no' then this entire line of argument is bunk. The Internet is going to be built by real engineers solving real engineering problems with running code. either that, or it will be destroyed by people pretending to be engineers (but failing to use any semblance of engineering discipline), solving imagined and/or poorly understood problems, with code that runs amok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. That depends on the definition you're using. Many hosts are v6-capable, though I'd still debate whether it's the majority. Very, very few of those hosts have working v6 connectivity because there's some device(s) or provider(s) between the host and the DFZ that are v4-only. agreed, but you were talking about hosts. It's humans and software, not hardware, that is generally the problem getting v6 deployed. agreed about humans - mindshare is the hardest thing to overcome. the software/hardware question is a distinction without a significant difference. if the products (you think) you need to secure your network aren't shipping, it doesn't matter much whether what you need is new hardware or a software upgrade. often, that's just a matter of packaging. On the other hand, adapting existing security policies, traffic filters, network intrusion detection systems, explicit and interception proxies is much harder. In some cases the products or upgrades don't even exist for IPv6, and when they do, they're not mature. So put the NAT-PT device on the outside of those security boxes. and then you end up with a crippled network that will impair a lot of the functionality you would have gained by using IPv6, and one which pollutes DNS besides. There's a lot of focus on NAT-PT for v6 sites to access remote v4-only sites; I'm focusing on the case of v4-only sites using NAT-PT to access remote v6-only sites. that's certainly an important case, but there are better ways than NAT-PT for v6-only sites to provide services to v4-only users. There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. No, the second incentive remains. Fully deploying v6 is still a good idea because it removes the problems inherent to NAT-PT, which I've already acknowledged. yes, but everyone else's NAT-PT boxes still keep you from getting most of the benefit from your upgrade to full IPv6. And, as Phillip says, it's a moot point because vendors are shipping NAT-PT anyways. BS. that's equivalent to the argument that because everyone else is evil, we might as well be evil too. IETF is useless if it doesn't try to describe what will work well in the long term. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
that I personally use? I'm guessing about a half-dozen, though I don't use them all everyday. some other apps work across NAT but with degraded functionality. okay. if you could name them we can try to convince people who are responsible. the people responsible for polluting the network with NATs? it's too late to punish them, I fear :) no, the people who have implemented your applications that are written in IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual. i do not care about NAT (un)friendliness, i just need it to support IPv6. we kame are guilty for almost every application IPv6 support, including Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools on *BSD, BSD libc, whatever. honestly noone can beat us on this topic:-P and the rest of us are very appreciative! of course, not all of the applications that people use are those that are shipped with *BSD. and while it's quite helpful if programming languages support IPv6, that doesn't mean that the programs written in those languages will automatically work with IPv6. well, that depends on what kind of programming language you will be using. Python uses a model where you explicitly need to invoke bind(2) and getaddrinfo(3), so the programmer has to be knowledgeable enough to handle IPv4/v6 stuff. iirc Ruby TCPSocket class embeds all the details about getaddrinfo(3) loop within the class/instance method, so you do not have to care about which IP version is in use. so, which is your real-world protocol which has the above problem? or is it a theoretical debate? code then spec. no, it's not a theoretical debate. I worked with a number of distributed systems: PVM, some MPI implementations, and one of my own design that didn't become so popular. There are a lot of applications layered on top of one or the other of these. But unless you're into high-performance computing you probably aren't aware of them. may i talk with you/designer of PVM/MPI code so that they can implement them in IPv6-friendly manner? privately. one way is to have a session-layer protocol (finally!). or, you can switch from TCP to SCTP. for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd love to see further development and standardization of multipath TCP - that seems like a very promising avenue) there were tons of multipath TCP drafts, but there's no real authentication so all of them failed badly. so i see some future in ssh. i have been trying to persuade openssh coders to have functionality to re-connect ssh session even when TCP session go down. if you tunnel everything over ssh, you won. sigh. yes that would be valuable functionality, but somehow I don't think that the answer to every problem imposed by shortsighted hacks in the network is to push things down another layer. and this kind of solution only solves the problem for two-node applications. please tell me, your apps are totally multicast or broadcast? if not, we need to solve 2-nodes communication first, then you can solve communication among n (n could be very big) nodes. you have to. you cannot be that lazy. our goal in IETF should be to allow programmers to be that lazy. separation of function between the host and the network is a Good Thing. let the hosts exchange packets and the network route them. the goal is certainly not to keep increasing complexity of the network and to keep making programmers' jobs more difficult. then use vendor libraries that are URL-based. or .Net framework (Windows) or CFNetwork (MacOS X) can handle it for you inside the library. only if you want your application to be crippled in other ways. (my, you have a simplistic view of the application world!) ??? i do not get your point. you would like to be lazy, then use libraries that are based on URLs. otherwise, you have to use getaddrinfo(3). other than that, either your design is broken or you are lazy. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
- more and more ISP infrastructure practices OP25B for IPv4. OP25B = Outbound Port 25 Blocking. it disallows ISP customers to run SMTP server, or use SMTP server outside of the ISP network. maybe it is japanese-local acronym, google shows me japanese pages only. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On 6-jul-2007, at 20:53, Douglas Otis wrote: How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. Simple: look at prefixes rather than individual addresses. If 2002::2002 is a spammer, then you may want to assume that 2002::2003, 2002::2004 etc are also spammers. With IPv6, the CIDR distance between nodes under different administration should be considerably larger than with IPv4, where you'll often see systems belonging to different people on consecutive addresses. An IPv6 address may traverse any number of translation points as well. Huh? What are you talking about? This complex topology spells the end of SMTP in its current form. And that's a bad thing? It's the fundamental lack of, well, everything, in SMTP that allows all this spam that we're suffering from these days and makes it impossible to get rid of things like the base64 encoding overhead. Build a better mousetrap rather than complain that the mice don't like the cheese. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On Jul 7, 2007, at 11:19 AM, Iljitsch van Beijnum wrote: On 6-jul-2007, at 20:53, Douglas Otis wrote: How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. Simple: look at prefixes rather than individual addresses. If 2002::2002 is a spammer, then you may want to assume that 2002::2003, 2002::2004 etc are also spammers. With IPv6, the CIDR distance between nodes under different administration should be considerably larger than with IPv4, where you'll often see systems belonging to different people on consecutive addresses. Recommending CIDR blocking will not win accolades. This is one of the evils most want to avoid. The dynamics of IPv6 addressing is part of the problem. IPv6 might utilize a translation of some IPv4 address, perhaps of a session crossing through the IPv4 address space into IPv6 address space via gateways. These translations will likely be dynamically assigned. Just the ease of being able to obtain a new IPv6 address represents a problem although this is also touted as a feature. IPv6 address vetting is unlikely to effectively track bad actors, nor will reverse DNS be all that useful. An IPv6 address may traverse any number of translation points as well. Huh? What are you talking about? There will be many ways to bridge between the IPv4 and IPv6 address space. This complex topology spells the end of SMTP in its current form. And that's a bad thing? Probably not. However, the IETF might want to consider what is needed to transition into something more robust once IPv6 space is allowed to send email. Difficult to obtain non-volatile references are essential for tracking abuse history. The difficulty is with the difficult-to-obtain reference. PNRP depends upon groups. Groups work in a fashion similar to that of a mailing list. This suggests there could be intermediaries offering references. Evidence of abuse should be limited to the transmitting domain and not the individual. Dealing with abuse should be internal to the domain. Limiting accountability to the domain is a major sticking point within the current email infrastructure. Those transmitting messages into public servers wish to avoid accountability. However, accountability simply does not scale down at an individual to individual level. There must be some form of collective accountability established. One way this could be accomplished would be to create a message that is nothing more than a URI. This could be done in a manner similar to BURL. The URI could be constructed of a double hash of a time- stamp, source identifier, and content. Message storage and retrieval could even utilize object storage. The group would be the web URL where the sender stored the individuals' messages. Recipient access could depend upon either the obscurity of the double hash or handled by a scheme similar to OpenID. This approach should scale, and yet ensure references are obtained from those offering an HTTP message access service. This would allow combining both SMTP and HTTP into a unified URL reputation vetting system independent of any underlying IP address. It's the fundamental lack of, well, everything, in SMTP that allows all this spam that we're suffering from these days and makes it impossible to get rid of things like the base64 encoding overhead. The transition will likely need to be evolutionary and not revolutionary. MUAs could be modified to handle either form of messaging. At some point, those still using the old methods will be too few to matter. Build a better mousetrap rather than complain that the mice don't like the cheese. Agreed. But is this something the IETF will even consider? Are there too many vested in the old mousetrap? -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On 6-jul-2007, at 20:53, Douglas Otis wrote: How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. Simple: look at prefixes rather than individual addresses. If 2002::2002 is a spammer, then you may want to assume that 2002::2003, 2002::2004 etc are also spammers. With IPv6, the CIDR distance between nodes under different administration should be considerably larger than with IPv4, where you'll often see systems belonging to different people on consecutive addresses. You will still see consective addresses with IPv6. Until you put a *dedicated* router at the end of the DSL line or on the cable modem etc. there will still be lots of addresses handed out where the next address is managed by someone else. An IPv6 address may traverse any number of translation points as well. Huh? What are you talking about? This complex topology spells the end of SMTP in its current form. And that's a bad thing? It's the fundamental lack of, well, everything, in SMTP that allows all this spam that we're suffering from these days and makes it impossible to get rid of things like the base64 encoding overhead. Build a better mousetrap rather than complain that the mice don't like the cheese. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
Thus spake Mark Andrews [EMAIL PROTECTED] You will still see consective addresses with IPv6. Until you put a *dedicated* router at the end of the DSL line or on the cable modem etc. there will still be lots of addresses handed out where the next address is managed by someone else. That's not necessary, though it's the ideal scenario once v4 is dead in a decade or two and it's feasible for consumer-grade ISPs to reorganize their L2 networks. In the meantime, what I've been expecting to see is that ISPs would use a /64 for the shared access subnet and then the CPE devices (a stateful firewall) would use DHCP PD to get a /64 for each customer's site. This is entirely compatible with using PA v4 space on the access subnet and having the CPE NAT to RFC1918 space (typically 192.168.1/24). Thanks to RFC 3041, you may never see two connections using the same IPv6 address and have to block a /64 at minimum for blacklists to have any effect. Fortunately, that's entirely compatible with most deployment scenarios, as each customer will be on their own /64 (or shorter). S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On Thu, 5 Jul 2007, Keith Moore wrote: There are basically two types of applications/protocols: the simple client/server ones (that work through NAT without changes) and anything else that's more complex. In my opinion, it would be a huge win to allow the former to work through some kind of IPv6-IPv4 translation because then all the hosts that only use these types of applications don't need IPv4 anymore and life becomes simple for the people who need to manage these hosts. that's the kind of thinking that polluted the IPv4 network with NATs. the problem is that those simple applications share the same hosts and network that the other applications do. if you put devices in the network that only solve problems for the simple applications, then you get a network that can only run simple applications. ^^^ At least, without tunneling/overlays. And that's exactly the kind of network we now have and will continue to have for the forseeable future. Moreover, I would claim that NAT is not even the biggest problem. (I'm always perplexed by the semi-annual NAT wars on the IETF list because rarely are firewalls given comparable billing even though I suspect they cause far more problems for NOCs. Certainly both they and NAT boxes cause silent, mysterious failures that cause users to think the network is broken. Yet *lots* of people want their part of the network to be a gated community.) We recently sent a team to Africa to better understand the connectivity challenges our researchers over there were facing. Result? We will soon be deploying our first-ever central VPN service on port 80/443 --because those are the only ports you can count on. In other words, we're going to deploy a VPN service not to *increase* anyone's security, but to tunnel *around* other people's security measures. The Internet-of-the-future is shaping up to be a collection of home and enterprise networks linked by port 443. And I see no reason to believe that IPv6 is going to change that. -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On 6-jul-2007, at 0:54, Keith Moore wrote: the problem is that those simple applications share the same hosts and network that the other applications do. if you put devices in the network that only solve problems for the simple applications, then you get a network that can only run simple applications. ^^^ Hence the part in my previous message about dynamically obtaining real IPv4 connectivity tunneled over IPv6 when non-simple applications need to talk to the IPv4 world. I understand there is a moratorium on new IPv4-IPv6 transition techniques in effect. I'm not familiar with the precise reasons for that (I assume it's the huge number of such mechanisms that was being proposed) but now that we have a better picture of the obstacles that block the transition from happening, I think it's time to revisit this and come up with a comprehensive set of transition tools that together, address the full range of user needs rather than one here and one there. In my opinion, dual stack has largely served its purpose here and we should put that on the back burner and start thinking about going IPv6-only in parts of the network, because dual stack by definition means adding complexity while it doesn't provide any benefits at this time. While IPv6-only has its problems, it does make building a network simpler. See http://arstechnica.com/news.ars/post/20070704-the-declaration-of-ipv6- independence.html But I'll take that up on v6ops. And from an architectural perspective, address translation is clearly a dead end. One of the reasons we argue against NATs is not that there aren't other major problems, it's that people haven't managed to get the message on NATs yet. Well, an iceberg looks very differently depending on whether you look at it above water or below. The problem with NAT is like almost all persisting problems: the bad consequences aren't felt in the place where they're created. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
Hence the part in my previous message about dynamically obtaining real IPv4 connectivity tunneled over IPv6 when non-simple applications need to talk to the IPv4 world. yes, I like that approach. and fwiw, I don't think there should be a moratorium against IETF working on it. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On Jul 6, 2007, at 3:07 AM, Iljitsch van Beijnum wrote: And from an architectural perspective, address translation is clearly a dead end. One of the reasons we argue against NATs is not that there aren't other major problems, it's that people haven't managed to get the message on NATs yet. Well, an iceberg looks very differently depending on whether you look at it above water or below. The problem with NAT is like almost all persisting problems: the bad consequences aren't felt in the place where they're created. It should be abundantly clear, being Internet robust is not a requirement set by the marketplace. People want their multiplayer games and conferencing programs to just work! A transition to full IPv6 will be perilous, as it is _not_ possible to drop IPv4 support in most environments. Unfortunately, the NAT problem also represents a business opportunity. This is true whether or not the solutions are condoned by a standards body. In the case of IPv6, Teredo UDP IPv4 tunneling, Teredo servers, and PNRP (a name service to navigate Teredo topologies) represents an immediate solution. A solution that introduces _more_ translations. The ideals of end-to-end assume the end is Internet robust. With Teredo and PNRP, external services play a significant role. Will the end, in conjunction with extremely complex topology ever become Internet robust? How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. An IPv6 address may traverse any number of translation points as well. This complex topology spells the end of SMTP in its current form. Perhaps SMTP could depend upon SMTP Client names or change into a type of URI based notification process, where messages are held by an HTTP server. The URI of the HTTP server might then replace reliance upon SMTP Client IP address reputation. SMTP represents just one protocol heavily dependent upon IPv4. As IPv4 becomes constrained, IPv4 based access control improves. Fully adopting IPv6 introduces another problem, IPv6 address access controls. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis [EMAIL PROTECTED] wrote: ... How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. An IPv6 address may traverse any number of translation points as well. This complex topology spells the end of SMTP in its current form. Perhaps SMTP could depend upon SMTP Client names or change into a type of URI based notification process, where messages are held by an HTTP server. The URI of the HTTP server might then replace reliance upon SMTP Client IP address reputation. SMTP represents just one protocol heavily dependent upon IPv4. Doug, I think you are conflating two problems. There is running code (and extensive history) to demonstrate your conclusion is not correct; the other issue may indicate that some of the things that are now under development in the IETF are wrong-headed and that they need to be rethought --now or later. First, SMTP was designed to work in a multiple-network environment, with gateways and relays patching over differences far more significant than anything related to the different between IPv4 and IPv6. Sometimes it underwent smaller or larger transformations in those other network-transport environments (e.g., using much more batch-oriented envelope structures). But anyone old enough to have seen a message move from EARN to the Internet and possibly then back to BITNET or into FidoNet or UUCP-based mail has rather strong empirical evidence that a mere change of network protocols doesn't do much to SMTP. It is perhaps worth remembering that RFC 821 contains a good deal of text, some appendices, and miscellaneous dancing around the topic of SMTP over non-TCP services. On the other hand, any authentication, authorization, or validation technique that depends either specifically on IPv4 addresses or on some sort of end-to-end connection between the final delivery MTA (or MUA after it) and Submission MTA (or earlier) is going to be in a certain amount of trouble: from IPv6, from long relay chains, from long-delay networks, and so on. Obviously some of the proposed mechanisms in that class are much more sensitive to network variations (or, in the worst cases, any situation in which there is not a single connection between the MSA and the delivery server) and maybe the IETF should be looking harder at those characteristics before publishing or standardizing them. But the oldest sender-authentication and message integrity mechanisms of all don't depend on such endpoint connections over a single network technology: I, and I imagine many others, have had mailboxes on and off for 20-odd years that will not accept any traffic that does not arrive with a digital signature over the content that can be verified by software in the delivery (receiving) system and with requirements on the signed content, such as sequence numbers or time stamps, to prevent replay attacks. Such approaches either require a strong PKI or secure out-of-band transmission of secret keys, don't scale, or both, but those aren't SMTP problems. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
How will SMTP servers vet sources of inbound messages within an IPv6 environment? I don't know, but except for very limited corner cases, trying to use a source address to vet the source in an IPv4 environment is foolish and error-prone. It is no less foolish and error-prone in IPv6, but that's not the fault of IPv6. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
John C Klensin wrote: --On Friday, 06 July, 2007 11:53 -0700 Douglas Otis [EMAIL PROTECTED] wrote: This complex topology spells the end of SMTP in its current form. ... Doug, I think you are conflating two problems. There is running code (and extensive history) to demonstrate your conclusion is not correct; As you note, the world used to be rather more complicated and it worked fine. Besides the integrate service, using heterogeneous email standards, that you cite, folks might want to take at another historical reference: http://www.isi.edu/in-notes/rfc1775.txt. That the current world is pressing for end-to-end authentication is not a new requirement. The challenge is present whether we have v4/v6 or just one IP, to serve us all. But, then, email is multi-hop -- contrary to some people's model -- so that's why we try to design mechanisms that work... multi-hop. On the other hand, any authentication, authorization, or validation technique that depends either specifically on IPv4 addresses or on some sort of end-to-end connection between the This is only one of the examples of the fundamental weakness of any scheme based on Path Registration -- that is, authentication based on a topology tag, such as an IP Address. Path Registration works for single-hop scenarios, albeit even then with significant limitations. Specifically: tying topology information to messaging means that it cannot work for multi-hop scenarios. d/ ps. We can have some fun debating the meaning of multi-hop since travel through a sequence of IP routers is multi-hop, even though the TCP connection is direct. Similarly, an SMTP or SUBMISSION session that goes through a proxy might entail multiple TCP connections, but the mail-level view is that, again, the interaction is direct. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On Jul 6, 2007, at 1:52 PM, John C Klensin wrote: --On Friday, 06 July, 2007 11:53 -0700 Douglas Otis [EMAIL PROTECTED] wrote: ... How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a new IPv6 address. An IPv6 address may traverse any number of translation points as well. This complex topology spells the end of SMTP in its current form. Perhaps SMTP could depend upon SMTP Client names or change into a type of URI based notification process, where messages are held by an HTTP server. The URI of the HTTP server might then replace reliance upon SMTP Client IP address reputation. SMTP represents just one protocol heavily dependent upon IPv4. Doug, I think you are conflating two problems. There is running code (and extensive history) to demonstrate your conclusion is not correct; the other issue may indicate that some of the things that are now under development in the IETF are wrong-headed and that they need to be rethought --now or later. It is more a matter of remaining relevant. If not now, then later matters even less. First, SMTP was designed to work in a multiple-network environment, with gateways and relays patching over differences far more significant than anything related to the different between IPv4 and IPv6. Sometimes it underwent smaller or larger transformations in those other network-transport environments (e.g., using much more batch-oriented envelope structures). But anyone old enough to have seen a message move from EARN to the Internet and possibly then back to BITNET or into FidoNet or UUCP-based mail has rather strong empirical evidence that a mere change of network protocols doesn't do much to SMTP. It is perhaps worth remembering that RFC 821 contains a good deal of text, some appendices, and miscellaneous dancing around the topic of SMTP over non-TCP services. You are right about SMTP working across topologies. I setup UUCP for offices back when dedicated business lines were considered too expensive. I set up older messaging schemes for my customers while conducting a peripheral design business. This business demanded timely exchanges of schematics, wire-lists, PCB photo-plots, test- vectors, and firmware. When first learning of the Internet, it was costing more than $10 per one page fax to Japan. It sounded as if the Internet was some sneaky method to steal expensive telco services. Low cost Internet services together with today's level of abuse has lead to unintended DDoS attacks. Defending against this unintended attack depends upon IP address history. When this history proves ineffectively at refusing traffic from previously noted bad actors, SMTP no longer works. It has been an ongoing battle to ensure bad actors are unable to exploit easily obtained IP addresses. This includes addresses used by dial-up accounts, compromised residential systems, and even ISPs not enforcing adequate AUPs. Compromised residential systems makes discerning the last category difficult, and perhaps soon abandoned as yet another casualty of faltering security. On the other hand, any authentication, authorization, or validation technique that depends either specifically on IPv4 addresses or on some sort of end-to-end connection between the final delivery MTA (or MUA after it) and Submission MTA (or earlier) is going to be in a certain amount of trouble: from IPv6, from long relay chains, from long-delay networks, and so on. Obviously some of the proposed mechanisms in that class are much more sensitive to network variations (or, in the worst cases, any situation in which there is not a single connection between the MSA and the delivery server) and maybe the IETF should be looking harder at those characteristics before publishing or standardizing them. Depending upon DNS to migrate protocol behavior is one concern. Wildcard records in DNS can increase the amplifications of some intentional DDoS attacks. To support SMTP, some servers will issue a long series of scripted DNS transactions which might have been dictated by bad actors (as if the goal was to taint and/or kill DNS). At least PNRP does not depend upon DNS. What will the IETF offer as an alternative to this proprietary name resolution protocol? But the oldest sender-authentication and message integrity mechanisms of all don't depend on such endpoint connections over a single network technology: I, and I imagine many others, have had mailboxes on and off for 20-odd years that will not accept any traffic that does not arrive with a digital signature over the content that can be verified by software in the delivery (receiving) system and with requirements on the signed content, such as sequence numbers or time stamps, to prevent replay attacks. Such approaches either require a strong PKI or secure out-
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
How will SMTP servers vet sources of inbound messages within an IPv6 environment? I don't know, but except for very limited corner cases, trying to use a source address to vet the source in an IPv4 environment is foolish and error-prone. It is no less foolish and error-prone in IPv6, but that's not the fault of IPv6. from my experience - very few SMTPv4 servers look at PTR/A record matching. i'm not sure how i can configure sendmail/procmail to do this. - i never found any RBL-style blacklist for IPv6. - spammers DO use SMTPv6. by chance or by intention? not sure. - more and more ISP SMTPv4 servers do filter SMTPv4 from outside of its network, to prevent the abuse by spammers. - more and more ISP infrastructure practices OP25B for IPv4. i'm not too sure about the latter two in IPv6. maybe we should ask NTT and IIJ email ops division about this. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Jul 1, 2007, at 6:34 AM, Dave Crocker wrote: Jun-ichiro itojun Hagino wrote: maybe we can have the default IETF61 SSID be pro-IPv6, and SSID legacy be IPv4-only :-P Ahh, well. That moves the change from being coercive to being cool. No, that moves it to being pejorative. In any case, what is the need for separate SSID's? Do you truly intend to clutter the airspace further with another set of AP's? There are effectively only three channels and you really want to use all three already to provide overlapping non-interfering coverage... Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Le 07-07-01 à 20:24, Jun-ichiro itojun Hagino a écrit : you right. we have been running dual stack network since 1998 or something (Marc Blanchet should have the real answer), Chicago IETF 42nd. Aug 1998. Marc. - IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
On 2-jul-2007, at 22:38, Keith Moore wrote: NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. First of all, this is the worst kind of ivory tower thinking. uh, no. it's realistic thinking. Sorry, I have to disagree. Realistic thinking is when there is a messy solution, you create a non-messy solution first before killing the messy one. I've written distributed applications before and after NAT, and the amount of additional complexity and infrastructure required for such an application to function and scale in the presence of NAT is staggering. the presence of NATs in the v4 Internet has held back application development for around 10 years now. ...with no end in sight. How am I supposed to run IPv6 and access the IPv4 world without a mechanism like NAT-PT? There are solutions for corner cases that involve address translation. For instance, if you have a legacy IPv4-only device, say a printer, and you want IPv6-only hosts to be able to access it, you can put a device in the signal path that translates between IPv6 and IPv4 and vice versa. It will look a lot like a NAT-PT box. The difference is that it's not a general purpose solution. It only works for specific applications that don't attach any significance to addresses. But as soon as you start trying to front an entire network with such a box, you've killed the ability of that network to support certain kinds of applications. And if such devices get widely deployed in such a manner, then the IPv6 network becomes just as crippled as the IPv4 network has become. Well, that depends. I grant you that this is certainly something that _could_ happen. The risk here is that if we provide something relatively simple that works for a relatively limited set of applications/protocols, people will want to apply this mechanism to additional applications/protocols, and then the trouble starts. But is not having the mechanism in the first place the best solution to avoid this? There are basically two types of applications/protocols: the simple client/server ones (that work through NAT without changes) and anything else that's more complex. In my opinion, it would be a huge win to allow the former to work through some kind of IPv6-IPv4 translation because then all the hosts that only use these types of applications don't need IPv4 anymore and life becomes simple for the people who need to manage these hosts. The solution for hosts that need to do more complex stuff all the time is obvious: those need an IPv4 address. This leaves the case of hosts who need to run more complex stuff some of the time unaddressed. I think some sort of IPv4 address leasing tunneled over IPv6 would work here. This has a number of advantages: - the host has an actual IPv4 address, so no weirdness because the two ends see different IP versions (avoiding NAT for the IPv4 part is left as an exercise for the reader) - the IPv4 address is only used when needed so the number of addresses is much smaller than with traditional IPv4 provisioning (more like dial-up) - there is no need to subnet, the IPv4 addresses can be used individually (also like dial-up) The following draft should appear in due course (it's only 4 pages): http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect- method-00.txt I'll look for it. http://www.ietf.org/internet-drafts/draft-van-beijnum-v6ops-connect- method-00.txt Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
+1 -original message- Subject: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity From: Keith Moore [EMAIL PROTECTED] Date: 07/05/2007 11:59 AM There are basically two types of applications/protocols: the simple client/server ones (that work through NAT without changes) and anything else that's more complex. In my opinion, it would be a huge win to allow the former to work through some kind of IPv6-IPv4 translation because then all the hosts that only use these types of applications don't need IPv4 anymore and life becomes simple for the people who need to manage these hosts. that's the kind of thinking that polluted the IPv4 network with NATs. the problem is that those simple applications share the same hosts and network that the other applications do. if you put devices in the network that only solve problems for the simple applications, then you get a network that can only run simple applications. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
There are basically two types of applications/protocols: the simple client/server ones (that work through NAT without changes) and anything else that's more complex. In my opinion, it would be a huge win to allow the former to work through some kind of IPv6-IPv4 translation because then all the hosts that only use these types of applications don't need IPv4 anymore and life becomes simple for the people who need to manage these hosts. that's the kind of thinking that polluted the IPv4 network with NATs. the problem is that those simple applications share the same hosts and network that the other applications do. if you put devices in the network that only solve problems for the simple applications, then you get a network that can only run simple applications. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
the problem is that those simple applications share the same hosts and network that the other applications do. if you put devices in the network that only solve problems for the simple applications, then you get a network that can only run simple applications. ^^^ At least, without tunneling/overlays. And that's exactly the kind of network we now have and will continue to have for the forseeable future. Moreover, I would claim that NAT is not even the biggest problem. (I'm always perplexed by the semi-annual NAT wars on the IETF list because rarely are firewalls given comparable billing even though I suspect they cause far more problems for NOCs. Certainly both they and NAT boxes cause silent, mysterious failures that cause users to think the network is broken. Yet *lots* of people want their part of the network to be a gated community.) Indeed, NATs aren't the only problem we're facing. Interception proxies and using IP addresses as policy tokens are also huge problems. But it's hard to argue that networks shouldn't have some policy, it's just that we haven't given them better tools to enforce it. And from an architectural perspective, address translation is clearly a dead end. One of the reasons we argue against NATs is not that there aren't other major problems, it's that people haven't managed to get the message on NATs yet. If we can't make the case against NATs within IETF, how can we even begin to address the thornier cases? (of course, what happens is that the thornier cases are used to justify the continued existence of NATs - which is a bit like using the existence of evil to justify doing more evil) The Internet-of-the-future is shaping up to be a collection of home and enterprise networks linked by port 443. And I see no reason to believe that IPv6 is going to change that. I suppose we should stop trying to design better networks, then? Maybe if everyone who believes that would stop participating in IETF then the dozen or so of us remaining could get some useful work done. :) For what it's worth, there seems to be a long history in the Internet (and other public networks) of bootstrapping new services by tunneling and gateways, which are replaced by more efficient and easier-to-maintain setups once the new service has attracted sufficient demand. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Well you say that you can't do this and that without knowing what you are doing. A counterexample is the fact that the basic architecture of the most widely used security protocol we have in use today were set by people who did not know what they were doing. They had the good sense to later hire people who did but they had already made the critical choices at that point. Sure we beat them up for getting the security design wrong (he's talking about an integrity attack, Marc), but they did make a design choice that none of the rest of us who knew better would have done that has in hindsight turned out to be completely right. A similar set of issues surrounded the Web. The critical invention was 404 Not Found. Scruffy links were the wrong way to do it in 1992 but today we understand that only scruffy can work. Architecture is about abstraction. Knowing what you can forget is the really important part. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 11:16 PM To: Clint Chaplin Cc: ietf@ietf.org Subject: Re: chicago IETF IPv6 connectivity Clint Chaplin wrote: there is NOBODY working in IETF for whom familiarity with IP, including IPv6, is not essential. whether they realize this is a different question. but you cannot do competent work in IETF without a basic understanding of the TCP/IP protocol stack. adsl mib enum geopriv mediactrl speechsc emu kitten ltans openpgp pkix my point stands. participants in all of these groups need to understand basics of the TCP/IP protocol stack (including UDP). for instance, you can't write a decent MIB without understanding how SNMP works and to do that you need to understand the consequences of its design choices (including how it uses UDP). similarly, you can't do a competent job designing new DNS records or using existing ones without understanding the protocol limitations of DNS, which follow to a large degree from quirks in IP and UDP. You certainly can't do competent Internet security work without understanding how the information is going to be packetized, routed, and sent around the network, and reassembled - i.e. without understanding IP. I once had a working group where the participants insisted that they layer everything on top of HTTP because they didn't understand TCP and weren't willing to learn. They didn't even really understand HTTP or its limitations, for instance, in being pretty much a remote-procedure-call mechanism (which has certain inherent inefficiencies) or being poor at handling asychronous notifications (which they needed). All they knew was that HTTP had APIs that they could call. And they didn't know how to use those. And what they produced was a disaster. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
you and I obviously inhabit different planets. please don't tell me any more about the one you live on. Keith Hallam-Baker, Phillip wrote: Well you say that you can't do this and that without knowing what you are doing. A counterexample is the fact that the basic architecture of the most widely used security protocol we have in use today were set by people who did not know what they were doing. They had the good sense to later hire people who did but they had already made the critical choices at that point. Sure we beat them up for getting the security design wrong (he's talking about an integrity attack, Marc), but they did make a design choice that none of the rest of us who knew better would have done that has in hindsight turned out to be completely right. A similar set of issues surrounded the Web. The critical invention was 404 Not Found. Scruffy links were the wrong way to do it in 1992 but today we understand that only scruffy can work. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Did we forget the IETF motto about running code ? I do understand that there is a need to alleviate risks in the operational network, so a traditional operational IPv4 network has to be maintained until a vast majority of IETFers have assessed the proper operation of IPv6. But this doesn't prevent to operate a more advanced technology simultaneously. Someone has to start and experiment the shortcomings, if the IETF is not doing it no body is going to do it or nobody is going to be put any trust in a new technology. IETF has to pioneer this as it did so far (multicast, security, IPv6, and hopefully more will experimented at the IETF). Anyway, IPv6 is not experimental, it runs alright in operational networks. What I think the IETF should experiment now at a wider scale is the transition tools between IPv6 and IPv4. This would only be meaningful if results of the experiments are published, for instance in the IETF journal. Regards, Thierry. On Mon, 02 Jul 2007 16:18:11 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Jun-ichiro itojun Hagino wrote: The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. +1 RFC1883 is not new. Neither is X.400, TP0, or many other specs. But then, that's not the issue. The issue is operational risk. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Thierry ERNST, PhD INRIA Rocquencourt France Project-Team IMARA / JRU LARA http://www.lara.prd.fr +33 1 39 63 59 30 (office) -- The coming end of the IPv4 world: http://penrose.uk6x.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Dave Crocker writes: Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Arnt Gulbrandsen wrote: Dave Crocker writes: Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. So basically, you're complaining that you came to the IETF and received production quality Internet service? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Why can't the people who want to use IPv4 use that and the people who want to use IPv6 use that. If IP and appletalk can survive in the same network then IPv4 should be able to survive with IPv6. Sounds to me as if what is really being proposed here is to shut down the IPv4 connectivity. That will cause a serious loss of productivity for me. I am going to Chicago to work and not to participate in a LAN party or an interop. There are plenty of venues where that can take place. With 1200 attendees paying $600 plus travel to attend the meeting is costing well over a million dollars. I agree that we should do dog food. The fact that this experiment cannot take place is the data point. People have to accept the data point and think through the deployment strategy more thoroughly. Back when laptops first came out you have to buy one power brick for the US and a second one for Europe. The modern multi-voltage power supply only appeared when an Apple vice president got angry when he discovered he dd not have the right adaptor, returned to the engineering dept and told them that from now on the machine would work on any mains electricity anywhere in the world. -Original Message- From: Thierry Ernst [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 4:05 AM To: ietf@ietf.org Subject: Re: chicago IETF IPv6 connectivity Did we forget the IETF motto about running code ? I do understand that there is a need to alleviate risks in the operational network, so a traditional operational IPv4 network has to be maintained until a vast majority of IETFers have assessed the proper operation of IPv6. But this doesn't prevent to operate a more advanced technology simultaneously. Someone has to start and experiment the shortcomings, if the IETF is not doing it no body is going to do it or nobody is going to be put any trust in a new technology. IETF has to pioneer this as it did so far (multicast, security, IPv6, and hopefully more will experimented at the IETF). Anyway, IPv6 is not experimental, it runs alright in operational networks. What I think the IETF should experiment now at a wider scale is the transition tools between IPv6 and IPv4. This would only be meaningful if results of the experiments are published, for instance in the IETF journal. Regards, Thierry. On Mon, 02 Jul 2007 16:18:11 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Jun-ichiro itojun Hagino wrote: The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. +1 RFC1883 is not new. Neither is X.400, TP0, or many other specs. But then, that's not the issue. The issue is operational risk. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Thierry ERNST, PhD INRIA Rocquencourt France Project-Team IMARA / JRU LARA http://www.lara.prd.fr +33 1 39 63 59 30 (office) -- The coming end of the IPv4 world: http://penrose.uk6x.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Jul 3, 2007, at 8:34 AM, Joel Jaeggli wrote: Arnt Gulbrandsen wrote: IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. So basically, you're complaining that you came to the IETF and received production quality Internet service? Do IETF networks add missing IPv6 root glue? If so, would this be beyond production quality? -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Clint Chaplin wrote: I've been watching this debate for a while, and all the previous debates every time this subject comes up. IETF is no longer a single subject group. Very few participants are up to date with everything that IETF is working on, and many newer participants are participating in what I would characterize as edge areas: capwap, manet, and the like. I suspect (and I fall into this category) that many of these newer participants are not IP wizards; they're here to do work in other areas. Requiring them to participate in testing a new infrastructure that they are not familiar with would be counterproductive to getting their work done. there is NOBODY working in IETF for whom familiarity with IP, including IPv6, is not essential. whether they realize this is a different question. but you cannot do competent work in IETF without a basic understanding of the TCP/IP protocol stack. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
adsl mib enum geopriv mediactrl speechsc emu kitten ltans openpgp pkix Oh, and TCP isn't the only protocol in use. UDP, for instance, is the protocol used by Kerberos. On 7/3/07, Keith Moore [EMAIL PROTECTED] wrote: Clint Chaplin wrote: I've been watching this debate for a while, and all the previous debates every time this subject comes up. IETF is no longer a single subject group. Very few participants are up to date with everything that IETF is working on, and many newer participants are participating in what I would characterize as edge areas: capwap, manet, and the like. I suspect (and I fall into this category) that many of these newer participants are not IP wizards; they're here to do work in other areas. Requiring them to participate in testing a new infrastructure that they are not familiar with would be counterproductive to getting their work done. there is NOBODY working in IETF for whom familiarity with IP, including IPv6, is not essential. whether they realize this is a different question. but you cannot do competent work in IETF without a basic understanding of the TCP/IP protocol stack. Keith -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
So basically, you're complaining that you came to the IETF and received production quality Internet service? Do IETF networks add missing IPv6 root glue? If so, would this be beyond production quality? if I were to provide RFC3142 IPv6-to-IPv4 TCP relaying gateway, I will be using totd tricky recursive DNS server. if you put it in /etc/resolv.conf or something alike, you will get translated records whenever there's no real record present for a DNS name, and IPv6 TCP traffic will be re-connected into IPv4.. there still are some questions remain: - on *BSDs we do not have UDP relaying gateway, because TCP relaying gateway relies upon *BSD tcpcb structure. Yokogawa sells commercial device which does UDP relaying as well, so maybe yokogawa guys want to speak up. - if you run named or some DNS resolver which caches old results, your DNS cache may be filled with the translated results. it may or may not cause problems. the DNS TTL below shows that totd gives the same TTL as the original A records, it should be reduced to like 0 or 10 seconds when translation happens. with *BSD implementation there's no caching code in libc resolver. with Apple MacOS X there may be some cache but I have never experienced any issues. so there's no cache I suppose, or cache entries are associated with the information source DNS server. I have no idea about Microsoft OSes nor Linux. itojun | IPv6-over-IPv4 tunnel (MTU = 1280) garlic.itojun.org coconut.itojun.org |2 |1 ==+===+== wireless segment | 192.168.0.0/24, 2001:240:501:1::/64 wireless clients - DHCPv4 daemon will give wireless clients IPv4 address, DNS server IPv4 address (192.168.0.2), but NO IPv4 default gateway - IPv6 router advertisement will make wireless clients configure itself with IPv6 address(es) and IPv6 default gateway - totd runs on garlic.itojun.org (192.168.0.2) - totd returns translated responses to clients when asked about DNS names without record associated with it (such as a.root-servers.net). totd will not trick you if the DNS name has associated with it (www.kame.net). - TCP traffic to 2001:240:501:::/64 will get sucked by garlic.itojun.org - garlic.itojun.org will re-connect IPv6 TCP to IPv4 TCP itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. a ; DiG 9.3.4 @192.168.0.2 a.root-servers.net. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13668 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.root-servers.net.IN A ;; ANSWER SECTION: a.root-servers.net. 604225 IN A 198.41.0.4 ;; AUTHORITY SECTION: root-servers.net. 604217 IN NS a.root-servers.net. root-servers.net. 604217 IN NS f.root-servers.net. root-servers.net. 604217 IN NS j.root-servers.net. root-servers.net. 604217 IN NS k.root-servers.net. ;; Query time: 27 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Wed Jul 4 05:18:25 2007 ;; MSG SIZE rcvd: 180 itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. ; DiG 9.3.4 @192.168.0.2 a.root-servers.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 30068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.root-servers.net.IN ;; ANSWER SECTION: a.root-servers.net. 604798 IN 2001:240:501:::c629:4 ;; AUTHORITY SECTION: root-servers.net. 604790 IN NS a.root-servers.net. root-servers.net. 604790 IN NS f.root-servers.net. root-servers.net. 604790 IN NS j.root-servers.net. root-servers.net. 604790 IN NS k.root-servers.net. ;; Query time: 88 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Wed Jul 4 05:08:52 2007 ;; MSG SIZE rcvd: 192 itojun[garlic:~] dig @192.168.0.2 www.kame.net. a ; DiG 9.3.4 @192.168.0.2 www.kame.net. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 61674 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.kame.net. IN A ;; ANSWER SECTION: www.kame.net. 86400 IN A 203.178.141.194 ;; AUTHORITY SECTION: kame.net. 86400 IN NS ns1.itojun.org. kame.net. 86400 IN NS orange.kame.net. ;; ADDITIONAL SECTION: ns1.itojun.org. 3600IN A 221.249.121.227 ns1.itojun.org. 3600IN 2001:240:501::53:0 ;; Query time: 306 msec ;;
RE: chicago IETF IPv6 connectivity
I certainly do not need to work out how to persuade my Checkpoint client to talk to my corporate VPN via IPv6 in order to contribute to KEYPROV, DKIM or any of the other WGs I will be attending. The application is miserable enough at the best of times without additional issues. And since the policy configuration is verified by the gateway I cannot change the policy unilateraly. The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. The approach being suggested here is to tell the salespeople to eat it and like it. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 3:56 PM To: Clint Chaplin Cc: ietf@ietf.org Subject: Re: chicago IETF IPv6 connectivity Clint Chaplin wrote: I've been watching this debate for a while, and all the previous debates every time this subject comes up. IETF is no longer a single subject group. Very few participants are up to date with everything that IETF is working on, and many newer participants are participating in what I would characterize as edge areas: capwap, manet, and the like. I suspect (and I fall into this category) that many of these newer participants are not IP wizards; they're here to do work in other areas. Requiring them to participate in testing a new infrastructure that they are not familiar with would be counterproductive to getting their work done. there is NOBODY working in IETF for whom familiarity with IP, including IPv6, is not essential. whether they realize this is a different question. but you cannot do competent work in IETF without a basic understanding of the TCP/IP protocol stack. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Jul 3, 2007, at 3:44 PM, Hallam-Baker, Phillip wrote: The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. The approach being suggested here is to tell the salespeople to eat it and like it. For most startups, it is not the quality of the dog food that matters. It is the quality of the sales people. No one expects a first version of anything to not have bugs. : ) -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
I certainly do not need to work out how to persuade my Checkpoint client to talk to my corporate VPN via IPv6 in order to contribute to KEYPROV, DKIM or any of the other WGs I will be attending. point taken. but you do need to know basics of how IPv6 works to competently participate in any IETF working group. you might think that IPv6 is irrelevant, but it's not, because people are constantly making IPv4-specific assumptions in higher-level protocol designs without realizing it. The application is miserable enough at the best of times without additional issues. And since the policy configuration is verified by the gateway I cannot change the policy unilateraly. if you work for a company that forces you to use crappy software, I feel for you. but hey, we all have our burdens to bear. The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. The approach being suggested here is to tell the salespeople to eat it and like it. what do salespeople have to do with IETF? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Clint Chaplin wrote: there is NOBODY working in IETF for whom familiarity with IP, including IPv6, is not essential. whether they realize this is a different question. but you cannot do competent work in IETF without a basic understanding of the TCP/IP protocol stack. adsl mib enum geopriv mediactrl speechsc emu kitten ltans openpgp pkix my point stands. participants in all of these groups need to understand basics of the TCP/IP protocol stack (including UDP). for instance, you can't write a decent MIB without understanding how SNMP works and to do that you need to understand the consequences of its design choices (including how it uses UDP). similarly, you can't do a competent job designing new DNS records or using existing ones without understanding the protocol limitations of DNS, which follow to a large degree from quirks in IP and UDP. You certainly can't do competent Internet security work without understanding how the information is going to be packetized, routed, and sent around the network, and reassembled - i.e. without understanding IP. I once had a working group where the participants insisted that they layer everything on top of HTTP because they didn't understand TCP and weren't willing to learn. They didn't even really understand HTTP or its limitations, for instance, in being pretty much a remote-procedure-call mechanism (which has certain inherent inefficiencies) or being poor at handling asychronous notifications (which they needed). All they knew was that HTTP had APIs that they could call. And they didn't know how to use those. And what they produced was a disaster. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Hallam-Baker, Phillip wrote: The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. Indeed. The approach being suggested here is to tell the salespeople to eat it and like it. It's orthogonal, and irrelevant. Salespeople do not care how the dog food tastes. If it sells, they will eat it and pretend they like it. If the dogs don't like the food, there is no point having the salespeople eat it. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On 1-jul-2007, at 18:46, Keith Moore wrote: NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. First of all, this is the worst kind of ivory tower thinking. How am I supposed to run IPv6 and access the IPv4 world without a mechanism like NAT-PT? Killing that without providing an alternative was a very bad move that will come back to haunt the IETF. (And although the problems with NAT-PT are real, they're not THAT bad.) And you're wrong, too. With NAT-PT and a DNS ALG in effect, you have NAT-incumbered access to the IPv4 world, which is not good because IPv6 stuff isn't built to work with NAT. But at least you have access to the IPv4 world. But your access to the IPv6 world is completely trouble free, which is the point. The following draft should appear in due course (it's only 4 pages): http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect- method-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Saturday, June 30, 2007 10:56:59 PM -0400 Fred Baker [EMAIL PROTECTED] wrote: On Jun 30, 2007, at 9:49 PM, Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. ... and this point may be lost on some people, but most IETF participants do not operate their ISP's or corporate networks, and have no ability to change them. Most of us come to IETF meetings to get work done, not to spend the week fighting to get connectivity to home because someone wants to use the IETF network to encourage someone to deploy IPv6 or any other new technology. Every time I come to an IETF meeting, I lose a week or more of time on my regular job. What makes that acceptable is that I can get significant amounts of IETF work done in that week. Take that away, and IETf meeting attendance suddenly becomes counter-productive for individuals, and then for the organization as a whole. The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Iljitsch van Beijnum wrote: On 1-jul-2007, at 18:46, Keith Moore wrote: NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. First of all, this is the worst kind of ivory tower thinking. uh, no. it's realistic thinking. I've written distributed applications before and after NAT, and the amount of additional complexity and infrastructure required for such an application to function and scale in the presence of NAT is staggering. the presence of NATs in the v4 Internet has held back application development for around 10 years now. How am I supposed to run IPv6 and access the IPv4 world without a mechanism like NAT-PT? There are solutions for corner cases that involve address translation. For instance, if you have a legacy IPv4-only device, say a printer, and you want IPv6-only hosts to be able to access it, you can put a device in the signal path that translates between IPv6 and IPv4 and vice versa. It will look a lot like a NAT-PT box. The difference is that it's not a general purpose solution. It only works for specific applications that don't attach any significance to addresses. But as soon as you start trying to front an entire network with such a box, you've killed the ability of that network to support certain kinds of applications. And if such devices get widely deployed in such a manner, then the IPv6 network becomes just as crippled as the IPv4 network has become. Similarly if you are on an IPv6-only network and you want to make some services accessible to IPv4, you can set up a tunnel between a specific application and a point of presence on the IPv4 network. Something like NAT-PT works in some cases, in other cases an application-specific proxy or a SOCKS-like protocol work better. But even if the NAT-PT like approach is used it's not a general solution, it's something that is set up for a particular application on a particular host and port based on knowledge of the specific needs of that application. Killing that without providing an alternative was a very bad move that will come back to haunt the IETF. (And although the problems with NAT-PT are real, they're not THAT bad.) Disagree. All of the documentation that IETF has done on the problems with NAT only scratches the surface. And NAT-PT is worse than NAT, because it promotes use of two-faced DNS which has its own set of evils that are approximately as bad as those for NAT. And you're wrong, too. With NAT-PT and a DNS ALG in effect, you have NAT-incumbered access to the IPv4 world, which is not good because IPv6 stuff isn't built to work with NAT. But at least you have access to the IPv4 world. But your access to the IPv6 world is completely trouble free, which is the point. no it's not, because that assumes that a host or an application is either purely IPv4 or IPv6, and it assumes that DNS results from IPv4 queries don't get exposed to IPv6-aware apps. neither of those is true. The following draft should appear in due course (it's only 4 pages): http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect-method-00.txt I'll look for it. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. +1 RFC1883 is not new. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: The IETF network is not, and never has been, for experimentation, showing off new technology, or making political statements. Please keep it that way. +1 RFC1883 is not new. Neither is X.400, TP0, or many other specs. But then, that's not the issue. The issue is operational risk. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? maybe we can have the default IETF61 SSID be pro-IPv6, and SSID legacy be IPv4-only :-P itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jun-ichiro itojun Hagino wrote: maybe we can have the default IETF61 SSID be pro-IPv6, and SSID legacy be IPv4-only :-P Ahh, well. That moves the change from being coercive to being cool. Good marketing approach. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
At 2:36 PM +0900 7/1/07, Jun-ichiro itojun Hagino wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 tranlators like NAT-PT or RFC3142. NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is Informational. Without a standards-track method for people to use IPv4, changing a production network to IPv6 seems unwise. their scalability is no worse than IPv4-to-IPv4 NAT. That may be true, but it is also irrelevant, given that the current production network doesn't use IPv4 NAT at all. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 tranlators like NAT-PT or RFC3142. NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is Informational. Without a standards-track method for people to use IPv4, changing a production network to IPv6 seems unwise. RFC status does not have direct connection with being implemented or being deployed (see all the W3C standards which did not originate in IETF). at N+I tokyo we have been using RFC2766/3142 for IPv6-only net cafe since around year 2000 or something. in June 2007 N+I network team used Windows Vista official releases as the clients. their scalability is no worse than IPv4-to-IPv4 NAT. That may be true, but it is also irrelevant, given that the current production network doesn't use IPv4 NAT at all. you are in ARIN region so you are enjoying vast amount of IPv4 address space... come to APNIC region or LACNIC region to experience the pain. i pay $300/mo for PA /29, and it is a real bargain. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Paul Hoffman wrote: At 2:36 PM +0900 7/1/07, Jun-ichiro itojun Hagino wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 tranlators like NAT-PT or RFC3142. NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is Informational. Without a standards-track method for people to use IPv4, changing a production network to IPv6 seems unwise. The thing to do before thinking of removing IPv4 connectivity is too look at which applications are actually using IPv4. NetFlow/sniffing etc can be used to determine these organization wide. Most likely you will come down to at least: - HTTP - for which one can use a HTTP Proxy which does v4+v6 - SMTP - for which one can use SMTP :) (does both v4+v6) - IMAP/POP - let the app handle it In the end though one needs to have a machine somewhere which does both IPv4 and IPv6 and translates between them. But on the Application Protocol level, not by changing bits like NAT-PT does. I am not sure, but is there not a draft/rfc/paper which details something like Common application migration path from IPv4 to IPv6? It is now I guess all cluttered all over the place. Maybe a Wikipedia article would be more appropriate, outlining which protocols can be resolved in way X and/or Y. This also allows everything to be in a central place which pointers to the programs that can do this too. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is Informational. Without a standards-track method for people to use IPv4, changing a production network to IPv6 seems unwise. RFC status does not have direct connection with being implemented or being deployed (see all the W3C standards which did not originate in IETF). at N+I tokyo we have been using RFC2766/3142 for IPv6-only net cafe since around year 2000 or something. in June 2007 N+I network team used Windows Vista official releases as the clients. NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
I suggest starting by having a separate SSID for IPv6 only and encouraging people to test it out. Advertise it in the notes, on the mailing list, and elsewhere. Ask people in the post-meeting survey whether they have tried it, and whether it worked with their computer. After there is a high success rate, then start migrating the main wireless network to IPv6 only, but leave a legacy SSID for IPv4. This will encourage people to transition, and will shift the focus to IPv6, while still allowing people with old computers and operating systems to connect. - Philip ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
maybe we can have the default IETF61 SSID be pro-IPv6, and SSID legacy be IPv4-only :-P Ahh, well. That moves the change from being coercive to being cool. No, that moves it to being pejorative. In any case, what is the need for separate SSID's? Do you truly intend to clutter the airspace further with another set of AP's? There are effectively only three channels and you really want to use all three already to provide overlapping non-interfering coverage... you right. we have been running dual stack network since 1998 or something (Marc Blanchet should have the real answer), and we even supplied IPv6-to-IPv4 translators, so there should be no problem at all. I can bring in IPv6-to-IPv4 translator if necessary. it would be an OpenBSD Soekris box. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Jim, Have no fear, the Chicago network will have IPv6 connectivity (as we always have). It's likely to be natively routed out through I2, though the kind offer of a tunnel will be held in reserve, should we have a problem with that. :-) Good to hear! Many kudos to the folks putting together the IETF network. Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
From: Bob Hinden [EMAIL PROTECTED] Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings Guess that's the only way you can get people to convert to IPv6, huh - cut off their IPv4 access? Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? No? -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
From: Bob Hinden [EMAIL PROTECTED] Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings Guess that's the only way you can get people to convert to IPv6, huh - cut off their IPv4 access? well, if you are using either of the following, you are IPv6 ready. - MacOS X after 10.2 (or 10.3? I do not remember but you should really be using 10.4.10) - *BSD releases after year 1999 - Linux after year 2000 or somewhere around (depending on your distribution) - Nokia Symbian phones (Bob will tell you more about it) - Windows Vista - Windows XP SP2 with ipv6 install command if you still are using Windows Me/98/95, you should really upgrade, since there's no security patch releases from Microsoft any longer IIRC. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Jun 30, 2007, at 9:49 PM, Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: chicago IETF IPv6 connectivity
Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings Noel Chiappa wrote: Guess that's the only way you can get people to convert to IPv6, huh - cut off their IPv4 access? :-D Might happen for IETF meetings; in the real world out of the ivory tower, might take more time. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? No? No, because that presumes that IPv6 will be used for production only when it mostly replaces IPv4. It's more realistic to assume that the first production uses of IPv6 are those for which IPv4 is not satisfactory for one reason or another - e.g. lack of available addresses, inability to use the desired applications in the presence of NAT, etc. OTOH, the IETF meeting net has never been entirely for production services - there's also been something of a history of using it to eat our own dogfood and learning how to make it tasty enough that we like it. Remote video and audio access via multicast, wireless LANs, etc. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings good luck. Until the ISPs and our corporate networks deploy it, we can't go there. to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4 tranlators like NAT-PT or RFC3142. their scalability is no worse than IPv4-to-IPv4 NAT. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Have no fear, the Chicago network will have IPv6 connectivity (as we always have). It's likely to be natively routed out through I2, though the kind offer of a tunnel will be held in reserve, should we have a problem with that. :-) - Jim On Jun 13, 2007, at 1:58 PM, Jeroen Massar wrote: [bcc'd someone from Verilan who can most likely comment on this :) ] Jun-ichiro itojun Hagino wrote: i'm wondering about IPv6 connectivity at chicago IETF69. if any of you have hints about it, please drop me a note. if there's no plan for IPv6, i'd be more than happy to help out, as always. It seems that VeriLAN (http://www.verilan.com) is taking on the NOC role again, they did, from what I understood, a great job in Prague*. A search using their own search toy for IPv6 didn't result in any hits though and google doesn't seem to know about it either. In the possible case that no IPv6 (native) connectivity can be arranged, there is a SixXS PoP in Chicago, courtesy of OCCAID, this box is up and running and can easily provide a fast stable tunnel + /48 to the site if needed. Just yell in case help there is needed. Greets, Jeroen * = http://tools.ietf.org/group/iaoc/wiki/VeriLAN ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
[bcc'd someone from Verilan who can most likely comment on this :) ] Jun-ichiro itojun Hagino wrote: i'm wondering about IPv6 connectivity at chicago IETF69. if any of you have hints about it, please drop me a note. if there's no plan for IPv6, i'd be more than happy to help out, as always. It seems that VeriLAN (http://www.verilan.com) is taking on the NOC role again, they did, from what I understood, a great job in Prague*. A search using their own search toy for IPv6 didn't result in any hits though and google doesn't seem to know about it either. In the possible case that no IPv6 (native) connectivity can be arranged, there is a SixXS PoP in Chicago, courtesy of OCCAID, this box is up and running and can easily provide a fast stable tunnel + /48 to the site if needed. Just yell in case help there is needed. Greets, Jeroen * = http://tools.ietf.org/group/iaoc/wiki/VeriLAN signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
