Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-30 03:06 , Mark Andrews wrote: In message 4e3127f1.2030...@unfix.org, Jeroen Massar writes: On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses I was more thinking about commonality with tunnel brokers. These all are implemented by tunnelbrokers, be they tunnel brokers where you can just fill in the details yourself (6to4) or the others where the parameters are provided by the entity you want to connect to. 6rd is not a replacement for 6to4 as it requires ISP involment or someone to create a registry of 3rd party 6rd providers along with associated parameters sets similar non anycast 6to4. 6rd is then also intended for a per ISP deployment. static proto-41 tunnel is also not a viable replacement as it doesn't handle address reassignment at the CPE end. See the proto-41 + heartbeat option, that is standard proto-41 but with a side-channel which beats where the endpoint currently is. But why are you trying to replace 6to4? What are the requirements that you have that are not satisfied by any of the above methods? Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-27 18:03 , Mark Andrews wrote: [..] b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses For which there is only experimental / ad-hoc code. You call my code Experimental/ad-hoc? :) Like a good whiskey it matured over the years and hopefully soon I will be releasing the next edition of AICCU which solves, at least in that implementation, a couple of quirks that we have encountered in the recent years. Please name CPE vendors that support tsp? Please name CPE vendors that support tunnel re-configuration on re-number. I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA in some cases there are a variety of vendors, amongst which AVM Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget ;) I unfortunately do not have an exact list of devices/models as I had nothing to do with them, we just get users saying that they have a device which supports it ;) The fun part though with CPEs is that they tend to sit on the public IP address, which is also the reason why the Fritz!Box only does TIC/heartbeat. And of course every self respecting distribtion has support for it too by just adding AICCU, that includes the various WRTs, pfSense, m0nowall, Astaro and many many others. As you said, everybody can decide themselves what options they add ;) Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-27 20:21 , Keith Moore wrote: On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? tunnel brokers suck if the tunnel endpoint isn't near your current network location. Let me rewrite that sentence for you: transition mechanisms suck if the tunnel endpoint isn't near your current network location It does not matter much if that mechanism is static proto-41 (6in4), 6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a bit more latency if they are not directly next to you. Not much you can do about except deploy more of them or And this will always be the case unless you deploy enough of them in all places possible. For SixXS we are at 48 boxes around the world, Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and then there are 4 others at other organizations and there are a couple of other services out there which provide tunnels see: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions. For your set of requirements maybe but especially Tunnel Brokers are working very well for a lot of people and if one sees the traffic stats on Teredo and 6to4 nodes due to this little thing called NNTP I would state that those are doing quite fine too for giving access to what people need to get to. Your major requirement seems to involve latency though, thus as such, there is only one thing to do, get one of those boxes deployed locally to your endpoint. Do note to yourself that the next issue you will run into that the service you are actually contacting will be far away, and you suddenly understand that you need that Akamai content box and a Google one and various other closeby too ;) If you want to solve your problem though, I guess for HE you'll have to give them connectivity to their network and space in a rack for a box, gogo6 will sell you a box and for SixXS you provide the box+connectivity and we'll set up the software for free for you and handle the tunneling completely. Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses TSP conveys configurartion information inline with the UDP packets. TIC is solely for configuration information and does not do tunneling but can be used for all proto-41/heartbeat/AYIYA protocols (and for instance AVM chose to only do proto-41 + heartbeat as their devices always have public IPv4 IPs). Teredo is only for a single host thus is not useful for CPEs and thus not included in them. One of the advantages of 6to4 anycast is that it is just needs a check box to turn on and off. Everybody speaks the same thing. Except that it does not work behind a NAT and most people do sit behind a NAT. Next to that those anycasts are even rarer around the world and on top of that it is hard to figure out issues when they are there (although some people have tricks to apparently debug them, the anycast on both IPv4 and IPv6 requires one to contact a lot of folks). The big advantage over a known tunnel endpoint is the known behavior of that endpoint and the simple way of complaining when something is broken. And people fortunately do complain when stuff is broken, unfortunately not always with the proper details though, but I am to blame for not finishing that program up... Another advantage of 6to4 is it doesn't require manual intervention on renumber events. Manual tunnel don't pass muster. I guess you are one of the lucky people to get a public static IPv4 address prefix at home that never renumbers? Guess what, most of the world does not have that luxury, they get 1 dynamic address and for instance in Germany they get a disconnect/force-renumber every 24 hours (according to the ISPs because of 'accounting' reasons...) Do realize that when you have that public IPv4 address, when it changes you are renumbering your 2002:ipv4::/48 prefix everywhere. Fun... (I hope you also like asking 6to4.nro.net everytime to change your reverse) The tunnels above all have ISP-supplied prefixes and tend to be static (I think TSP anonymous tunnels rotate addresses, but the majority just keeps on returning the same static allocation, in the case of SixXS you really get a fixed address, much easier on the PoP side and we can do whois and store it in the relevant RIR registry) Another advantage of 6to4 is you don't have to register. For most of the tunnel brokers you have to register. I guess you also where able to anonymously sign up to your IPv4 ISP!? :) Especially that static IPv4 address must be wonderful to get that way. Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. Something with the amounts of abuse made us (SixXS) require that we require valid address data. Next to that it is a RIPE requirement to register /48 prefixes. Other Tunnelbrokers just started blocking things like IRC and NNTP because there was too much abuse or traffic We kill off accounts of people when they abuse, google my name and you will find various people who where caught in the act and are quite mad that they can't have funny vhosts on IRC anymore and attract 500mbit DoSses and other such nonsense which are not the goal of providing IPv6. Also, the registration means that people can just type in their username/password (and optionally which tunnel they want to use out of the multiple tunnels they might have) in their CPE and the CPE then uses TIC or TSP to fetch this configuration and set it all up, and it will just work(tm). As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg and http://www.sixxs.net/wiki/Fritz!Box_7270 Next to that knowing where the user is and more importantly their endpoint allows one to select a proper PoP for that user close to their endpoint causing low latency and generally high throughput. With anycast you are just hoping that that all will work. Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
Arnt Gulbrandsen wrote: Iljitsch van Beijnum writes: You do have to understand that IPv6 support was available in BitTorrent clients for a long time, but then the Pirate Bay deployed trackers (servers) that were incompatible with the existing clients, so only people who both have IPv6 and a recent IPv6-capable client are in those numbers. I had to null-route the PB IPv6 address to get my old client to work again over IPv4... So considerably more than 1% of random filesharing users have IPv6 already? I assume that also means 1% of random DSL connections have IPv6 already. No, it is not Native IPv6 over DSL or any other form unfortunately. ou have to start thanking Microsoft for pushing 6to4 and especially Teredo, having it automatically on new platforms and having clients like uTorrent auto-enable it on install for those that don't. For instance read a bit here: http://mailman.nanog.org/pipermail/nanog/2008-August/003051.html Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78 Annoucement
Ole Jacobsen wrote: [..] Train time is around 3 and 1/2 hours with 3 changes, but I'd actually recommend going all the way to Utrecht on the German ICE which gives If you are going to hop over Utrecht, better just take a direct flight to Amsterdam (AMS) :) For The Netherlands, one can plan train rides using: http://www.ns.nl Top right corner has a link to the English edition. Amsterdam-Maastricht will take at least 3 hours though... :( Greets, Jeroen (and Zurich-Maastricht by train is also 8 hours, or by plain 3 train + 3 plane would make 6, oh well, bit silly though for that short distance, lets see how Hiroshima works out at least I get to see something new then ;) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org
Cullen Jennings wrote: [..] Sam, not disagreeing with anything you are saying here but none of this helps me understand why Dean should be blocked. [Note, I'm not saying this blocking is right or wrong, just that I don't understand why]. Should someone who is subject of a PR action just be automatically blocked from all IETF lists? With all the nonsense caused by this person with his 'dishonest' lists, I would say YES. I am very delighted that Henrik took those actions and fully support that decision in light of the PR action and all the abusive nonsense that the individual is causing. Greets, Jeroen (who fortunately is able to configure all his MX's to nicely reject mail from that individual and all his silly mailinglists, to avoid having to read the nonsense, and worse, get mail doubly which completely messes up message sorting and thus causes a lot of work, and there is enough of that already) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Problems accessing www.ietf.org over IPv6
Robert Moskowitz wrote: I have a /48 native IPv6 prefix routed to my home lab. I come back from IETF, and Firefox 3.0.6 is hanging accessing www.ietf.org on my duo-stack Centos 5.2 laptop. That is called a Path MTU issue. As you have a Linux box, install the tracepath6 tool (iputils-tracepath on Debian, probably similar package for an RPM distro) and then do a tracepath6 www.ietf.org and you will see where it goes wrong, then contact your provider and pass them that info. It is kinda funny to see big old ATT hanging behind OCCAID; I hope the secretariat is not paying ATT too much for that kind of 'transit'. (seems that Sprint and Telia also have the route but don't play transit for ATT thus the only transit for ATT is OCCAID...) Lets hope that improves soon... Greets, Jeroen -- jer...@purgatory:~$ tracepath6 www.ietf.org 1 : [LOCALHOST] pmtu 1500 2: gehenna.ch.unfix.org 1.581ms pmtu 1480 3: xen-gw.zrh.sixxs.net 26.816ms 4: ipman.zrh.sixxs.net 29.298ms 5: ge0-3.br01.zrh254.ipv6.ip-man.net 29.472ms 6: pos3-0.cr01.gva02.ipv6.ip-man.net 33.045ms 7: srp1-0.cr01.gva16.ipv6.ip-man.net 33.928ms 8: pos2-0.br01.ams254.ipv6.ip-man.net51.227ms 9: amsix.r1.ams2.nl.opencarrier.eu 53.085ms 10: opencarrier-ams-px.occaid.net 71.227ms 11: bbr01-p1-0.nwrk01.occaid.net 143.202ms asymm 12 12: r1.mdtnj.ipv6.att.net194.826ms 13: 2001:1890:61:9017::2 270.532ms 14: mail.ietf.org263.312ms reached Resume: pmtu 1480 hops 14 back 51 signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
Joe Abley wrote: On 23-Mar-2009, at 14:35, Melinda Shore wrote: I was auto-subscribed to Dean's ietf-honest mailing list, and I'm unhappy about it. As I think was mentioned a day or two ago on this list, the reasonable way I found to avoid these auto-subscriptions to ietf-honest was to block packets from the originating network. I had a very enjoyable few days following the installation of those packet filters. However, it now seems that (a) any address I've used in the past is now fair game, and not just the addresses I'm using today, and (b) it's not just the ietf list, but working group lists too, e.g. see below. I don't have the same ability to do server-side filtering or packet blocking on other mail accounts. Seems he wants the core of the Internet to apply those filters... I must say that I love the wording: This list was created by IADL.ORG (www.iadl.org) because of dishonest filtering by the IESG. See http://www.av8.net/IETF-watch for more information on the corrupt activities of officials of the Internet Society, Inc (ISOC) IETF Activity, and their connection to other corrupt activities. Those are clear allegations of corruption. Isn't that what the IETF calls an ad-hominum attack? Wasn't there something about that about causing subscriptions to be able to be blocked etc? You were probably added to this list because you participated in dn...@ietf.org discussion, and that list is used to determine consensus for ISOC IETF Activity actions. Consensus is a democratic activity of the ISOC, which is a U.S. non-profit, tax exempt membership corporation. ALL members of the ISOC IETF have a property right to participate in its democratic decision processes. [see U.S. v. Local 560, extortion (Hobbs Act) and racketeering by mafia that took over a Union and tried to prevent participation by those opposing the mafia] Nice one, the IETF is compared to the Mafia. [..] IETF representatives (e.g. Working Group Chairs) have a duty to the corporation to read email sent to them on IETF business, and should not try to unsubscribe. And here it goes: as a WG chair you are not able to unsubscribe, you are not even allowed to try. Nice Mafia-alike practice. I didn't know that the IETF was incorporated btw. All news to me ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hey my local ISP has IPv6 connection!
Marshall Eubanks wrote: Can you share their name ? Should we start a site listing IPv6 providers ? Something like: http://www.sixxs.net/faq/connectivity/?faq=native Which lists quite a number of them already, there is also a link to the Japanese service providers of which there are quite a few more. On Oct 29, 2008, at 10:18 AM, Hallam-Baker, Phillip wrote: Did a ping this morning from my residential broadband, was surprised to see responses from an IPv6 address. 6to4/Teredo etc make connectivity possible semi-automatically in a lot of places, thus without seeing source addresses and a traceroute it doesn't say that you are native at all; and when it is not native, then most very likely your local ISP doesn't have much to do with it. But as can be seen in the above URL, there are ISPs which are already awake. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Be aware when traveling to the USA.
Truman Boyes wrote: Hi there, According to the US Customs and Border Protection Policy document it appears that search and seizure at border/immigration centers does not apply directly to sealed letter class mail; and documents inside sealed letter class mail may not be read by officers without a appropriate search warrant. For folks concerned about this, do at least read: http://www.cbp.gov/linkhandler/cgov/travel/admissability/search_authority.ctt/search_authority.pdf as it might clarify some things which might be misunderstood otherwise. That document also mentions: Notwithstanding this law enforcement mission, in the course of every border search, CBP will protect the rights of individuals against unreasonable search and seizure. Unfortunately they don't specify what they call unreasonable, as IMHO this whole 'mission' of them described in that PDF is unreasonable. How about mailing yourself a USB drive with encrypted data and taking that along for the trip. Or what about, trying to use this great invention called... The Internet Which kind makes it completely useless for them to be doing this in the first place (IMnsHO) because the people who want to bring data from A to B will just send it that way and nicely over all kinds of secure channels. Then again, a plane full of tapes is faster than most internet connections of course. I am still wondering what the real reasoning is behind this lame security theater setup. It is just another annoying step from wanting me to go there. For me the procedure seems simple and applies actually to any case where you might expect your data/hardware to be stolen (it is the same thing in my opinion if they take it with law behind them, or a thief just steals something from me): - Don't bring along anything you don't want others to get - For the hardware you bring along before entering _and_ leaving the country: - use shred(*1) on the full disk and other media you have - re-install a full copy of $distro, so that you have the tools - just have one account: username=root, password=root Then after arrival, download and use your data, before leaving (might take 8 hours++ for the shred) upload your data to your internet host, shred+re-install in the same way. Now if they want your laptop or other hardware/storage, you can just give it up, yes, you loose them for some time, but there is nothing you have really lost. Yes, it is, like every other Security Theater, very annoying, but at least you avoid the problem where you loose something you didn't want to loose, and you can also just tell the guys there this is my re-install cd, you can have it, you'll figure out that there is nothing on this thing that can be illegal or violating anything Don't forget that your PSP or DS, that you are using in-flight, might also contain precious save-games especially after 8 hours of gaming in-flight), so don't forget to figure out a way to back-up those after landing ;) Of course, one can always make use of Tor (http://www.torproject.org/) to send your data around so that you'll remain quite anonymous too. For these kind of nasty rules, we'll just have to bend over and keep on smiling (but not too much, because they won't like that either...) Greets, Jeroen *1 = http://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Kurt Erik Lindqvist wrote: On 8 jul 2008, at 20.41, Keith Moore wrote: [..] I disagree that it doesn't work for servers. (Or it would be better to say that I'd like to know why you think it doesn't work for servers.) People have personal opinions, one likes this, the other likes that, maybe it works for you, maybe it works different for me. Well, when I change that broken NIC in my server, it will receive a new address that needs to be reflected in the DNS. Which is why EUI-64 is a great method on combination with RA to do autoconfiguration, but if somebody (for whatever reason they have) want to use those 64bits differently (eg using DHCP or static config) they should definitely do so, it is their network after all, and there is no meaning in those bits. EUI-64/RA is just to make some cases (the dental office one for instance) really simply, but it is not a solution for everything else. Pick and use what is useful... BTW: Most OS's allow overriding of the MAC address, next to of course just configing an automatic EUI-64 address as a static one on an interface ;) Your network, your rules, your problem if you peep it up. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers)
(That draft would basically be a BCP, cc'd to v6ops where this belongs) [EMAIL PROTECTED] wrote: I think I could have been clearer with my message.[..] Instead, I was presenting what I thought was an interesting example of a subtle problem that can come up in ipv6 deployment. I think it is a good idea to document common examples of how one could setup a datacenter, or at least a small network. One thing to note is that people should stop thinking in IPv4 terms. Yes, IPv6 is in effect only more bits, but those bits belong to you and you can use them to do all kinds of new interesting setups as you are not limited any more to what you are doing with respect to address usage. Generally the ideas for a network I follow are: - autoconfig (or if wanted DHCPv6) for hosts (client+server) Turn off RFC3041 on all hosts (it is just annoying IMHO :) - for servers use the autoconfigged address for 'management' purposes - for services, use a /64 per service, or just use one with all services. Call these 'service prefixes'. Thus DNS could be pfx::53/64. Then you can use quagga or similar to do OSPF/BGP/whatsuitesyou on the server and announce that it is able to serve DNS, just announce the pfx::53/64 (or /128 or whatever) everything in the network can use pfx::53 for DNS resolutions. Of course the side-effect is that you can just setup another host and do the same trick, then have some scripting on those hosts to check if the service is actually working and retract announces when needed. Voila a very nice distributed-by-anycast-local-service setup. Repeat this trick for any service you want. Remember, if your service becomes busy, just add another box, or just move it to another etc. Also, if the MAC of the box dies, it is unrelated to the actual service and outages will be kept to a minimum. This of course works for http-proxies/smtp-servers/imap-servers etc. Note that for the service prefix, as it is generally only for serving local clients, one could quite well use a ULA prefix, which will thus will never change even if changing upstreams or disconnecting etc. YMMV on that one though. Note that you just need a route to that ULA prefix and can avoid clients having to have a secondary address in that range. Benefit for ULA prefix is of course that automatically it will be hard for external sites (The Big Bad Internet) to reach these services as they don't easily get a working TCP bidirectional path to it. - Forward/Reverse DNS, I simply register the EUI-64's in DNS, hardcoded. One can of course with DHCPv6/(Secure-)DDNS also do it dynamically if wanted. If you are a Windows-shop Active Directory can also help you out in this area. It depends a bit on what you require, how many hosts you have and also how much control you have over these hosts. - DNS resolving is configured either static (we have the service prefix which will most likely never change anyway if lucky) or you could simply do it using DHCPv4||v6. - Don't forget to properly configure your firewalls ;) Another note for a lot of people who use a VPN when working from home but where the VPN is only IPv4-capable. When you are at home you will have a (public) IPv4 address, an IPv6 address and a VPN-IPv4 address, but no VPN-IPv6 address, thus most likely the Internet-IPv6 address will thus hit the firewall and die off there. Thus if you have [EMAIL PROTECTED], 's in the DNS you won't be able to reach them and hilarity ensues as this will cause lots of connections delays due to most firewalls dropping connections, not rejecting them. Thanks to our marvelous IS team here though I found out that ISATAP is a perfect solution to this problem as it automatically sets up tunnels locally when needed, as the VPN IPv4 is 'local' the tunnel works and you can reach resources which would be firewalled when using the global address. Which reminds me to quickly writesubmit another draft I had in my head on that subject. The mailserver in question uses a default redhat enterprise build (actually centos). ipv6 is either enabled by default, or just has a single check box, with no further information. The fact that ipv6 is enabled so trivially carries the implication that just enabling ipv6 won't actually damage anything. Unfortunately if people just click they will open a lot of things that are not needed and can cause issues, for them bot more importantly for others. As that means that the box is not properly configured, clearly as the 'admin' didn't care, why would anyone then even care to receive mail/traffic from them? Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, but this strikes me as a trap that lots of people could fall into. People who make those
Re: problem dealing w/ ietf.org mail servers
John C Klensin wrote: --On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: On 3 jul 2008, at 15.57, Jeroen Massar wrote: [..] Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Despite the :-), I think there is an important question here. Does it imply that this is a use case from which we should be learning... and then fixing the RFCs? Or that you believe that the RFCs are correct and Jeroen's analysis is incorrect? I guess/hope he is just teasing ;) As I privately replied to Kurt already, RFCs are Requests For Comments, as such what I am giving is definitely a comment, and the only way to solve it for real and to give some guidance is to move this problem to v6ops (which I think is the most appropriate WG) and document scenarios that guide people on how to possibly configure a network using IPv6. Of course people could also just get a good book and/or use common sense, unfortunately that is not always happening, especially the latter. I hope it doesn't mean the RFCs ought to govern, even when reality and experience seem to contradict them. See my message to ietf@ + v6ops@ titled: Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers) As RFC's can be updated as much as we want and they definitely are not final. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). SMTP shows that it is perfectly usable for these situations as it nicely rejects the message with a proper message automatically telling you on how to solve it. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Those boxes are not set up correctly thus should not be sending email in the first place. For that matter you should actually be firewalling+logging port 25 outbound so you can monitor any host in your network doing illegal SMTP connects. Spam bots don't use IPv6 yet (afaik), but when they are aware how 'open' everything is and especially that RBL's don't exist yadda yadda, they might just switch over to that. Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 yet as that would change that scenario. Configure your mailservers correctly, it helps you send out mail, and it helps avoid others receiving crap from you. Greets, Jeroen -- For postfix folks: http://www.postfix.org/IPV6_README.html 8 /etc/postfix/main.cf: smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1 8 Other SMTP servers have similar mechanisms. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?
Patrik Fältström wrote: [..] P.S. And if multicast is in use, or unicast or some othercast, that is from my point of view part of the innovation the ISPs have to do (and will do) to ensure that the production cost is as low as possible so that their margin is maximized. I actually see a bit of a problem here as multicast would lower the usage of links, as such, they can't charge as much as with link that is saturated with unicasted packets. Thus to lower the use in the internal network one would use multicast, but the client would then still have to get unicast so that for every listener they are actually paying... Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Multicast and charging (Was: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?)
Patrik Fältström wrote: [..] I am afraid that this is the sort of reasoning that has lead to P2P having such widespread use. I fully agree, (unicast) P2P is a godsend for Transit operators. The fun with p2p is though, that HTTP is also peer to peer and actually anything unicast is p2p from a design point of view ;) Is not one of the problems of exchanging multicast packets that someone that receive a multicast packet do not know how much bandwidth in the internal network that packet in reality will take? If the incoming packet is a unicast packet, there is a 1:1 relationship between incoming and outgoing packets. With multicast, one might have to send 1 packet out over the egress after receiving a packet? Generally a network is a tree, unicast will mean you get a packet per branch, multicast you get 1 packet for all branches. As such your traffic is less. Though indeed, if you get 1 packet from your transit (thus at the root of your network), it takes up 1 packet everywhere else in your network. But you only pay your transit for 1 packet, not the zillion of branches that you might have and thus not for a zillion of packets. AFAIK the biggest problem with multicast is management though. Not evening going onto the subject of it being available in hardware for most platforms... If so, could not new models of charging be that if A send multicast packet to B, the number of packets sent are the number of packets going _out_ from B, not in to B? If it was possible to do such accounting... Multicast account is simple: you do it at the place where you measure, same as unicast. Thus if you have: / H /- I /--- E-- J A --- B --- C --- F \ \--- G \ \ \--- D For multicast, if you have clients everywhere, at A you see 1 packet and at H you see 1 packet, but that same packet is also at I J etc. For unicast you see clients times packets at A and 1 packet at each client. As such, an ISP (B) who has clients C,D,E,F,G..., will pay Transit A, in case of Multicast 1 packet, while for unicast he would pay Transit A for clients packets. In both cases though ISP B will charge his clients for that single packet. As such, multicast makes money for B, but not for A. Transits thus don't like it, ISP's don't get it. Greets, Jeroen (This all reminds me to put working multicast on the list again for SixXS...) u signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Presentation on IP address shortage
Henning Schulzrinne wrote: I'm looking for a reasonably recent presentation on the state of IP address allocation that would be suitable for a class I'm teaching. See: http://www.potaroo.net/tools/ipv4/index.html or for a 'recent' presentation: http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf also google(geoff huston ppt ipv4 prediction) or google(tony hain ppt ipv4 prediction), permutate with pdf ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Eating our own dog food and using SIP for telephony... (was Re: My view of the IAOC Meeting Selection Guidelines)
Dan York wrote: [..] P.S. How many folks out there have phones (hard or soft) from which they can place calls to other random SIP endpoints? (I do, but also realize I'm in a minority.) I know quite a number of people who have and are actively using SIP phones. I personally am a great fan of the Siemens S450IP/S675IP[1], just plug it in, go to the webpage, configure, works, and the fun thing is, it is a normal phone, thus plug in POTS and that also keeps on working. I donated one to my folks, and now it is publically known how I can call up my mum for free (except inethardwarepower etc costs) for a couple of hours if I am cooking something up again ;) The problem at the moment with SIP is: - STUN works, but is sorta annoying to setup - E164 support is not there yet (just try to get your number registered in e164.arpa, workaround: use e164.org) One big solution would be using IPv6 of course ;) But: - most hardphones don't support this - Asterisk doesn't come out of the box with IPv6 *yet*, see [2] With IPv6 enabled, one can at least avoid the STUN tricks and routing the packets over the PBX (eg asterisk) and that would make latency better (unless you have bad IPv6 connectivity) and thus even more enjoyable. Currently, the S675IP with a Asterisk box works like a charm though and it is what I use daily for calling up people and getting called. Greets, Jeroen [1] = http://www.voip-info.org/wiki/view/Siemens+Gigaset+S675IP [2] = http://www.asteriskv6.org/ signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Jaap Akkerhuis wrote: [..] And it seems the the resort is build on the meadows used by the fairies. Fairies hebben geen heibel gemaakt want de golf-velden daar liggen er super mooi bij. Er is ook een helicopter landplaats daar, wat wellicht een goede optie is :) I'm afraid that the potheen will be less available then it used to be. That's progress I assume. What makes me think the public transport might have improved although the traffic jams might be a new problem. That's progress again. Maybe can rent a bike. Een ding wat je dus NIET wilt doen is fietsen in Dublin. Het gaat best op zich hoor, maar je moet wel heel erg oppassen en het liefste over de stoep fietsen. Vooral bussen en taxis hebben namelijk nogal de rare neiging om fietsers gewoon maar de kant (lees: muur, paal, andere autos) in te drukken. Ik heb er een jaartje gewoont en veel gefietst, want dat openbaar vervoer is NIETS, nog erger dan de NS in nederland (al is de trein redelijk de paar keer dat ik hem gebruikt heb): ze hebben geen echt schema voor de bussen, er komen er dus gerust twee achter elkaar en dan heel lang niets, als je je hand niet opsteekt stoppen ze niet. Ze vergeten te stoppen, ook al druk je tig keer op de knop of zeg je het tegen de chauffeur dat ie hem toch echt gemist heeft etc. Oh en dan natuurlijk het verkeer, muur vast want de straten zijn te smal en de bussen passen er eigenlijk niet door heen, daarnaast stopt er een, en de andere erachter moet dan maar wachten, etc, etc. Ramp dus, dus pak je als nederlander lekker de fiets. Aanrader, koop schoenen zoals ik heb: http://www.underground-cybershop.co.uk/acatalog/info_UR_044_L_BLK.html Juist ja, zware schoenen met mooie keiharde plastic neuzen en een tikkel metaal zodat, als er weer een bus over je tenen rijdt omdat die het leuk vind om je de kant in te forceren je iig geen platte tenen overhoudt, nee idd deze schoenen deuken niet :) Platte land, dus in de buurt van dat hotel is het overigens goed te doen hoor, want je zit er effectief in de middle of nowhere, maar *in* Dublin, probeer de fiets maar niet, taxi is een halve optie, de andere manier is de tram nemen, die dan nog half-redelijk rijd. Enne, vergeet de paraplu niet, want die ga je nodig hebben ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Ross Finlayson wrote: Excuse me, but isn't this in the boonies way outside town? Are we going to be stuck in a $200 a night hotel with no reasonable alternative accommodations eating vastly overpriced hotel food and facing a one-hour commute to anywhere else? How easy will it be to commute between the hotel and central Dublin (e.g., if we want to eat lunch or dinner somewhere other than the hotel)? What transportation options are available, and how long will the take? Bus - cheap (in a sense), but takes about 45mins (ex waiting time) Taxi - expensive, takes about 30 mins The bus is funny btw, as it only runs once every while, in Dublin that will mean that they come at random times and might just not come, or there might be two busses directly after each other. The ride is a nice one though as you are guided through large parts of Dublin because of it. For the people with a bit more cash, they have heli-pads at that hotel, so you might be able to pull an Oracle and just fly in and out, but you should be able to pay the taxi then too ;) Oh and one major thing not to forget: umbrella's! No sunshine in that part of the country (unless you are very lucky to accidentally hit some sunshine). For sunshine you will have to go south, or west, that is, of the country, not of the city ;) There is one trick around it though: when it starts raining, just jump into a pub, take a beer, wait till it is over and go to the next pub before it starts raining again, that should keep you busy. For the golfers: don't forget to take along a nice wetsuit to keep you dry ;) Museums are mostly gratis/free and actually pretty good, except for instance Trinity College, if you want to see the Book of Kells, the Library above it (The Long room, aka The Jedi Archives*) which is included in that tour is more worth it though. Don't forget to crash the local Eddy Rockets for a Oreo milkshake and a fishchips place for a battered mars bar. Enjoy ;) Greets, Jeroen * = http://www.irish-architecture.com/news/2002/000238.htm signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 and email routing, was Re: AAAA records to be added for root servers
Tony Finch wrote:
On Fri, 4 Jan 2008, John C Klensin wrote:
However, there is also a rule that, if no MX records are present at a
particular node, the mail system looks for an A RR at the same node and
treats it as if its label appeared with an MX preference of 0. That
default does not apply to records, so it is necessary that
operators understand that, if mail systems are to be accessed using
IPv6, they MUST have MX records at the relevant nodes.
The only document that I know of which specifies IPv6 email routing is RFC
3974, which says that should be treated exactly the same as A. As far
as I know, Exim, Postfix, and Sendmail follow RFC 3974.
It seems that at least Postfix doesn't handle this the way it should do
it. It does IPv6, but not according to how I understand it which is:
--
all_mxs = dig(dom, MX);
sort_on_prio(all_mxs);
done = 0;
for (mx in all_mxs done == 0)
{
all_addrs = dig(mx, |A);
sort__first_then_a(all_addrs);
for (addr in all_addrs)
{
if (connect_to(addr, 25))
{
ret = try_smtp_exchange();
if (connection_timeout) next;
if (ret == 2xx) done = 1; success(); last;
if (ret == 4xx) last;
if (ret == 5xx) done = 1; DSN(); last;
}
}
}
if (!done)
{
queue_message_for_later_retry();
}
--
Then if we have:
---
example.com.
MX 10 a.example.com.
MX 20 b.example.com.
a.example.com.
2001:db8::11
A 192.0.2.11
b.example.com.
2001:db8::22
A 192.0.2.22
--
'a' 'b' are both separate MX's. As such according to the above
pseudo-code, which I deduced from the RFC, whenever 'a' is contactable
and you can get a response from it, you should honor that response. Thus
if you contact 'a' and it replies with a 450 Out of diskspace, try
later or other temp failure or a 5xx error etc, one should go to 'b'.
Postfix contacts a-, gets a 450 diskspace, then contacts a-A, gets
the same error again, and then tries b- and then b-A, which might
accept the message.
We actually noticed this last year because of one of Paul Vixies email
setups rejects-all over IPv4 but accepts mail on IPv6, but as IPv6 gets
greylisted (and thus it sends a 450) postfix tried the IPv4 address
also, which resulted in a 500, rejecting the message, if Postfix would
have properly followed the RFC like in the above pseudo code then it
would have requeued the message and tried again a bit later, which would
have caused the message delivery to succeed.
Indeed it is an odd-case, but it is the way it is specified in the RFC.
Also, the real thing is that one should not retry on the same MX as it
is the same host, otherwise it would be a different host with a
different weight in the MX label.
Also indeed, this does also lighten the load on 'email clusters' where
the MX label has maybe 20 A records or so, as the sender should only try
once to that MX label, and not try and contact all 20 of them.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Transitioning to IPv6 == dual-stack (Re: AAAA records to be added for root servers)
Hallam-Baker, Phillip wrote: [..] example.com MX 1 1 1 smtp1.example.com smtp1.example.com A 10.1.1.1 smtp1.example.com .. Which is a perfect example of dual-stack. As for 'home users', they will get an IPv4 NAT while IPv6 will be e2e. So what if you can pull up the .com domain via IPv6? The DNS server still has to be IPv4 capable or the query will quickly fail at microsoft.com, google.com or wherever. In the mean time: http://www.microsoft.com.sixxs.org http://www.google.com.sixxs.org or: http://www.kame.net.ipv4.sixxs.org if you have IPv4 but want to look at IPv6 only sites. As The Internet for most people is SMTP (see above for the solution) and HTTP (just add a IPv6/IPv4 proxy somewhere) there is not an issue at all with going to IPv6 except for enabling proxies at the right places, configuring tools to use them and getting the connectivity to the users. For everything else SOCKS does still exist. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Deployment Cases
[EMAIL PROTECTED] wrote: Unless I've missed something recent, the IETF did not do a lot of work on the scenario where IPv4 islands need to communicate over an IPv6 Internet, talking to both IPv4 and IPv6 services. It is called dual-stack. That seems to simply ignore the issue by saying, let there be IPv4 everywhere for those who need it. But if there are not enough addresses to grow the IPv4 infrastructure, you can't have IPv4 everywhere. The big question of course is: what exact problem do you want to solve? An IPv4 island, that is blissfully unaware of the IPv4 address crunch until far too late, wants to avoid changing their network but still maintain connectivity to both the IPv6 and the IPv4 Internet. They may have to connect to an IPv6 ISP (for instance if their IPv4 ISP goes bankrupt or they move an office location) or they may connect to an IPv4 ISP who peers with a dual-stack ISP or 6PE ISP. How do they continue to access all Internet services from their IPv4 island, regardless of whether or not the services are using IPv6 only? What is so difficult in going dual-stack? IPv4 is NATted, as it already is at a lot of places, and IPv6 comes in there using a tunnel. Most 'services' that people use over the internet, fall under either: - HTTP - Use a HTTP Proxy with both IPv4 IPv6 - SMTP - Use a SMTP server which supports both IPv4 IPv6 Anything else? Not really. As such, which exact services do you want to transition? Note that this is rather similar to the question raised regarding the IPv4 outage at an IETF meeting. How does an IPv4 laptop user continue to function without interruption when only IPv6 Internet access is available at an IETF meeting? As your source address breaks the moment your connection is interrupted your have an interruption already. But you probably mean so that they can continue using service X, well first start by defining service X. The generic answer is of course NAT-PT, but there is a big reason why we don't want that. Another trick is totd and there are a number of these transition functions which are already in place and in use for a long long time. As such the sole problem left, which is going to be resolved soon, is DNS, we will finally have in the root, next step DNSSEC :) [..] Stating I want to connect from IPv4 to IPv6, can mean a lot of things, is this HTTP? SMTP? or do you really want a generic solution? A generic solution that will work for all TCP and UDP protocols. NAT-PT, but NAT doesn't understand all the protocols, if it did, then we would not have to go to IPv6 in the first place. I don't believe that there is an IETF solution for this scenario which I expect to be a very common scenario specifically because transition to IPv6 is being triggered by an IPv4 address shortage whose effects will be felt first in the network core and ripple outward from there. As you clearly believe that there is no such thing, then make a list of all the things you have tried and where they fail to meet your requirements. Then make a list of the requirements you are missing and propose that we solve that problem. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Deployment Cases
[EMAIL PROTECTED] wrote: [..] Unless I've missed something recent, the IETF did not do a lot of work on the scenario where IPv4 islands need to communicate over an IPv6 Internet, talking to both IPv4 and IPv6 services. It is called dual-stack. One will have IPv4 NAT and IPv6 e2e. This is already the case for most end-users who have received an IPv6 block from their provider or who went to a tunnel broker to get a nice fat /48 IPv6, while they only got a /32 IPv4 from their provider. This has actually been a huge incentive for a lot of people to start using IPv6 and to start using it everywhere they have hosts as this way they can reach all their hosts at home and have full e2e connectivity between machines, thus allowing you to SSH in to your local box. This is a, by now, 8 year old trick btw ;) The big question of course is: what exact problem do you want to solve? Stating I want to connect from IPv4 to IPv6, can mean a lot of things, is this HTTP? SMTP? or do you really want a generic solution? As for the case where you have a limited number of public IPv4 addresses and want to provide them to the clients, who will have IPv6 all the time, there is a sweet little protocol called DSTM (See for more http://www.dstm.info) which solves that problem. Of course a protocol like AYIYA also allows a IPv4 over IPv6 tunnel and lastly we also still have SOCKS and application-specific proxies (eg MX's and HTTP proxies). Oh I forget of course our good old ones: L2TP, PPTP etc :) There are a LOT of choices, probably too many. The following URL: http://www.sixxs.net/faq/connectivity/?faq=comparison has a short list of them, not all of them are on it of course. eg tinc/OpenVPN etc are missing. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mini-cores (was Re: ULA-C)
Keith Moore wrote: In my vision the /48s being given out as PI today can be used for the ID portion, while every transit will give a location /48 to the site that needs it. Over the DFZ the src/dst will be in DFZ/location style, but when it arrives at the endsite it will be in PI mode again. NAT (that evil thing) is useful and when you do it twice you actually still have the same packet and have achieved a tunnel without the overhead of it. The signaling of what to use is the tricky part though. I think that dual NAT can be used in a somewhat benign way. If it's done by bilateral agreement between networks with globally unique prefixes, and the mappings at each end are symmetrical, it seems like it's basically equivalent to a tunnel with a kind of header compression and without the PMTU reduction issues. Exactly what I meant. The 'bilateral agreement' is the unknown magic pixie dust though which should be automated and is the biggest problem. For the rest it is indeed just automated tunnels. And if the addresses used at the host are unique, it gets rid of many of the problems caused by overlapping use of RFC 1918 addresses in IPv4. There's still some issues related to traceability of traffic over the network, but maybe those are manageable. The source and destination address are globally unique. As such you know where the traffic comes from as all these prefixes are correctly registered in whois. This means that an end-site organization might have 5 /48's in whois: one they use for ID, this can be a special block like ULA, PI or just a block they get from one of their upstream ISPs, and maybe 4 from their upstream ISPs. All would be in whois, pointing at least to the ISP responsible and maybe even to the org that is using it. As long as uRPF is correctly enabled nothing will go through the DMZ which is not from the ISP that actually is supposed to send data sourced from that prefix. Traceability thus becomes easier as traffic has to be sourced from the ISP it has to come from. As mentioned above PI blocks can be used for this. As such organizations who can convince all ISPs in the DFZ that they are important enough to have their own routing slot can cough up the dough and be there, others will just have to do with this mechanism to get around. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)
Stephane Bortzmeyer wrote: On Wed, Sep 19, 2007 at 12:50:44AM +, Paul Vixie [EMAIL PROTECTED] wrote a message of 32 lines which said: in the IETF, the naysayers pretty much kick the consenting adults' asses every day and twice on sunday. and that's the real problem here, i finally think. Time to have a formal representation of end-users at the IETF? What is defined as an 'end-user'? You, me, the rest of the people, are all end-users IMHO. That we might have quite a bit more knowledge on how things work and that we might have some connections to people so that we can arrange things, is nothing of an advantage over people who are not technically inclined (or how do you put that nicely ;) The point is that those people don't know better and as such they also don't know what is possible and what they are missing. Eg, if you tell somebody oh but I have a /27 IPv4 and a /48 IPv6 at home and I can access all my computers from the Internet wherever I am, they will be going and? why would I need that. The typical lay-man end-user really couldn't care less, as long as their stuff works. The only people really noticing problems with this are hobbyists and most likely the gaming crowd trying to setup their own gameserver and finding out that they are stuck behind this thing called NAT. P2P people, thus quite a large group of people using the Internet today, have their tools to nice NAT tricks, thus these won't notice it. And for the rest of the population the Internet consists of http:// and https:// if they even recognize those two things, thus most likely only www and email, the latter likely only over a webinterface... Which group do you want to 'involve' in the IETF and more-over, why? Last time I checked the IETF was doing protocols and not user interfaces. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mini-cores (was Re: ULA-C)
Paul Vixie wrote: Without going into debate about consenting adults, and while I might disagree with Paul in certain fine points, I'd suggest that we consider the ULA-G proposal within the IETF and ask that Paul submit it as an I-D. ULA-G could have broad application if in fact we solve the multihoming problem (IMHO) and I'd like to be the optimist and say that we can do that. i'll need new coauthors. i ain't signing up for this alone, and the authors of ULA-C only wrote it up so that we would all know what ideas had been abandoned, not as a way forward. And in another mail wrote: i'm at the ignore ietf now stage with things like DNSSEC DLV, and it's going to come as no shock to me if SIXXS is at the ignore ietf now stage with ULA. My view on the ULA story and for that matter any address space being given out is much simpler and it has nothing to do with ignore, it has to do with what is realistic. That ULA registry is just to demonstrate that a very cost effective (aka 0.0EUR cost) way can be setup where people can register their prefixes if it really is so important for them to have that little bit more certainty that they are 100% unique instead of the collision probability of 4.54*10^-05 even when having 10k connections to other ULA sites. If IANA would want to run similar code I am very happy to provide them with the details etc on how to do it, though I am fairly sure they can easily do it themselves too. Currently organizations need IPv6 address space. ARIN/APNIC/AfriNIC allow them to get a nice /48, or larger if they can justify that. In RIPE land you just become LIR and get a /32 along with it. This allows them to deploy IPv6 today. As for organizations wanting 'disconnected' address space, just go to your RIR and get it. There is (except for AfriNIC) no requirement anywhere to announce the space in the DFZ. If you don't want to go to an RIR, go to an LIR who have a /32 and just ask them for a /48, and pay them a 100 EUR or something for 'administrative fees' or whatever. That is why LIRs exist. This is also what happens today with IPv4 address space. IMHO The /48 PI thing is a good thing. Except that in my view of things in a year or 10-20 they won't be floating in the DFZ any more. The DFZ as we know it will be a real Tier system. Only the Tier 1s and Tier2s, the current organizations who get the /32's and up will be in there. All the 'small' parties, thus the /40 - /48's will be using a non-BGP method of connecting up to the Internet and thus won't contribute to DFZ re-calculations. Routing will become more 'geographic', the only thing you will need to know is that Organization X is a customer of transit Z and Y and they prefer Z, you have a BGP route to transit Z and simply send your packets there. When transit Z flaps around, then you only need 1 update, not 10, which are their customers. Still you will have some state which can be updated in near-real-time, where X will say please send packets destined to me preferably over Y or Transit W is now our preferred transit, use them please. In my vision the /48s being given out as PI today can be used for the ID portion, while every transit will give a location /48 to the site that needs it. Over the DFZ the src/dst will be in DFZ/location style, but when it arrives at the endsite it will be in PI mode again. NAT (that evil thing) is useful and when you do it twice you actually still have the same packet and have achieved a tunnel without the overhead of it. The signaling of what to use is the tricky part though. See [EMAIL PROTECTED] for more of those discussions. Those folks are doing good work. It might indeed not be ready tomorrow, not next year, maybe not in the next 10 years, but really current routing hardware will scale up to that. Remember, only 900 IPv6 routes today and only 1517 prefixes have really been allocated from the RIRs to the ISPs and I don't see another 200k popping out of nowhere anywhere soon. I could be very wrong of course though :) Who can be Tier1 or 2 will then be determined based on cash, connectivity and weight; eg YouTube and Google for instance can do pretty much they want, if they do www.google.com A 1.2.3.4, 1.0.0.0/8 will most likely quickly be theirs, just because otherwise you will have your customers whining that you broke the Internet. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Tony Hain wrote: [..] The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I don't think ULA-C makes sense. We have a RIR system in place. These RIRs are supposed to provide address space for people/organizations who can justify a need for that address space. Clearly everybody does want this address space to be unique and a lot of people for various reasons (statistics, contact info, who it belongs to, which country, etc) want to have at least an entry somewhere in a database that is publicly available. As at least ARIN, APNIC and AfriNIC have policies in place now, which break the global policy that once existed, to provide /48's and upward to individual sites. These sites might or might not be (completely) connected to the Internet, there is no requirement anywhere to do so. As such, there is already a perfect method of getting globally unique and registered address space. As such, there is no need for ULA-C. Which is good, as any address space that gets marked as 'special' will be unusable because some people won't ever update filters, which is their problem of course, but it will hurt others. As history has shown that one day or another you will want to connect to the Internet, having those blocks simply come from the RIRs is the perfect way to do it. As for the routing system problem, simple Economics will resolve that. Either Transit Providers will stop accepting certain sized prefixes or they will nicely start charging serious amounts of cash for the routing slots they occupy. In the mean time the great people working on the [EMAIL PROTECTED] list will find a great method of avoiding that problem. We are at 900 prefixes in IPv6 and I really don't see it hitting 100k of them any time soon. When it does, then we know that we might need to hurry up a bit. But as the IPv4 tables are already at 230k and are doing fine, I think we can have quite a couple of quiet years before that will become a serious issue, especially when ISPs can always filter if they want. Checking the Looking Glass of GRH (http://www.sixxs.net/tools/grh/) it shows also that quite some ISP's are already attempting de-aggregation of their /32's and even the /20's they have received. Still the basic premise is that they should only be announcing that single prefix and most likely they only connect to you at one/two common points anyway and you won't need their more specifics. As such you can filter on those borders to avoid those few routes. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]
Thomas Narten wrote: [..] There was overwhelming support for the PI to end sites proposal. Anyone who was at the ARIN meeting would have to take away two things: 1) some people were seriously worried about the long-term impact the policy would have on routing table size, and 2) there was still an overwhelming sense that PI for end sites was needed anyway, to support the requirements of larger enterprises. There were even some people who shared _both_ views. My view on this is that the RIRs have, partially, done the right thing. A RIR is for allocating internet resources in their region, as such them providing /48's and up to their members is the right thing to do. That they have names like PI and PA for it is IMHO wrong though, they all should have the same name Allocation and the only difference should be the size that they are allocated in, which is based on the justification provided by the request that gets sent to them. This would then allow anybody who can justify the need for address space to get it. A /48 per 'site' is good, especially in the case of businesses, for home-usage though, most very likely a /56 will be more than enough. As such IMHO having 2 sizes, one business, one homeuser, would not be a bad compromise, otherwise the really large ISP's, eg the ones having multiple million customers, would need multiple million /48's and then the address space consumption suddenly really goes really fast. Having /56's there would slow that down a little bit. A /56 is still 256 /64's, and I have a hard time believing that most people even on lists such as ARIN ppml or the various IETF ones will ever configure that many subnets at home. But now something the RIRs should not be doing though is meddling in what ends up in BGP. Fortunately mostly they do stay out of there, but unfortunately the allocation policies are based on them. Routing (currently done mostly using BGP) is something that the ISPs will figure out. In IPv4 /24 is filtered out, for IPv6 at the moment it is /48. ISPs are running the show there and they can do what they want, and as long as their customers can reach the sites they need to they will. They also make up the bulk of the RIR crowd and thus can also set up most of the policies there, nice monopoly settings are very possible that way. Fortunately policies are more or less relaxed and as long as you can come up with some solid business arguments one can get address space quite easily, still the take up on IPv6 is not very high yet. The problem with this, at least assumed, is that a certain point the IPv4 + IPv6 routing tables will 'explode' into millions of routes and apparently people don't want to upgrade their routers to handle these over the coming years, which is somewhat understandable. The big question here is, how quickly will we reach that huge number, and also which hardware will fall over first; or otherwise said: should we really be so worried about this. Looking again at those IPv6 takeup numbers, should we really be worried about routing table explosion in the next couple of years? IMHO not really, most likely current equipment will be able to be used for the next couple of years. Looking at http://www.sixxs.net/tools/grh/growth/ we have surpassed last years number of allocations and one can also clearly see that ARIN (blue) took off quite a bit allocation wise, mostly because of their PI /48s. Still, the total number of prefixes that have been allocated is only ~1600*, thus if every one of them would be announced only 1600 of them would exist in the BGP tables, (unless folks deaggregate) could be me but that is far off from the 200k that we have in BGP, or the 300k that some have internally. Of course internal BGP for IPv6 can become large, but that is why one should use a /40 per PoP or similar constructs to nicely aggregate things up. In the mean time though, there is great working being done on the Routing And Addressing Mailing List (https://www1.ietf.org/mailman/listinfo/ram) and some great ideas have already been shown there. One should also not forget HIP of course and a variety of other problem statements and solutions. Greets, Jeroen * = http://www.sixxs.net/tools/grh/dfp/ signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS as 1980s technology [was Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all]
Keith Moore wrote: [..] I believe I understand how to replace DNS with a better protocol while preserving the existing hierarchy and RRsets and DNSSEC, and allowing graceful transition from the old to the new. However, I'm not sure that I have enough understanding of DNS's failings to engineer something that addresses all or most of them - I just know about the ones I've run into. But I'd like to hear from other people who are interested in replacing DNS, maybe we could collaborate on a proposal that shows how DNS could be improved and how replacement of DNS is feasible. Might I suggest that you first start doing what most sensible people have been doing over the long long years of human existence: - define your problem - define what you want to solve - define for what you want to solve it And then after that is all done, realize that the problem you have is very difficult. The IETF has a simple process for all of this: write a draft. And the alternative process is: build running code. But afaik you already know about this. Bickering about all this is fun of course, but it doesn't help coming to a solution, especially as the solution doesn't have a defined problem set and what it is supposed to solve. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Tony Li wrote: When they do, they are violating the premises on which they received their allocation. As such any ISP which is not willing to provide a /48* to an end-user should get their IPv6 allocation revoked by the RIR. Could you please site chapter and verse? Here's what I can find: http://www.arin.net/policy/nrpm.html#six54 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. Thanks for quoting exactly the correct portion as that part exactly explains what the ISP is supposed to do. Except that the boundary here is worse than what is being proposed, the boundary in the above case is /64 - /48. For instance /128 is not allowed to be assigned to an end-user. They will have to provide at least a /64, but as not exactly one subnet is anticipated for the end site they will have to provide more than that single /64. As the proposal currently on PPML has, it tries to standardize the size of the prefix actually given away. In IETF talk the 'rule' has always been /128 if only one IP, /64 for a single subnet, /48 for anything else (see the architecture RFC's). Proposed now is to add a /56 for home-user sites, and 2 other prefix sizes (which IMHO are a bit overdone). ISPs should be charging based on *bandwidth usage* not on IP usage. Sorry, ISPs charge based on providing a *service*. Yes, that includes bandwidth (and generally flat bandwidth, not usage) and also other components (DHCP, addressing, DNS, email, web hosting, spam filtering, etc). Strange that many ISPs charge *specifically* for more IPv4 addresses. But that is IPv4 addresses, I hope that the RIR's can make very clear to the ISPs in question that they are getting a IPv6 /32 based on the mere fact that they can then assign /48's to their endusers. Someone mentioned the Comcast case, unfortunately for those users, Comcast clearly only has the intention of using the /32 for provisioning the CPE's, they won't be providing /48's from that block. If they where going to do that, they really have to go back to ARIN and request something in the vicinity of a /20, as that would actually cover the x million customers they have. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Tony Li wrote: [..] Most MSOs would VERY much like to sell you a service with a fraction of an IPv4 address today, but they really haven't figured out how they could do so technically. For v6, they will always sell a service with a minimal amount of address, regardless of ARIN policies. If they could figure out how to make that a /128, they would. When they do, they are violating the premises on which they received their allocation. As such any ISP which is not willing to provide a /48* to an end-user should get their IPv6 allocation revoked by the RIR. Unfortunately it is for any RIR not very easy to check up on these things. Though it would be great if the RIRs have an easy reporting mechanism for these cases so that end users can report against ISPs which are not willing to provide them with IP addresses. ISPs should be charging based on *bandwidth usage* not on IP usage. It is really strange that they do do that as they are paying their transits based on traffic too, not on the amount of addresses. Of course it is a great way to do business, but lousy for the enduser, and it will only really cause the thing that IPv6 was supposed to avoid: NAT or better said to be able to provide end-to-end connectivity. Alas, as long as ISPs can get away with it, they will most likely do so. Greets, Jeroen * currently, which is why the /56 thing has come up again, which IMHO might be a good idea as a /48 is an awful lot that I won't even use at home, though a /48 for every end-site is fine by me as it currently is too. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
Brian E Carpenter wrote: There is no other device that can provide me with a lightweight firewall for $50. Yes there is; it's a SOHO gateway with its NAT function switched off for use with a fixed IP address. SOHO gateways with IPv6 support will provide exactly as much firewall protection as a NAT-capable IPv4 SOHO gateway. The only question is when they will cost $50. going-nicely-ietf-offtopic: google(WRT cheap EUR) returned me with: http://www.dd-wrt.com/shop/catalog/product_reviews_info.php?products_id=28reviews_id=21 Which is a Buffalo WHR-G54S for 49.99EUR. When buying them there you get them preloaded with DD-WRT which does IPv6 (and even aiccu :) out of the box. Instead of there you can of course buy a lot of variants of the WRT type of 'routers' in your local shop and make them into real routers by upgrading them to OpenWRT/DD-WRT and a number of variants. WRT's are accidentally also the cheapest managed router/switch/wifibox as you can install SNMPd, SSH/telnet/webif etc etc ;) Problemo solved and yes IMHO those are really nice boxes to have. There are also a few of those boxes which can do DSL for you btw, all depends on the config they come with. Of course there are also a number of vendors who ship with IPv6 support as a standard feature. Greets, Jeroen == Oh and to 'prove' that they do IPv6: 7 sheol.unfix.org (2001:7b8:20d:0:20f:66ff:fec8:5fd4) 16.9 ms 14.006 ms 14.308 ms 7 gehenna.unfix.org (2001:7b8:20d:0:214:bfff:fe72:f83c) 18.911 ms 13.978 ms 15.3 ms Yep, both still work fine and I haven't touched those for quite some time now ;) signature.asc Description: OpenPGP digital signature ___ 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
[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
Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
The IPv6 connectivity problems, at least the ones that I and some others encountered, where resolved yesterday. Thanks to all the folks involved who made that happen! Mike Leber wrote: [..] Would you similarly disconnect a nonresponsive customer because they used a /30 from RFC1918 space on a point to point link with you? That link should not have existed in the first place. Also RPF filters would catch any packets being sourced from that block. [..] Of course, Neustar, who are hosting www.ietf.org, might also want to look for a couple of extra transit providers who can provide them with real connectivity to the rest of the world. That won't renumber Bill Manning's links if that is the problem you are trying to fix. Not much to fix when the person in question doesn't want to fix it. That comment was more meant to point that Neustar should have multiple upstreams. [..] BTW, Jeroen does have a valid beef, [EMAIL PROTECTED] used to not be handled by our normal engineering staff. It was somebody's part time side project. This has changed with the migration of our IPv6 network into our core. Since IPv6 is available via all core routers for customers on the same links as their IPv4 connection, all Hurricane network engineers are now required to be able take care of issues with it. That is great to hear, keep the good work coming! Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ipv6] 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
Steve Powell wrote: Greetings. Thanks for the quick response. That is always appreciated. Some networks don't even take that decency to respond, and for the record, those are the ones that the previous mail is targeted at, in the hope that they at least maybe acknowledge that there is a problem instead of letting everything go into /dev/null. Acknowledging a problem is a first step, fixing it is of course the next and better one. I do not believe 6bone space has anything to do with it. As I wrote in my message, it definitely has. 6bone space is correctly dropped by various AS's and routers, as it is not supposed to be used for almost a *YEAR*. As the ICMP Packet Too Big packets from routers who change MTU also get dropped by that when the router is sending this message from 6bone space, this definitely has effect. Solution: Do not use 6bone space as you are supposed to. 3ffe:80a::/64 is still being used by PAIX in Palo Alto. It's an IX, that is L2, who cares what L3 IP's are used over it? I would depeer those folks, as clearly they don't care about the state of the network anyway. If they do care they will fix it up really soon after you did that. In a week (6/6/7) it was a year ago that you where supposed to stop using it. If in that time you really could not arrange for a renumbering of a transit session I seriously wonder what is wrong in that scenario. In general, I had no problems reaching www.ietf.org from pretty much anywhere in our network. This is because you most likely have a lot of paths which are nicely MTU 1500 all the way, or have something setting it to eg 1280 quite quickly on both sides of the path. However, I have seen stranger stuff with IPv6. If you could send me a traceroute and show me where its dieing, I can do some more poking around. As traceroute uses relatively small ICMPv6 or UDP packets these come through perfectly fine. The problem occur when you want to access as website, eg http://www.ietf.org and the packets are larger than actually fit through the link, thus causing pMTU discovery etc. Even the TCP session setup works fine, but nothing else. When traceroute fails it is 'easy' to pinpoint the problem when you can traceroute from both sides of the pond. If you want traceroutes from an array of networks, please see http://www.sixxs.net/tools/traceroute/ which provides that functionality from several ASNs. As an additional side note, you could of course always offer the IETF (nee Neustar) a transit service, even if it is only for your own customers. This way you avoid the dependency on 2 other networks, the one you connect with and use as a transit for your own network, is notoriously known to not fix problems or even reply. But of course their routing is immeasurably superior*. Note the point that you can't measure it :) Greets, Jeroen * = http://www.he.net/colo_ipv6.html signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Putting IPR on IPFIX while the target of IPFIX is to in effect open NetFlow (Was: [IPFIX] Implementation Guidelines // SCTP)
[..] Benoit Claise [EMAIL PROTECTED] wrote: What you're proposing is something that Cisco has been thinking about for more than 6 months now. Actually we filled in a patent on that one. Because you proposed the idea, we worked on the creation of a new draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt: http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt fully explaining the idea We also posted an IPR: see https://datatracker.ietf.org/public/ipr_list.cgi: https://datatracker.ietf.org/public/ipr_list.cgi . The title of the IPR disclosure is Cisco's Statement about IPR claimed in draft-claise-ipfix-export-per-sctp-stream-00.txt. Alternatively, directly look up http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt: http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt (The above long formatted lines are not mine, 72 is a nice limit FYI) Sorry to be blunt, but what exactly is the point again of 'opening up NetFlow' if there is going to be IPR stuff being smacked upon IPFIX and thus encumbering it? And no the we don't sue when you don't sue sillyness is not 'open'. If there is IPR on this part of IPFIX then it MUST never become part of the standard of IPFIX that is to be the IETF version of NetFlow. The Disclosure http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt doesn't contain *ANY* details on what exactly is IPR'd and what not. So do we just have to assume that everything in that draft is encumbered? I also have to note that the existing IPFIX capable collectors actually can't care so much about what exactly gets delivered and how and in which stream exactly the IPFIX packets are being sent, I am very sure that the collectors that already exist are automatically prior art to what is described in the draft document, therefor nullifying at least half of the draft. I am sincerely wondering _why_ Cisco is first going the long route of trying to get an IETF, and thus widely open accepted, standard form of NetFlow, thus making all kinds of vendors, who are still reluctant to use NetFlow because of IPR nonsense, happy and then suddenly, after a long time of getting people to accept it as a standard means, still yet again go the IPR route to go back to square zero: no vendor will accept IPFIX, and there will be various different kinds of NetFlow for doing traffic, and other kinds of, metering. Please, please, please, come up with something which actually is original, get a patent for that and make your lawyers happy sueing each other over those things. Don't go back to encumber something that is actually starting to get adopted by a lot of vendors. Greets, Jeroen (before anybody screams murder, of course like anything IETFish should be, this is my private personal opinion bla bla...) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: www.ietf.org over IPv6
Christian Huitema wrote: I tested ping, trace route and browsing over Teredo... and it work! But that is more luck than anything else as the upstream 'transit' for Neustar is missing 78 prefixes. See http://www.sixxs.net/tools/grh/dfp/all/?missing=30071 for more details of folks who can't reach the IETF website because of that. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Mail delivery problems
Markku Savela wrote: I recently got notice from IETF mailing lists that my mail has been bouncing. The notice didn't have any examples of the bounces Those bounces are delivery problems, see below why. so I couldn't get any clue what is wrong. However, now I got a bounce notice from bugtrag.. and it had this note [..] Apparently networksolutions for some reason occasionally resolves burp.tkv.asdf.org into resalehost.networksolutions.com. Ever though about the place where bugtraq is hosted? Also note that the IETF has nothing to do with that. Isn't this behaviour totally antisocial from networksolutions and how can it be stopped? Antisocial is accusing organizations. Do a dig and find out: org.172800 IN NS TLD3.ULTRADNS.org. org.172800 IN NS TLD4.ULTRADNS.org. org.172800 IN NS TLD5.ULTRADNS.INFO. org.172800 IN NS TLD6.ULTRADNS.CO.UK. org.172800 IN NS TLD1.ULTRADNS.NET. org.172800 IN NS TLD2.ULTRADNS.NET. ;; Received 349 bytes from 192.112.36.4#53(g.root-servers.net) in 126 ms asdf.org. 86400 IN NS gw1.solid.fi. asdf.org. 86400 IN NS gw.solid.fi. ;; Received 78 bytes from 199.7.66.1#53(TLD3.ULTRADNS.org) in 102 ms tkv.asdf.org. 1800IN NS ns.tkv.asdf.org. ;; Received 68 bytes from 193.65.201.11#53(gw1.solid.fi) in 50 ms Now ask gw1.solid.fi where the NS is, eek a NS - CNAME, that violates some RFC's: $ dig @gw1.solid.fi ns.tkv.asdf.org. ;; ANSWER SECTION: ns.tkv.asdf.org.86400 IN CNAME tkvnic.tkv.asdf.org. tkvnic.tkv.asdf.org.48291 IN A 212.16.100.33 And that host is not alive. So the MX can't be resolved, nor the A record of tkv.asdf.org and as such mail will bounce. Conclusion: Fix your mail setup. Instead of accusing other people of things they don't do. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Network update
Morgan Sackett wrote: All, Some of you have noticed trouble connecting to certain sites. This was an issue caused this morning by an attempt to improve reachability to RE networks that are not multi-homed with a commodity link. Our attempts at implementing the improvements didn't work. Routing policies have been rolled back to the previous configuration and connectivity to all commodity Internet sites have been restored. We would have done this earlier in the weekend, but due to cultural differences we needed for upstream network staff to become available. Network operations will continue to find a solution throughout the day in a way that will not impact the network. If we feel that we have a workable solution we will attempt to implement in the early hours before the meeting tomorrow morning. Silly question maybe, but exactly WHICH network are you exactly talking about? Assuming that it is IETF related, is it the network(s) where the various servers (www1,2,3) are hosted (which are run by NeuStar) or is it the Meeting network, or is it some other network? Note, that you send a message with only 'network update' to the generic world-wide ietf@ietf.org list. Some people are not where you are. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Game theory and IPv4 to IPv6
Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. Yes, because of latency, No because of NAT's. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. [ postgrad hat on ;) ] There is a reason why companies like Demonware (http://www.demonware.net/) exit, they exist solely to provide for a cleanup of the IPv4 mess with NAT's by providing a stable stack that allows them to get around most NAT issues by using mechanisms like STUN. Note that MS has given a very lucrative way of solving this problem by providing Teredo support; games and other programs simply use IPv6, all the NAT issues get solved automagically by Teredo. There are certain costs associated with the various transitions. Latency being the number one problem. Every millisecond extra causes annoyance to users. Unfortunately due to the state of deployment of Teredo relays and other similar techniques these are not usable (yet). The quake approach: client-server works though. P2P is out of the question in many of those cases though. The benefit of being in the IPv4 or IPv6 network is proportional to the size of the networks. I don't have time to run full simulation runs but my preliminary trials suggest that IPv6 is not relevant to the IPv4 exhaustion issue. IPv4 will run out either way. IPv6 won't slow it down for a even a day. Most, if not all, people using IPv6 also have IPv4 connectivity. IPv6 connectivity in general is non-NATted, while IPv4 is behind a NAT. Want to connect to that box behind the NAT? Just use IPv6 and problem solved. Some people tend to just throw around VPN's to those places though. The reason is that the participants are all going to cluster into IPv4/IPv6 or IPv4-NAT/IPv6, there is no incentive I can see to transition to the pure IPv6 state and release the IPv4 addresses. The whole idea of transition is dual-stack. Some people will be on IPv4, others on IPv6. Servers and gateways (SMTP style) will connect them. For instance if you have a IPv6 enabled Quake server (thanks Viagenie) then IPv4 players can also connect to it. Unless you assume that there is a very considerable value to IPv4 over IPv4-NAT all that happens during address exhaustion is that larger and larger proportions of the net disappear behind NATs. In effect you end up with the two speed Internet we want to avoid. No, there is no considerable value of IPv4 over IPv6. There is a considerable value of IPv4 over IPv4 NAT though due this the simple concept called End-To-End, which with IPv6 gets restored so that hosts at least get their own IP address again, avoiding all the rattraps introduced by NAT's. Then again, firewalls can block those people off also again, but that is then the network policy, not because they can't at all do it. (Don't play games at work folks ;) Rather than fight the dynamics of a market with a billion participants I believe that we should embrace them and remember that taking IPv4 to end of life is not exactly an unacceptable outcome. The key is to channel people into IPv4-NAT/IPv6 rather than IPv4-NAT. It also depends on game companies. They should make their games IPv6 compliant so that they at least support it. I am explicitly not saying that they should do IPv6 per default as that will hurt performance in all the cases where quality IPv6 connectivity is unavailable. A toggle to enable it though would be a great step forward. Servers supporting it on the public Internet will then be a second step. The way that I would go about this is to introduce a gold standard for next generation gateways that provide other features that the consumer is likely to consider desirable. Like being maintenance free, working without the complaints and setup time that current devices require. Greets, Jeroen (hoping that Enemy Territory - Quake Wars supports IPv6...) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: www.ietf.org unresponsive over IPv6?
Tim Chown wrote: Hi, While I can establish a fast telnet session to port 80: $ telnet www.ietf.org 80 Trying 2001:503:c779:b::d1ad:35b4... Connected to www.ietf.org. Escape character is '^]'. Attempting to browse via MSIE leads to timeouts. Connecting explictly to http://209.173.53.180 to assure IPv4 works fine. telnet -4 www.ietf.org should do that trick too, but notez bien: www.ietf.orgA 209.173.53.180 www.ietf.orgA 209.173.57.180 www.ietf.org2001:503:C779:B:0:0:D1AD:35B4 We don't know if those are 3 different boxes, or simply 1 box with multiple links/addresses. As IPv4 traceroutes die off one can't tell what really is happening behind ATT (at least from my perspective). Looking at routeviews it seems that both IPv4 /24's have somewhat different ASPaths, going over different upstreams. Perhaps some Apache issue or PMTU issue? Most likely PMTU. Anyone else experiencing this? Works from boxes behind my home DSL line (purgatory.unfix.org) and from my work box, which is behind SWITCH (2001:620::/32). Tested with telnet, MSIE and firefox. See below for traces from the DSL. Can you try tracepath6, which is available afaik only on Linux boxes though, to show the MTU path? (iputils-tracepath is the deb package) Greets, Jeroen -- [EMAIL PROTECTED]:~$ tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1480 1: 2001:7b8:5:10:74::1 32.572ms 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 33.623ms 3: jun1.telecity.ipv6.network.bit.nlasymm 4 34.609ms 4: zpr2.amt.cw.net asymm 5 35.522ms 5: so-5-2-0-dcr1.amd.cw.net asymm 6 34.597ms 6: as0-dcr2.amd.cw.net asymm 7 35.611ms 7: so-4-0-0-dcr1.tsd.cw.net asymm 8 41.612ms 8: so-1-0-0-zcr1.lnt.cw.net asymm 9 41.507ms 9: 2001:7f8:4::31f9:1 asymm 8 137.537ms 10: v3323-mpd.cr1.ewr1.us.occaid.net asymm 7 141.670ms 11: ge-0-1-0.cr1.iad1.us.occaid.net asymm 7 146.538ms 12: unknown.occaid.net asymm 8 152.466ms And then no responses, thus most likely filtered for this kind of trace. But traceroute6 works fully: traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 2001:7b8:20d:0:290:27ff:fe24:c19f, 30 hops max, 24 byte packets 1 2001:7b8:5:10:74::1 (2001:7b8:5:10:74::1) 13.874 ms 9.645 ms 10.963 ms 2 i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl (2001:7b8:3:31:290:6900:31c6:d81f) 9.943 ms 15.581 ms 14.958 ms 3 jun1.telecity.ipv6.network.bit.nl (2001:7b8::290:6900:1c6:7c1f) 16.953 ms * 10.6 ms 4 zpr2.amt.cw.net (2001:7f8:1::a500:1273:1) 10.972 ms 11.501 ms 10.99 ms 5 so-5-2-0-dcr1.amd.cw.net (2001:5000:0:12::1) 11.987 ms 11.614 ms 11.986 ms 6 as0-dcr2.amd.cw.net (2001:5000:0:11::2) 11.989 ms 11.569 ms 10.989 ms 7 so-4-0-0-dcr1.tsd.cw.net (2001:5000:0:20::2) 17.988 ms 17.589 ms 17.989 ms 8 so-1-0-0-zcr1.lnt.cw.net (2001:5000:0:61::2) 21.988 ms 17.505 ms 17.988 ms 9 2001:7f8:4::31f9:1 (2001:7f8:4::31f9:1) 112.99 ms 112.727 ms 113.984 ms 10 v3323-mpd.cr1.ewr1.us.occaid.net (2001:4830:fe:1010::2) 111.988 ms 112.501 ms 112.991 ms 11 ge-0-1-0.cr1.iad1.us.occaid.net (2001:4830:ff:f150::2) 117.969 ms 118.47 ms 118.997 ms 12 unknown.occaid.net (2001:4830:e6:d::2) 121.972 ms 122.48 ms 121.978 ms 13 stsc350a-eth3c0.va.neustar.com (2610:a0:c779::fe) 124.004 ms 124.44 ms 124.975 ms 14 2001:503:c779:b::d1ad:35b4 (2001:503:c779:b::d1ad:35b4) 123.992 ms 122.722 ms 124.007 ms Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: www.ietf.org unresponsive over IPv6?
Tim Chown wrote: On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote: Tim Chown wrote: [..] [EMAIL PROTECTED]:~$ tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1480 This 1480 is actually from the pmtu cache, when it expires, or I flush it manually, it gives: 1?: [LOCALHOST] pmtu 1500 1: 2001:7b8:5:10:74::1 33.631ms 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 35.484ms 3: jun1.telecity.ipv6.network.bit.nlasymm 4 34.532ms 4: zpr2.amt.cw.net asymm 5 36.527ms 5: so-5-2-0-dcr1.amd.cw.net asymm 6 36.572ms 6: as0-dcr2.amd.cw.net asymm 7 36.553ms 7: so-4-0-0-dcr1.tsd.cw.net asymm 8 42.392ms 8: so-1-0-0-zcr1.lnt.cw.net asymm 9 44.520ms 9: 2001:7f8:4::31f9:1 asymm 8 137.479ms 10: 2001:7f8:4::31f9:1 asymm 8 137.774ms pmtu 1480 10: v3323-mpd.cr1.ewr1.us.occaid.net asymm 7 142.540ms 11: ge-0-1-0.cr1.iad1.us.occaid.net asymm 7 147.413ms 12: unknown.occaid.net asymm 8 148.820ms Long live native IPv6 over DSL :) Hop 9/10 are a bit weird though, most likely a TTL bug. And then no responses, thus most likely filtered for this kind of trace. So I'm on RedHat, have tracepath6 installed (not used before, thanks for the pointer :) and I see in comparison: Yes, tracepath6 is a *very* useful tool, but as I demonstrated myself above, it doesn't flush the cache, thus be careful there. Tracepath6 uses some Linux specific tricks for getting certain information, which is why (afaik) it is not available on eg BSD's. $ /usr/sbin/tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::21.191ms 2: zaphod.6core.ecs.soton.ac.uk 1. 93ms 3: ford.6core.ecs.soton.ac.uk 1.915ms 4: 2001:630:c1:100::1 2. 66ms 5: 2001:630:c1:10::1 2.353ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 8.440ms How sure are you these have a MTU of 1500? Best way to test is to do ping6's in the form of ping6 -M do -s 1500 target and decrementing per 10 or 20 till it doesn't respond anymore and then increasing again. 19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 16. 63ms pmtu 1480 Though from this hop you should have 1480 which is at least the correct value for the rest of the route. 1280 should always work of course, but then the link has to indicate this too. The problem with debugging this is that you can't do a traceroute6 from both sides, there might be an async route back to your network which might be causing this issue. Assuming that http://www.sixxs.net/tools/traceroute/ indicates that the three SixXS PoPs inside the OCCAID network, over which the IETF seems to get connectivity at least pick Verio-NTT as an outbound route towards your network. Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug these issues easier? I'll send the secretariat a separate message about that, also that they might want to ask Neustar join up with GRH (http://www.sixxs.net/tools/grh/) to make debugging easier as then we at least have ASpaths also which might help here. [..] Hmm, 1500 vs 1480. Check your neighbor cache after the traceroute/path or even a full TCP connect has completed, you should have an entry similar to: [EMAIL PROTECTED]:~$ ip -6 ro sho cache 2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1 metric 0 cache expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295 The 1480 is noted here, check that that is the case. $ /usr/sbin/traceroute6 www.ietf.org traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets 1 2001:630:d0:f102::2 (2001:630:d0:f102::2) 1.883 ms 2.719 ms 4.513 ms 2 zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1) 4.462 ms 2.485 ms 2.886 ms 3 ford.6core.ecs.soton.ac.uk (2001:630:d0:f000::1) 3.444 ms 0.648 ms 0.64 ms 4 2001:630:c1:100::1 (2001:630:c1:100::1) 1.235 ms 1.104 ms 0.962 ms 5 2001:630:c1:10::1 (2001:630:c1:10::1) 1.21 ms 1.138 ms 1.186 ms 6 * * * 7 2001:630:c1::1 (2001:630:c1::1) 4.982 ms 2.891 ms 2.138 ms 8 2001:630:c1::1 (2001:630:c1::1) 2.562 ms 2.189 ms 2.662 ms These hops are weird IMHO, 7 8 should not be duplicate, prolly a Cisco IOS located there as there are some releases which didn't decrement the TTL when going from Ethernet-ATM or some other weird interface changeover. [EMAIL PROTECTED]:~$ tracepath6 2001:630:d0:f102::2 1?: [LOCALHOST] pmtu 1500 1: 2001:7b8:5:10:74::1 33.450ms 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 33.178ms 3: jun1.telecity.ipv6
Re: IETF lists as RSS?
On Thu, 2006-04-27 at 09:05 +0200, Stephane Bortzmeyer wrote: On Wed, Apr 26, 2006 at 05:01:50PM -0700, David W. Hankins [EMAIL PROTECTED] wrote a message of 56 lines which said: It would certainly be strange, at the IETF, for anyone to suggest using a technology that is known to be pervasively deployed and functional. Atom (RFC 4287) and the various RSS (which one to use, by the way?) are deployed and are functional. For RSS the one that Feed Validator likes, for draft/RFC annnounces, check: http://community.unfix.org/feeds/ No per-user-subscribe yet though, as I unfortunatly broke my right shoulder and that will take some time to mend and typing with one hand is not very speedy ;( Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
[very nice cross posting going on here ;) ] On Sun, 2006-04-16 at 12:10 -0400, Patrick W. Gilmore wrote: [... large snip about trying to bash shim6 which is not finalized yet, thus how can you bash it ? Note: extra sarcasm included in this post. Eat the eggs with salt. ...] Oh, and one thing I should have said last time: Technical arguments are important, but they are only part of the decision process. In other words: You are right with your arguments, but I just threw your args away as they are futile based on the comparison of money earned this way or the other People (like me) have explained that the Internet is a business, and in addition to being .. technically unsavory to many people, shim6 is simply not viable in a business setting. And as you will only care for your business for the coming 10 or maybe 20 years you really can't care what happens to the internet afterward. The idea of IPv6 is (still not was) to have it around for quite some time longer than the lifespan of IPv4. Fortunately, the PI thing is far from the end of the world and will only help catch on, see below. Of course any vendor will love the idea of having to do another IP version of course, bring in the cash ;) Neither backbone operators (vendors) nor end users (customers) are warming to the idea. Just the opposite. (At least in general, the one-in-a-million end user with DSL and cable who likes the idea 'cause he can't figure out how to spell B-G-P or doesn't want to pay for it is irrelevant.) Irrelevant for you as they don't give you money. Indeed, you only look at your own business interrest (and who can blame you for that ;) (Once though the internet was there for the masses and not only for the ones with cash) So how do you get a technology widely accepted when the majority of people involved do not think it is the best technical solution? When the majority of vendors supposed to implement it will not do so for technical -and- business reasons. There is for you indeed a business reason to not like it: the end-site won't have any reason to stick to the upstream. Which is indeed a bad business for many of the 'vendors' you mean. As Eliot Lear also said very clearly: Thanks for lining the vendors and all the stockholders pockets ;) That is in the long run, most likely in the coming 10-20 years the IPv6 routing tables will not have 'exploded' yet, but the folks selling equipment and having stocks of those venders after that most likely will have a nice retirement fund. Thanks to you! Nevertheless, the PI thing is really *not* a bad thing, as it can be used as an identifier for shim6, which is actually perfect. It just saves on having to do a complete policy process for getting address space for this type of usage. But thanks to this, this won't be needed and thus in the end anybody who can get PI can use a shim6-alike solution and won't have any problem with the upstream that actually wanted to lock them in by letting them pay loads for an entry in the BGP tables. Thus people voting for PI, thanks for helping shim6 or another solution in that space, progress a lot :) And finally on a much brighter note, especially for the shim6 folks: I know of quite a number of endsites that don't want to use BGP, the don't care about an entry in the routing tables, but do want to be multihomed in an easy way and also want to have 1 unique address space on their local network, but do want to use different upstreams. Shim6 will be perfect for this and thanks to the PI space their is the perfect identifier. Greets, Jeroen (being sarcastic, I guess the amounts of chocolate did it, but hey, I have a great excuse being only 7 mins away from the LindtSprungli factory outlet, happy easter! ;) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Sat, 2006-04-15 at 19:49 +0200, Iljitsch van Beijnum wrote: On 15-apr-2006, at 18:54, Christian Huitema wrote: [..] It's really too bad, because we almost have what we need to pull this whole scalability thing off in IPv6: stateless autoconfig, DHCPv6 prefix delegation, dynamic DNS updates, MIPv6, shim6. The only thing missing is some finishing touches (ok, more than some for shim6, but it is moving along) and for firewall vendors to jump on the bandwagon and move away from hardcoded IP address based filters. Iljitsch, please stop seeing the 'bad' side about this. If people really are going to stick millions of routes into BGP they will hang themselves anyway as they will be the ones having to buy the fat new shiny routers for lots of cash, which can then be provided by all those nice consultants and vendors who thrive on things like that. The funniest thing is that due to the open process we can always point fingers *evil grin*. But I don't see a problem at all as I mentioned before. The bright point is that the PI space provides something really good: - Folks will have their Globally Unique address space. On which they can rely that it will be theirs for a long time. Which means that it can be used as a perfect identifier for setups like shim6. The PI space will then reside in their own network, while when the packet goes over the internet, at the moment it crossed their border, the packet gets translated to the address space of the upstream provider, when arriving at the other side it gets translated back into the PI space. This will make them happy and keep the routing table very small. Just like the original idea of doing IPv6 PA was :) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
On Fri, 2006-04-14 at 14:17 -0400, Noel Chiappa wrote: From: Kevin Loch [EMAIL PROTECTED] Nobody in that room would have supported a policy they actually believed would blow up the Internet. Who was in the room, BTW? How many of those 60 were from ISP's? Also, does that group have any commitments from ISP's (particularly the large global backbones) to carry these PI addresses? (I assume the group is expecting that PI addresses will be supported by the routing, not by some as-yet-undefined other mechanism.) I guess actually that the larger ISP's are not too happy about PI space in general, as with the Aggregate system they can nicely lock-in customers. As for global backbones, check GRH (http://www.sixxs.net/tools/grh/) and look at the amount of /48's and up seen in the routing tables and which transits are providing these in BGP today. Most, if not all, do this thus this will pose no problem whatsoever. Let's see how it all will take of, when GRH shows a large increase in new allocations we'll notice quickly if this is a success or not. We'll max out the 16-bit ASN space first anyhow ;) In the very very very long run, your undefined mech, we might end up using these PI /48's for 'identifiers', using the upstream's /48 as the locator space. No renumbering will thus be required, only some border changes, and the tricky bit: a signaling protocol for notifying the other end who we are so they can map it back to the PI /48. IHMO that will become a real solution for many problems. Announcing multiple prefixes and using source-address selection for instance is far from pretty. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Copyright status of early RFCs
On Mon, 2006-04-10 at 07:28 -0700, Harald Alvestrand wrote: [EMAIL PROTECTED] wrote: not being the RFC editor, the IAB (or member thereof), or even the (as yet undefinable) IETF, I am not sure I am qualified to render a value judgement here. That said, I am in posession of two bound volumes of the collected RFC series as of the date of publication of said volumes (modulo delays from the time the collection(s) were assembled and the time they were published). One is circa 1995 and the other is circa 1997 ... and I know of at least one CD containing the RFC archives that has been sold. The rules by which the IAB/IESG manage the IETF process have changed dramatically in the past four years... so what was once possible/encouraged seems now to be treated as suspect or illegal beahviour. Who knows if the ISOC/IAB/IESG folks are attempting to claim copywrite on old RFCs (which used to claim Distribution Unlimited)... I think it's much more a question of we won't pay your lawyer's bills if someone sues you over this than a desire to exert any form of control. I think all the IAB, IESG, IETF trust etcetera WISH for all RFCs to be freely copyable in their entirety. The 'entirety' is the key word here, as the cd's and prints Bill mention contain the unmodified complete RFC's. That is, the versions I read where contained complete unmodified RFC's and I expect them to be that way too. I have to note that I have a good number of books, specifically IPv6 ones, which contain excerpts of varous RFC's, even the newest ones. It's indeed a 'who is going to pay for the lawyer riddle' in most of these IPR/Copyright things ;( Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
[cc trimmed] On Tue, 2006-03-28 at 01:54 -0800, Michel Py wrote: People will still want to do NAT on IPv6. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). I guess you missed out on: http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast[RFC4193] You can use that to generate your local prefix and it is much better than site-locals as the chance of collisions is fairly low. And as you know you simply don't want to do a NAT from 10/8 to 10/8 at one point in time when two big companies merge ;) Michel Py wrote: A protocol that would be only v4 with more bits in the first place, with routers / NAT boxes that would pad/unpad extra zeroes (also including extra TBD fields). As this would be 100% compatible with v4 this could be deployed without too many headaches. (I almost got lost in the attribution level here) Then why is IPv6 causing so many headaches? As one can see 6to4 is mostly making up your IPv4+ address from the IPv4 one by doing: 2002 + ipv4 address + padding bytes ;) Ah, of course, one actually need to upgrade most of the internal stuff and upgrade all the applications, convince managers, get money to do it, do training etc... Also for the rest of the thread, overlaying IPv6 over IPv4: RFC4380 Which is more or less a p2p overlay network using IPv6 as the addressing part and thus leveraging a lot of applications already. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
On Tue, 2006-03-28 at 08:00 -0800, Hallam-Baker, Phillip wrote: From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... Precisely. Just what is this fetish about keeping the IP address the same as the packet travels? It certainly doesn't have to be. As long as there is one global identifier which is the same on the other side. A double NAT (thus making sure the packet is 100% identical on the sending and receiving side) with a signalling protocol in between is the solution for this. And there is something already being worked on which does that: shim6. If there is a way for the host to determine that it is behind a NAT and to request external registration of necessary ports the whole process can be made completely transparent to the hosts at each end. You are thinking of UPNP (See http://www.upnp.org or read for instance http://www.microsoft.com/windowsxp/using/setup/expert/crawford_02july22.mspx). Which is already support by Windows for some time and many NAT boxes (ohno I should say 'router' or 'firewall' according to them) vendors also nicely implement it. But it is a kludge and a heavy one as all the applications using it also have to support it and it is not always available and there are not too many applications supporting it, let alone protocols. Next to that, when the well known port on the outside IP is taken it won't work. Just like when there are multiple levels of NAT, or there are no rights to control the UPNP process at all. IPv6 thus gives the advantage over UPNP that: - it is clear and simple to all the applications who they are talking to based on the source/destination IPv6 address - same ideas as IPv4 and no kludges - firewalling can remain the normal firewalling - multiple tools can use the wellknown ports as there are multiple IP's - etc... Other thing you might want to look at is Teredo (RFC4380), which basically implements an p2p overlay network on top of IPv4, but using IPv6 for addressing. (Funny eh that both Teredo and UPNP come out of the MS stables, guess what these guys wanted to solve...) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: too many notes -- a modest proposal Re: Proposal for keeping free speech but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)
[aggregated message, the from's are in the cc, Rob see first reply] Top-PS: Did folks see and read the following: http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-00.txt Michael Thomas wrote: [..] Perhaps we should take a lesson from TCP and set a receive window on IETF mailing lists in the face of conjestion. The sender is thus obligated to keep the transmission within the window, and as a side effect to consider the quality of the, um, quantity. Just this simple step would greatly limit (purposeful) DOS attacks and other death spirals. It also mitigates the free speech attacks by not throttling based on content (which is inherently contentious), but based on wg mailing list bandwidth. A couple of mailinglists already have a form of this, eg for the ipv6 working group mailinglist, see: http://www1.ietf.org/mail-archive/web/ipv6/current/msg06123.html This started somewhere around 18 Aug 2003 on request of the chairs. ftp://playground.sun.com/pub/ipng/ipng-mail-archive/ipng.200308 Note that the list was then still hosted at SUN. Afaik, since this was introduced, people did start posting with higher content quality and lower quantity. Maybe Rob Austein can provide the numbers in a nice graph or some other details? Steve Silverman wrote: It seems to me that limiting users to 3 messages / day (perhaps with a maximum number of bytes) would be a minimal impact on free speech but would limit the damage done by overly productive transmitters. This could be limited to users who are nominated to a limit list by many users. Limiting to less than 3 per day would be the same as suspending for X hours. Next to that it might also inhibit one from fixing a statement, though of course one should re-read their post before posting. How difficult this would be to implement on the message exploders is another question. Mailman is python and it should not be to difficult to add per-poster counters, but this would also require that the secretariat applies those patches and then hope that these changes are really working perfectly well. A lot of testing would be required. Many people depend on the list software, breaking it is not something that will be taken lightly ;) Also avoiding such counters can be done easily by using multiple subscriptions, but indeed that would be obvious. Doug Royer wrote: Are you going to write mailing list software an provide it free of charge to implement all of this? That already exists, it is called Mailman, which is what at least @ietf.org uses and several of the lists not hosted here also. Note the X-Mailman-Version: 2.1.5 header in every post. The existing lists are already there, just add an extra 'full' list, subscribe the mainlist to the full list, which is quite normal with umbrella lists, and presto. Now when somebody gets suspended from the mainlist, the WG Chair can then ask the listadmin to move the subscription of the to be suspended person from the mainlist to the alternate list. Thus add on full, remove from main. The technical part is the very easy part here. It is politics and maybe more over ethnics and some other factors which are the hard parts. Harald Tveit Alvestrand wrote: [..full/main list..] In fact this has been implemented at least once that I know of - on the DNSO GA mailing list. The full version had relatively few subscribers. Only suspended folks or suspended-lovers (AmaViS style) would indeed be interested in following it. To avoid this we could, at first setup the full list to contain all the members of The DNSO list also has a long 'rules of order' file: http://www.dnso.org/dnso/notes/2000.GA-ga-rules-v0.4.html Another variant is the ietf-censored version of the IETF list that I ran for a while, but left to others when becoming IETF chair - google claims that http://vesuvio.ipv6.tilab.com/mailman/listinfo/ietf_censored is a current page for it. I guess the main problem with this list is that the WG Chair doesn't have (much) influence on it. It is neither an official list. Also it is not clear who has been censored or not, which indeed means censoring, while IMHO we still want to allow people to voice their opinions and not simply discard them. The naming 'censored' is thus quite correct for this list but I that is also something that the IETF should steer clear from with a wide angle. Darryl (Dassa) Lynch wrote: snip I was a subscriber to both of the DNSO GA mailing lists and I do think the experiment worked for the most part. As the list isn't active any more it might be useful to get input from the members of the list that where then participating. Of course from both the I want to be on the main and on the full lists. Off-list replies for 'counting' are welcome. I've seen this a few times [..] Anything that can be done to improve participation is a good thing. Exactly my opinion. PS...I've known Jefsey online since those early DNSO and IDNO days and whilst I don't always agree
Proposal for keeping free speech but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)
Anthony G. Atkielski wrote: Pekka Savola writes: Why must each and every WG member be required to filter a person's postings? Much more convenient to do so in one place. Because each and every WG member is an individual, with his own ideas of what he does or doesn't want to read, and imposing the same rules upon everyone prevents members from making their own decisions. It also imposes the decisions of a small minority upon the majority. Here goes for a try... flame me off list if required. As it is indeed quite controversial to 'block' people, maybe there can be a solution that, though it will have overhead for listadmins, it will help the process that the workinggroup is actually for in the first place. In the several messages there have been brought up a number of solutions to the problem where one or multiple entities are (deliberately) flooding/overloading the mailinglists of workinggroups and other places with off-topic messages. There seem to be a couple of solutions, amongst which: - Filtering based on source address at the receiver - Filtering based on keywords, which has really bad side-effects. - Blocking the sender at the mailinglist level. - 3683 PR for complete full blockage of posting rights. The first is reasonably fine, as you don't see the message of the entity that one finds not useful, but you might see responses of others thus this is still intrusive and you still get those messages which you wanted to filter out. The second option might filter out messages which you did want to read. Both still will get these messages in the mailinglist archive, even though there was a consensus that those messages are unwanted. The third and fourth option are pretty definitive, no more messages from that entity, but this might be seen as silencing this persons freedom of speech. My proposal to solve this issue but keeping everybody happy: Two mailinglists: wg@ietf.org + full.wg@ietf.org full.wg@ is completely open, anybody can post anything they want though hopefully on topic on the subject of the workinggroup and of course based on the source address having a subscription *1 full.wg@ is subscribed to wg@ thus full.wg gets everything preserving, at least parts, of the freedom of speech that is wanted and for the people who want to read a lot of mail everyday. Initially everybody who signs up to the wg@ list can post to it. When the consensus on the list is that a member is not participating correctly, ignoring warnings etc, like currently this member can be banned from the list for a temporary amount of time. The member can still voice his opinions on the wg@ list. This thus allows him to voice his concerns to the members that do want to read them. Like the current 3683 PR the ban can become effectively indefinitely for the main list, while the poster is still and always allowed on full.wg@. The big concern here is of course that one could say that if you get booted out of the group that your voice won't be heard as they are not reading the other list. This is of course true, but one can raise their concerns on the full list, for instance Google won't differentiate between them and there will always be folks who will listen to it and forward these concerns when they have valid argumentation. By posting 'good' messages to the full.wg@ list a member can also demonstrate that he is really willing to contribute instead of disrupt. One of the nicest controversies is of course what to determine good and bad, starwars as an example, how bad are the jedi and how good are the sith, it completely depends on the side you are on, nothing else. That all boils down to trust and other factors, any mailinglist admin could abuse his position to set the sender of an address to silently discard, SMTP can have a CC: in the header and mailman will not forward the message to that person and various other nice tricks. I hope the above might give a better point to discuss all this over instead of seeing replies like that is not good see above and other comments without effective constructive arguments. Greets, Jeroen *1 = to avoid the large amount of spam flowing to the various lists which nicely get blocked because of subscription regulation. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: John Cowan supports 3683 PR-action against Jefsey Morfin
Anthony G. Atkielski wrote: John Cowan writes: Filtering him out individually, as I do, is insufficient: one still must read the polite or exasperated responses of others. I am almost at the point where I will filter any posting that so much as *mentions* him. Why don't you do that, then, so that he need not be banned just for your convenience? And then suddenly somebody makes a seriously good contribution and your filter accidentally filters out that message which does have a lot of value and thus importance for the working group. The signal to noise ratio has risen way too much by all this talk about one person and simply takes away a lot of time from a lot of people who can do a lot more technically interesting work when that ratio is brought back to signal instead of just being noise. Being able to completely shutdown a person after having repeatedly warned that person about his behavior is the only real solution here. Another aspect is that the mailing lists also contains those non-technical,non-wg-relevant discussions which effectively are on the level of Usenet-alike flame war going back and forth in the mailing list archives. Anybody wanting to join the wg will only find those messages, possibly missing out on the things that really matter. That doesn't help in progressing the task of the working group at all. Discussions should be based on technical aspects relevant to that working group, not to a myriad of other arguments which are far from the topic of the WG's task. Yes, it is excluding somebody from giving his viewpoints, but it is not without arguments that this will be done and the person who this is bestowed upon has had many chances of bettering his way of posting and drifting off topic all the time. Note also that the PR only allows the complete banishment from the list if that WG decides that that is deemed necessary. Other WG's which do not have a problem with the postings of a PR'd person can freely choose to accept them, but of course then have a choice to ban the person too. [..] But you still mention irrelevant matters external to this mailing list in your post. Any personal problem you may have with someone outside the list (or vice versa) is completely unrelated to IETF work or mailing lists, and the inconvenience you suffer from having to press the delete key is also only very tenuously linked to this list. Thus in your opinion you tolerate the behavior where people contact your boss for actions you take personally (IETF is on personal basis not on business basis, at least in theory) on a public forum!? Another way to look at your point of view is to say that mailinglists should accept spam. As the enduser who receives the list should simply filter them out. If somebody has a problem with you in the way you are behaving in such a forum one contacts the list administrator or working group chair. It's a list issue when it originates on the list, not a business issue, thus your boss has absolutely no relevance in this area. It more sounds like such a method can only be meant as a backstabbing 'teach a lesson' method to a person than anything else. What good does that bring? Or do you also call up the wife of the WG chair when you don't like his decision to complain to him that she should give him food that evening as you don't have any arguments left any more and simply start doing ad hominem attacks? Maybe your employer's advice wasn't so bad. That is is true of course, looking at the situation, taking a bit of a stand-off point of view, reiterating things before doing etc are a good thing, but sometimes the SnR ratio simply becomes way to high... Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: List archives and copyright [WAS Re: John Cowan supports 3683 PR-action against Jefsey Morfin]
Michael Froomkin - U.Miami School of Law wrote: delurklawyer If you post to a list with a publicly announced public archive -- and even more so if you are informed about the archive at the time you join the list (hint: you usually are) -- then I think it's pretty clear under US law [..] IANAL but one really doesn't have to bother with US law, that really doesn't apply to many folks (fortunately :) There is a much better thing than US law, it's called IETF, and the fact that there is: http://www.ietf.org/maillist-new.html which contains: 8-- All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979. --8 Mailinglist traffic also are subject to that. One gets a copy of this when signing up for the various lists. On Mon, 23 Jan 2006, Anthony G. Atkielski wrote: Since public archives are usually a violation of copyright, anyway, the entities that maintain them are poorly placed to complain. According to you Google and every other website indexing service is a violation of copyright, better get sue'ing then, you might get rich. And archives can be purged after the fact, without impairing the flow of messages to the list in real time. Archives are meant to store things, which is what they are doing, if you don't want to contribute then simply don't. Greets, Jeroen (Who wonders that now I've quoted mr Atkielski if I am in violation of his copyright...) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
Hallam-Baker, Phillip wrote: SNIP previous posters text It might seem odd to people whose names do fit in ASCII but there are a lot of people who care about this type of issue. You can of course publish drafts and RFC's as XML which supports any character set you want. SNIP The IETF has had the attitude 'this is the way we do things here, nobody asked you to like it'. It would be better to state: if you don't like it, participate. Because if you didn't participate, then don't complain that it isn't like you wanted it to be. Yes that requires significant effort, time and thus cash, but that is mostly unavoidable. So far 700 translations of W3C specifications have been made by SNIP One can always start translating RFC's: 4267 RFC's and a long list of drafts to go, though there is a lot of material already translated by book authors. Note that many languages don't have translations for many English words. German is one of the good examples where they have a lot of German versions of English words, but they don't have one for 'Hyper Text Transfer Protocol' unless you babelfish it to Hyper Text-Übergangsprotokoll*, which is far from a useful translation. There is also the thing that sentence construction might cause misinterpretation from what the original working group meant. SHOULD and MUST both translate to Muß in German, which is thus not correct either. This can cause many issues. And German is somewhat in the same line as English, I am not even thinking in the area of Asian languages, which I unfortunately am far from familiar with except that they resemble small pictures of what they mean. I don't think it is a task for the IETF itself to translate documents. But it would indeed be nice to have a place for them, with a big note that they have not been verified and may include odd translations. Maybe there could be a separate 'translated documents' section? Greets, Jeroen * contains a U-umlaut (Uuml;) and Ringel-S (szlig;) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spam in the IETF's name?
On Thu, 2005-10-20 at 08:40 -0700, RL 'Bob' Morgan wrote: On Thu, 20 Oct 2005, Harald Tveit Alvestrand wrote: That's what got me upset over that aspect; if it had started out I and a few other friends have this great idea that we're pushing in the IETF, and we want to meet to talk about it, I'd only have been upset about the method, not the content. It seems to me the actual IETF involvement here (and I got the invitation too, more than once) is that the list is hosted @ietf.org. I wasn't aware that IETF hosted lists for discussion of things that might become WGs. I see from https://datatracker.ietf.org/public/nwg_list.cgi that in fact there are quite a few, including this one. But I also see that such things require AD approval. So presumably the [EMAIL PROTECTED] initiators submitted something to the apps-area ADs to support this list creation. Another point that would be good to do is that there is an announcement on the ietf-announce list when a new list is created, stating it's purpose so that people who are interrested in this area now that it is happening and not behind people's backs. At the moment one could check on the mailman/listinfo/ page all the time but that isn't really helpful. Thus: please announce new lists when they are created. Greets, Jeroen PS: I like the idea of Digital Identity coming into the IETF arena, thus I signed up, as for the BCC's I prolly didn't see it as SA-marked spams go into /dev/null; enotime for checking them... signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: George Green takes over internet Re: 5W Intelligence Service Report
Just a little clarification for the archives as this is of course again mis-propaganda etc On Wed, 2005-10-12 at 15:58 -0400, Joe Baptista wrote: Yes - both patents attempt to take control of the adding of tlds to a root zone file. The second patent recorded on 6 July 2005 is an attempt to further recognize the proceedure as being commercial. Will need some native speakers to make out the exact wording on the original patents. SNIP http://nl.ecodoc.mineco.fgov.be/BASIS/BREV/web/brevwebdut11/DDW?W%3DTI+PH+IS+%27TECHNOLOGIE+EN+BUSINESSMODEL+INZAKE%27%26M%3D2%26K%3D004/0623%26R%3DY%26U%3D1 http://nl.ecodoc.mineco.fgov.be/BASIS/BREV/web/brevwebdut11/DDW?W%3DTI+PH+IS+%27TECHNOLOGIE+EN+BUSINESSMODEL+INZAKE%27%26M%3D1%26K%3D005/0340%26R%3DY%26U%3D1 For Non Dutch Speaking people, these two URL's both contain a very important part: 8 Beperkingen: 4. GEWEIGERD / AFGEWEZEN 20050404 8 Which translates to: 8 Limitations: 4. REJECTED 20050404 8 In other words, nobody is getting any patent. There would be a lot of prior art anyway ;) Now back to your normal IETF schedule Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: a new DNS root for the world?
{sort-of IETF off-topic but we have RFC3675}
On Mon, 2005-10-03 at 09:59 -0700, Paul Hoffman wrote:
At 11:58 AM -0400 10/3/05, Marshall Eubanks wrote:
Wouldn't it at least make sense to require that the .gprs
pseudo-TLD be reserved by IANA under Section 4 of RFC 2860
(technical work items and
assignments of domain names for technical uses), with the proviso that
this TLD must not be resolved, except locally ?
Absolutely not. There are already literally dozens (if not hundreds)
of such local tlds, some of which have the same names for different
purposes.
You don't want .sms, .wap, .wap2, .gprs2, .turbogprs ??? :)
There is already a .mobi coming up too, another useless domain.
http://www.icann.org/tlds/stld-apps-19mar04/mobi.htm
Will we also get .computer for computer manufacturers, .toy, for toys?
I don't see any reason why they could not have sticked their .mobi
under, something odd; like say: mobi.corp.com, aren't they doing the
mobile stuff in the first place? But the reasoning for this domain is
really great: stakeholders - money.
http://www.domainbank.net/mobi/index.cfm also lists an excellent things:
As many companies were beaten in the rush to acquire desired .com
domain names, the .mobi sTLD is a new channel to differentiate your
business from the sea of .coms and .nets and to protect your brand
name.
and I really wonder who is going to deliver the news for all the mobile
users:
Further attributes of the .mobi sTLD include personal names (e.g.
User_name.name.mobi) and location-based services (e.g.
NewYork.news.mobi) utilizing the .mobi sTLD.
IMHO there should have been only:
- cc-tld which each contain:
- gov.cc - for goverment organisations (including military)
- name.cc : for companies and others, first come, first serve
no products, no movies, only organisations/lastnames.
- int for global organisations/companies
Indeed way less than what everybody else seem to want.
But unfortunately we got the mil/gov/net/com stuff as legacy, which sort
of breaks the hierarchy. New domains though are uncalled for IMHO.
DNS is there for name esolution, not for finding a company or a product.
hamburger.int is useless imho, as it is sold by company X, if they want
that in the dns then do it hierarchically: hamburger.foodcorp.int,
unless the shop is only there in one country: foodcorp.cc
If you want to find this hamburger, you will use a search engine, they
nicely index it for you, dns doesn't index anything in that way.
But apparently that is not how all the domain-selling cash cows are
thinking, they just see $$$
Greets,
Jeroen
signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Mon, 2005-09-05 at 15:02 +0300, Markku Savela wrote: LLMNR does create extra queries to root servers. Lets say I have named my local devices in LLMNR as fridge tv vcr myserver Which would be easily solved for both mDNS (when not restricting to .local) by first asking the local network using mDNS/LLMNR and then asking DNS. Which takes away the worry of flooding (root) dns servers. (Misconfigured machines are a bigger problem there) This has a *huge* security issue of course when some one starts replying to all those queries with false data (www.paypal.com anyone?, or responding for www.ietf.org and putting all kind of naughty words in the drafts ;) Then again, hosts on the local network can already easily respond to normal DNS queries too by flooding the switch with MAC addresses, putting it into broadcast mode and then simply responding to queries. Of course one will then get some dupes back from the original one which will make things a bit confusing, but most resolvers don't care about those and simply ignore them anyway (afaik). I guess we want DNSSec here, but that was the whole point - zeroconf... That said, it would be really good if both mDNS/LLMNR had a 'off' switch. When a real DNS server responds then we have a working DNS server, with mDNS/LLMNR being targetted at zero-conf networks, apparently, as we have DNS, these networks are configured, they have a working DNS server, thus mDNS/LLMNR is not required. Folks can then use DDNS and other methods for registering names. Another thing one could do then is have a real DNS server respond directly to these mDNS/LLMNR queries, which avoids one to even configure a DNS server. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
[for as112 project: maybe add .local into the list of domains??] On Wed, 2005-08-31 at 14:24 -0700, Christian Huitema wrote: Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. Christian, could you please tell us, for each OS mentioned, how to enable LLMNR? That would enable everyone participating in this discussion to witness for themselves exactly how it works and what it does. You would have to get an experimental implementation of LLMNR from some developer site. This is not 'simply enabling it' :) And then I also wonder if there actually is an implementation for Win98/Win2k those two being pretty old and quite unsupported by now I guess... but this besides the point. To the best of my knowledge, Microsoft is not shipping this code. In these systems, ad hoc names are resolved through NETBIOS. The .local queries observed in Peter's root servers is most certainly not caused by an LLMNR implementation. They are most likely done by these nice DSL router (NAT :) setups. Most of these devices have a .local zone configured too. I would not be surprised if these leaked their queries to the root servers. That said, if people want to limit the effect of these 'bogus' queries onto the root servers I suggest that ISP's join into the AS112 project. Also it would maybe be an idea for AS112 to add .local there? Greets, Jeroen PS: Who ever named the LLMNR draft 'mdns' isn't that completely confusing for people looking up the mDNS draft, that is the protocol that Stuart made? :) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On Thu, 2005-09-01 at 09:38 +0200, Frank Ellermann wrote: Jeroen Massar wrote: [for as112 project: maybe add .local into the list of domains??] (?) Better add .local to a hypothetical 2606bis. Bye, Frank Full ack. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)
On Thu, 2005-09-01 at 20:08 +0200, Harald Tveit Alvestrand wrote: The difference between LLMNR and mDNS here seems to be that mDNS *requires* me to use two different names in the two different cases; LLMNR, while it certainly *permits* me to do so, does not *require* it. Can I read this as LLMNR SHOULD be used with domains in the .local domain ? Which puts it really in the same baliwick as mDNS (that is the version that existed before that draft was written with the name mdns ;) One can of course easily remove the check for the .local from the real mDNS and use it for anything else too. Just change the MUST into a SHOULD in the draft and everybody is happy. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote: Peter, Peter Dambier wrote: Russ Allbery wrote: Margaret Wasserman [EMAIL PROTECTED] writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification during this IETF LC. If you (or anyone else) has intended to raise a blocking technical issue, either with LLMNR itself or with its ability to coexist with mDNS, please make that clearer to me. Sorry I overlooked this: I dont count 25% of the root server traffic a minor issue. Can you point to publicly available data about the rate of .local queries to *all* the root servers (including the anycast servers)? Check for only K: http://k.root-servers.org/index.html#stats Interresting one here is NXDOMAIN responses: http://k.root-servers.org/stats/linx/xstats_SNXD-all.html (note, that is only the LINX node) It is a large part of the traffic and annoying, 0.763 k out of 2116 k queries/sec. Interrestingly that since about June it started to decline which could be because these real root-servers (http://www.root-servers.org/) also have a project called AS112 (http://www.as112.net), which takes care of at least the reverse trees for RFC1918 space. For instance, the Italian node (http://frejus.itgate.net/as112/), run by ITGate is seeing about 100 queries per second for their point of view. The RIPE one (http://www.ripe.net/as112/) in Amsterdam does about 300 queries/s so it really depends on ones point of view. For real details I suggest one to ask either Olaf Kolkman or Daniel Karrenberg (both cc'd so they will not skip this message ;) or other root-server operators who can shed way more light on this subject. In short: having something query for known bogus domains is bad and hurts the root-servers. It can be limited a bit, but not much. Additional note: Making zones 'up' and making an 'alternate root' causes that sometimes these zones leak into the real root, where they don't exist. Eg this happens in misconfiguration cases or people publishing the alternate root DNS names, which don't exist for the rest of the world. That said having an alterante root is more disruptive than having LLMNR. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: regarding IETF lists using mailman: nodupes considered harmful
On Thu, 2005-08-25 at 18:20 -0400, Keith Moore wrote: SNIP Specifics: Mailman has a per-recipient setting called nodupes. The effect of this setting is that any recipient address that has the nodupes flag set, and which appears in a To or CC field of a message sent to the list, will not receive a copy of the message from the list. But they _should_ be getting the message directly already, because of the CC: or To:. Or is there something which causes the person not to get it? Indeed when some 'malicious' person would add Cc's/To's and would instruct his SMTP to not forward to the additional addresses in the Cc/To the users will effectively not receive the message. Or when the recipient doesn't accept messages to [EMAIL PROTECTED] + himself, and expects everything to come from the list directly. But how exactly does this cause a problem? Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Re: regarding IETF lists using mailman: nodupes considered harmful]
On Fri, 2005-08-26 at 10:33 +0200, Peter Dambier wrote: Hi Jeroen, I forwared your message - not replying to show your headder: From: Jeroen Massar [EMAIL PROTECTED] To: Keith Moore moore@cs.utk.edu Cc: ietf@ietf.org offtopic title=what actually happens with mailman Which causes my mailer to forward to purgatory.unfix.org, which I use as my outbound mail box and instructs it to send it to: Aug 26 09:15:07 purgatory postfix/smtp[27087]: 7A73D7FAD: to=moore@cs.utk.edu, relay=smtp.cs.utk.edu[160.36.56.220], delay=8, status=sent (250 Ok: queued as 7FC99273B5) Aug 26 09:15:39 purgatory postfix/smtp[27088]: 7A73D7FAD: to=ietf@ietf.org, relay=ietf-mx.ietf.org[132.151.6.1], delay=40, status=sent (250 OK id=1E8YRo-0002xE-QX) Thus the list gets it, and thus everybody who is subscribed. Keith might get it *twice*: - The first directly from my SMTP box to his - The second from mailman, unless he activated the nodupes option. But as the lists have nodupes enabled per default, he most likely gets it ones, only from me. Thus if I was very mean and I hated Keith (is that possible? :), I could have simply nullrouted his SMTP, or instructed my mailer to ignore the cc's, indeed, Keith would not have received the message from me, and when he would have turned off the nodupes option, which is enabled per default, would not have received it from the list either. But as I like arguments I refuse to do something silly like that, there might be people who do though for whatever reason. Reading material: RFC2821 + RFC2822 and most likely quite some others. /offtopic So you had sent to [EMAIL PROTECTED] ietf@ietf.org received only a copy. Some people might have got nothing. Which people? The only person who might not have received anything is Keith, and only if I would sabotage it forcefully, see above, or some disaster occured somewhere. That is what we all need to do now if I got it correctly. Correctly understanding the workings of SMTP or something else? Greets, Jeroen PS: Before you ask, you get this message: if (mailman-nodupes==active jeroen-isevil()) amount=0; else if (mailman-nodupes==active !jeroen-isevil()) amount=1; else if (mailman-nodupes==disabled jeroen-isevil()) amount=1; else if (mailman-nodupes==disabled !jeroen-isevil()) amount=2; Where jeroen-isevil, could mean that a SMTP box between me and you filters the message out, maybe even a spamfilter could cause that. But the same could happen between the ietf mailservers and you... One simply can't be sure that a message gets delivered. signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: regarding IETF lists using mailman: nodupes considered harmful
On Fri, 2005-08-26 at 03:56 -0400, Ken Raeburn wrote: On Aug 26, 2005, at 03:14, Jeroen Massar wrote: Indeed when some 'malicious' person would add Cc's/To's and would instruct his SMTP to not forward to the additional addresses in the Cc/To the users will effectively not receive the message. But how exactly does this cause a problem? Isn't that enough? Tricking the list software into excluding certain people from part of a discussion, even if it's only the part sent by one certain submitter? It gives a false impression to the other list members that certain list members are part of the discussion when they have quietly been left out. Yes, which is why it might be good if the IETF Secretariat would: * Disable the nodupes feature That is, that per default it is disabled and folks get 'dupes'. * Notify, once, the users who have nodupes active, that it might affect the amount of mail they are getting, referencing or including Keiths original message. Does this a) sound like a good idea, then b) can this be requested? Rest of this discussion follows but can be skipped by most folks... If that's not bad enough, what if the message in question were forged as being from someone who was also excluded from receiving it through this mechanism? SNIP (Of course, if the person is offline for a vacation or something, the same might happen. And habitually signing one's messages may help call attention to the forgery, but we've got a ways to go to make that commonplace.) This part can be indeed only be solved by that simple step, which you and I are already using: PGP sign the message. Though privacy-folks then say 'but then I can't repudiate my message' to which my silly answer is: either say something or don't. I would actually be in favor of a mechanism where only PGP signed messages get forwarded onto the list, others bounced back to the origin stating that the sender can't be verified and that this might be because it is not the original sender + how to setup and use PGP. This also avoids having to check if a message from 'the iesg' actually comes from the iesg by checking the headers. SPF will only help partially in this case. Malicious intent aside, it's also useful to know sometimes if the mailing list software is somehow munging your messages in a way you didn't intend. Stripping out attachments, converting encodings, changing HTML to plain text, etc. (And I've seen mailman occasionally botch some such processing, leaving empty messages, but I don't recall the specifics at the moment, or if it's been fixed.) They have fixed quite a number of issues in that department fortunately ;) I personally like the 'nodupes' feature very much as messages that I get cc'd on, thus most likely a reply to something doesn't get caught by the List-Id header and then sorted in the correct folder, thus ending up in my direct-message folder on this subject so I know that it is a reply and I need to pay attention to it. Something semi-related, nobody complains about the fact that one can Bcc people which thus leads to other people than indicated in the To/Cc to read the message, not that one knows the membership of most mailinglists but still... Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
On Wed, 2005-08-10 at 15:25 -0400, Henning Schulzrinne wrote: The next SIPit event is in about a month; see http://www.sipit.net/ There was a GIMPS (now GIST) + NSIS NSLP interop event just before the IETF meeting (pre-RFC). I wish there were more, but there are some. The NSIS interop was co-located with IPFIX/NetFlow9 NetConf, as can be found at: http://www.ist-mome.org/events/interop/ The IPFIX interop resulted in a 30 min presentation/discussion during the wg meeting and also solved quite a number of ambigues issues and uncovered some things that many people might do wrong while making the implementation. IPFIX is not in last call yet either, but having this interop for sure improved the quality of the document a lot. IMHO Running Code is a good thing, doing an interop before going to last-call is even better. Thus, as mailed before, 2 seperate interoperating implementations would be a good thing to have, not only to take care of all the ambiguities, it also makes sure that the document will actually be used and is not yet-another-paper... Greets, Jeroen (who likes to actually implement things, not write about it ;) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
On Sat, 2005-08-06 at 19:07 -0400, Brian Rosen wrote: I notice that we have stopped being interested in running code. Not everywhere. For the IPFIX protocol, which is currently still in draft status, there where 6 different implementations, both of collector and meters, showing up at the Interop meeting, which took place just before the IETF63. This helped a lot in finding a number of ambigueties, which caused the document editors to revise/reword some parts of the document and will also provide a lot of input, eg common mistakes/misassumptions to the implementation guidelines. Maybe there should be requirement that before having going to Last Call there should at least be 2 separate implementations when a document is created by a working group? Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF servers aren't for testing
Iljitsch van Beijnum wrote: Limiting myself to the www.ietf.org webservers (yes, this address points to two different hosts) it appears this site runs on: Server: Apache/2.0.46 (Red Hat) Server: Apache/2.0.40 (Red Hat Linux) DAV/2 mod_ssl/2.0.40 OpenSSL/ 0.9.7a www1.ietf.org @ cnri/reston.va.us/cogent + www2.ietf.org @ foretec/uunet This is done for failover/bombproof etc reasons, not the perfect thing to do but that will change one day with HIP/shim6/sctp/lot of other hard work that many people are doing. Even though these Apache versions are 2 - 3 years old (with many vulnerabilities found and fixed in the mean time), they're fully capable of supporting IPv6, as are Red Hat Linux versions of around the same age. The problem here seems to be more the fact that, in the US, getting IPv6 connectivity can be quite tiresome. Cogent, the current IPv4 upstream, doesn't do IPv6 (they have 2001:500:2::/48) for instance. UUnet could maybe do IPv6. Maybe the secretariat would wants to try out some tunnels? In any case http://www.ietf.org.sixxs.org also works, though it might indeed be nice if this trick was automatic without appending the domain. Greets, Jeroen PS: I assume RedHat backports fixes so that 2.0.40 actually is a 2.0.53 but with a different version number... signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 Network and IPv6
Brian Haberman wrote: IETF'ers, I would like to raise an issue with everyone in Paris using the IPv6 support provided by France Telecom and the volunteer NOC squad. There are a few rogue client nodes advertising themselves as IPv6 routers. Here is a list of the guilty parties: SNIP - 2001:0688::24::/64 This prefix is actually the one you are supposed to be using, but indeed this one comes from the wrong MAC which is far from nice. Sort of looks like a redirection/mtm attempt. 6to4 prefixes will only 'hurt' when connecting to non-native. Checking my traceroutes from here to eg unfix.org or noc.sixxs.net, I guess I can conclude that FT/OpenTransit might want to start doing a little more peering, eg by going to AMS-IX and setting that up. And this is the bad part of it all there is not usually an easy way to disable accepting of the RA's from a certain device. OS's should have a toggle for this. Of course the ipfw/iptables toggle works here. Regards, Brian Just a poor IPv6 WG co-chair trying to use IPv6 to phone home My connectivity over IPv6 has been reasonable to good, but the flakyness was more the wlan which got saturated on some moments. And hail to SEND that would be a welcome addition indeed. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SRV continued
On Tue, 2005-07-19 at 19:39 -0700, Hallam-Baker, Phillip wrote: While we are on the subject of SRV, port numbers etc: Why not define SRV prefixes for POP3, IMAP4 and SUBMIT so that email applications can auto-configure from the email address alone. Actually.. there is, at least in draft form: http://www.ietf.org/internet-drafts/draft-massar-dnsop-service-00.txt 8--- This document defines a new domain, _service., which can be used for automatic service configuration and discovery. The associated anycast prefixes can be used to configure a default DNS server, which provides lookups for a local _service. domain but also acts as a (caching) recursive DNS server, thus allowing DNS clients to use this well-known address as their default DNS server as well as to use it to find various well known services, thus avoiding manual configuration. ---8 Applied to automatically setting up IPv6 tunnels: http://www.ietf.org/internet-drafts/draft-massar-v6ops-tunneldiscovery-00.txt Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
On Tue, 2005-07-19 at 09:23 -0500, John Kristoff wrote: On Fri, 15 Jul 2005 11:48:28 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: There are certain limitations to the SRV prefix scheme but these are entirely fixable. All we actually need is one new RR to allow one level of indirection to be introduced. With that in place it is possible to use prefixed SRV records in place of port assignments and prefixed TXT records as a means of expressing protocol configuration information. I'm concerned this may usher in DNS SRV message filtering in addition to protocol port filtering. Filtering can always be done, that is the right of the network administrator doing the filtering. That some users won't like it is indeed an issue, but that is political and not technical. One way of addressing that potential effect is to make the port assignments be negotiated between two communicating end hosts. This could be used with or without DNS. It might also provide some remote attack protection, since only a simple passive listener is used to perform the local/remote address/port selection for any active client before the real communication switches to agreed upon (and bound only to) the two process end points. As previously mentioned, RFC1078 - TCPMUX: http://www.ietf.org/rfc/rfc1078.txt Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
On Thu, 2005-07-14 at 15:54 +0100, David Hopwood wrote: Brian E Carpenter wrote: 3. Thus I come to the key question - how high should the bar be for assignments in clearly constrained namespaces? This month's poster child is IPv6 option numbers, but at an even more basic level, we should probably be more worried about port numbers, where we seem pretty close to running out of well-known numbers, and moving along nicely through the registered port numbers. I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase the port number space. I know it's off-topic here, but anyone know why they didn't? It surely must have been considered. It would not make much sense, between 2 hosts you can already have 65536*65536 possible connections*, which should be more than enough(tm) ;) I wonder if there are any hosts actually using more than 65536 connections at the same time. Greets, Jeroen * = Listening sockets of course limit this quite a bit, but even with 2 listening sockets, 40k*60k is still a lot. signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Where to find drafts + state etc (Was: Re: IETF Newsletter: What's cooking?)
On Wed, 2005-06-01 at 01:57 +0200, JFC (Jefsey) Morfin wrote: For example I am unable to understand when last calls are called, what are the current last calls, what is the URL of the Draft people discuss and never give the URL, etc. URL's are volatile, draft versions are too. Check: http://datatracker.ietf.org type in what you are looking for and presto. For tools: http://tools.ietf.org/ As for older versions of drafts: http://www.watersprings.org/pub/id/index-all.html And you might want to snoop around on http://www.IETF.org, it's all there, especially if you do a google(keyword site:ietf.org) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: HTTP/1.1 Protocol: Help Needed
On Mon, 2005-05-09 at 13:32 +0530, Gaurav Vaish wrote: Hi, I have a situation where the clients do not have cookies enabled and I have to authenticate through forms. Authentication through forms is not the way that HTTP authentication works. If you would be doing HTTP authentication* You do need cookies then or you can use a special 'session id' option in the tag. You might want to read eg http://ch2.php.net/session as an example. PHP uses PHPSESSID=id in every url, which is the big disadvantage, unless you have something to include it when you output to the user again. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting Idea? (Was: Last Call: 'Requirements for IETF DraftSubmission Toolset' to Informational RFC)
On Thu, 2005-04-07 at 08:05 -0400, Margaret Wasserman wrote: In the IETF, we use straw polls to get a sense of how many people in the room have an opinion on a particular topic, This room factor is also one of the reasons why I mentioned e-mail in my message. Each WG has a set of active participants and a number of people who don't visibly work, might lurk or do a lot of work behind the scenes on the topic of the WG, at least these people are reading, hopefully, the messages on this list. What if one of the hard working persons has a lot to do, or due to sickness or whatever reason, maybe business somewhere, raising his/her kids, or what about the very normal reason: no time and money, to not attend an IETF meeting. Then this person will not be in the room and thus can't participate in a vote, for which he/she worked very hard to get around. This thus basically means that if he/she can't be there all his work could be just hummed away by some proponent sending in a lot of people, who never did anything at all, and might not even know anything on the subject and let them hum their tone. In short. if you don't have a lot of financial backing one is not getting anywhere in an organization that is supposed to based on individuals, whom are supposed to be doing work on free open internet standards, but are unable to do so over that internet they are making those standards for... Just my two cents ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting Idea? (Was: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC)
On Thu, 2005-04-07 at 07:18 -0400, Thomas Narten wrote: Jeroen Massar [EMAIL PROTECTED] writes: Just like the above, except that the chairs can see the email addresses that people gave when they voted. They could then check this list against the list that has actually been signed up on the wg's mailinglist and filter out discrepancies, might these exist. Maybe this is pointing out the obvious, but discounting input because it comes from someone not subscribed to the list is Poor Practice. Often, the most critical (but also the best) reviews come from folk outside of the WG, who are not following the work closely, and are reading a draft entirely on its own merits, and from a broader perspective than the WG might have. This was not obvious, at least did not directly jump into my mind to me when I wrote the above part, but indeed is very logical. On Thu, 2005-04-07 at 10:26 -0400, Bruce Lilly wrote: In short, quality of argument trumps (if the chair is chairing) quantity. Voting (incl. as straw polls) only measures quantity, not quality. And I fully agree with that statement too. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Voting Idea? (Was: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC)
On Wed, 2005-04-06 at 11:52 +0200, Brian E Carpenter wrote: Well, I thought I'd try something daring. We have people arguing about xml versus nroff (again). If you write Internet Drafts, try this toy (and only vote once, please...). If the toy doesn't work, don't blame me... I just found the site with Google. http://www.internationalvoting.com/int3/ask.cgi?pid=22-143 As this is the tools discussion after all, might it maybe be a good tool to have a voting tool for the IETF? Just like the above, except that the chairs can see the email addresses that people gave when they voted. They could then check this list against the list that has actually been signed up on the wg's mailinglist and filter out discrepancies, might these exist. Thus a following process could be made: - WG Chair adds a vote (topic,description,options,enddate) - Tool posts this new vote to the WG's list. - WG members (*1) read this message and go to the URL that is given in the message - WG member votes - Tool sends a confirmation, to verify that this user is really that user that just voted. - WG member confirms his/her/it's/* vote. - Tool closes the vote - Tool sends results to the list The pro of this procedure is that votes can always be reviewed, checked, they are easily accounted for etc. And best of all, it doesn't require one to be present at eg a meeting, so if for instance there would be a vote during a meeting, even remote participants can be in the vote. Only requirement then would be that people are able to read their email where-ever they are, but that should not be a problem for technical folks would it ? :) Single side-effect I quickly can come up with though would be that people who are reading the WG maillist using an exploder address will come out in the votes as 'bogus' as they are not signed up. These folks could of course be asked under which address they are signed up or some other procedure. There are not likely many, though one never knows for sure of course. This you are not on the mailinglist can of course be handled by the tool. Other side-effects, raise your voice. *1) If you are not on the list, how else will you know what they are talking about, thus why should you vote? ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UPDATE - mp3 audio streaming...
On Wed, 2005-03-09 at 12:23 -0500, Tony Hansen wrote: Kudos for the mp3 streams! So far, the mp3 streams have been quite a success. From the feedback I've heard, the audio quality has been mostly excellent. When combined with the xmpp/jabber rooms, we have a two way communication path, and several meetings I've been in have used this combination quite effectively. The quality indeed was quit good and following the conversation was very doable, having a backpath eg over jabber to the room would be great and would indeed allow almost complete participation. It would be good to have the slides of the speakers then too of course so one can also see the slides. Add a couple of webcams and full internet conferencing ;) It would be nice btw for the few people who have multicast available to also make these streams available over multicast, even if it was just to make the point that it works. Maybe a silly idea, but what about having a meeting completely online? Presenters pass url's to their slides, discuss in the jabber group. Would need a +voice method, like on irc, to be able to let one person to talk at the same time, otherwise it could turn into quite a mess ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MP3 audio streaming for IETF 62
On Sun, 2005-03-06 at 19:43 -0800, Joel Jaeggli wrote: I look forward to more opportunities for multicast evangelism in the future. I think I can speak for Hans, Lucy, myself and the rest of the crew at the UO when I say we still believe that multicast holds out the promise of an empowering, subversive technology for data delivery whose time will come. Bringing the power to the people(tm) is really the way to go. When people can use it then they might start using it and demanding it from their ISP's. When they don't know it exists or cannot use it because there is nobody providing it at all, they will never figure out how much fun it is and the possibilities it can give them. m6bone is doing a good job at this, getting more people connected though is the next step. I sincerely hope that ISP's would start offering multicast connectivity. They could do it in one go together with IPv6 connectivity. There are a few ISP's doing this as a trial/experimental service. This allows their tech folks to play with it while not demanding too much time from them when it breaks... just my two rapfen... ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 6BONE Help
On Sat, 2004-12-18 at 20:28 -0800, Heidi Khan wrote: i. What is the current 6BONE setup and the way it handles IPv6 traffic on existing Internet architecture? ii. Over time, as confidence builds to allow production routers to carry native IPv6 packets, it is expected that the 6BONE would disappear by agreement of all parties. Is this statement true or false? Can u please explain? 6bone has mostly seized to exist already with many ISP's moving to RIR space. It will be permanently and completely iii. Do you see any potential in 6BONE that can attract business community? This is not a technical question but one of hope and luck ;) BTW, [EMAIL PROTECTED] is a mailinglist about the 6bone... Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
On Mon, 2004-11-29 at 01:38 -0500, Eric S. Raymond wrote: Kai Henningsen [EMAIL PROTECTED]: Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS update. My DHCP server is firmware in my Linksys :-). Which is a Linux box, which can be upgraded ;) http://www.openwrt.org/ http://www.seattlewireless.net/index.cgi/LinksysWrt54g etc... 8-- dhcp client / server * caching dns server (with hooks to dhcp to lookup dhcp client hostnames --8 Linksys WRTG's are probably one of the nicest NAT boxes, you can even let them _route_ IPv6, including firewalling ;) (Which reminds me to simply get one so I have a very cheap spare linux box to fool around with, almost cheaper as buying vmware ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Fri, 2004-11-26 at 21:47 +, Greg Skinner wrote: On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote: On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Without solutions to these four problems on the horizon, I can't voice any enthusiasm that the larger address space in IPv6 will eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. That is such a odd argument. When an ISP runs out of IP space, they go to their RIR and say Hey! You! I am running out of IP space gimme a new chunk! And then they get one, usually even 3 months in advance of running out. As long as an ISP can show demand for address space they can get it. You do need to have your network documentation in order of course and fit some other rules, but you will get the space. There is *no* address shortage in IPv4 (nor IPv6), see the various very nice presentations by Geoff Huston which he gave at the RIR meetings and other places. On Sat, 2004-11-27 at 11:48 +0100, Leif Johansson wrote: Jeroen Massar wrote: On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote: For somebody administering a network of 100 machines, the hassle cost of IP renumbering would be twenty times larger. Given this, how could anyone wonder why NAT is popular? Wrong. If you administer 100's or 1000s of machines you build or buy a system for doing address management. Renumbering is only difficult if your system is called vi :-) Wrong ;) Well at least, up to 1000 is probably doable. But what if you are talking about 100s or 1000s of organizations with each a 100 or 1000 machines. My site is 10k+ addresses. Seems easy enough to manage to me :-) And how many organizational bits and how many countries are covered using in that address space? I guess, that for most organizations, especially that started early, one is plain lucky when you can even find the administrator of a certain box, let alone the admin or carekeeper of a certain prefix when the organization goes above around that number. If you _can_ manage it, then you did a very good job ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Why people by NATs
On Thu, 2004-11-25 at 14:53 -0800, Michel Py wrote:
Jeroen Massar wrote:
What if you want to do VoIP from _multiple_
computers or even real VoIP phones.
This has never been an issue in the enterprise.
Indeed not if they are keeping the traffic local or using a proxy.
Then you don't have to circumvent NAT anyhow.
SNIP
Or something nice as setting up a gameserver behind your NAT.
Newer game protocols work fine over NAT.
Please tell me how to setup a eg Doom III, Halflife2 server behind a NAT
and let other people on the internet connect to it.
Thus to draw a picture for you:
+-+ +-+ .--,--,--. +-+
| Game Server |-| NAT Box |{ Internet }--| Game Client |
+-+ +-+ `-,---,--' +-+
This maybe works if you have an uPnP compatible NAT and when above two
support uPnP, but afaik both don't support that. And please don't say
you have to do manual port forwarding on the NAT box.
End to end is not possible in the above, or an even more common
situation, because of course ISP's have to few IPv4 addresses and
IPv4 addresses are expensive thus they charge you for it, thus most
people only get 1 IP address, because there simply isn't an alternative
in most cases (ISP's should charge for traffic not IP's):
+-+ +---+ .--,--,--. +---+ +-+
| Game Server |--| NAT_A |--{ Internet }--| NAT_B |--| Game Client |
+-+ +---+ `-,---,--' +---+ +-+
How will this work? Open 'known ports' on each NAT box? What if you have
two brothers behind NAT_B who want to play a competition to the two
sisters running the Game Server behind NAT_A? Won't work now will it.
Or are you depending on a public server on the internet?
Guess why there are hosting companies selling Game Server packages and
they earn a lot of centavos with that, apparently for them it is not so
hard to get enough IP's, may they be IPv4 or IPv6.
This where NAT sucks: game developers have to write NAT-compatible
code. But they do: contrary to IPv6 which is optional, NAT support has
become mandatory. No NAT support no sales. No IPv6 support nobody
gives a rip.
Chicken and egg, you know the problem quite well.
They could easily support it, but for some reason they don't.
I actually wonder why, because it is not hard at all to do it.
For the coder folks:
http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html
Tell me: which game would you be playing?
1. The game that works over IPv4 NAT.
2. The game that works only over IPv4 no-NAT.
3. The game that works only over IPv6.
Nobody demands an IPv6-only anything. Dual-stack is the keyword
everywhere in all the transition documents I have seen.
Answer: 1. Because 2 does not exist (save for the hacked Quake done by our
Viagenie friends)
and 3 does not sell because NAT is the standard setup these days. Have
a good frag with yourself with IPv6.
You mix up 23 here, but absolutely correct, when there is no chicken,
there will be no egg. Someone has to start doing it and then it will
come by itself.
Nevertheless, most homes currently only consist of
maybe 3 Ethernet segments
Where does this come from? 99.9% of home/SOHO setups consist of _one_
Ethernet segment.
Read the maybe part, I should have inserted a 'max' here though.
I'm not defending NAT, but the course of action that says people will have to
use IPv6 because NAT is not working is flawed.
Quoting yourself from above:
This where NAT sucks: game developers have to write NAT-compatible
code.
I rest my case ;)
What if I wanted to use IPv6 in Mexico while on vacation? I actually could: I
would have to tunnel it over IPv4 over double NAT.
- What would it buy me? Nothing.
- What would it cost me? Configuration time. Not too bad, but do you realize
know how hard it is to configure a network with the laptop on your lap,
a hand holding the pinacolada glass (harder than Noel's) and your eyes
looking at the chiquitas on the beach?
Freenet6 has had this nice automatic tunneling tool for quite some time
already. Oh and due to the many people behind NAT's it also crosses
that. And I know another effort who can do this. Not even mentioning
VPN's (IPv4 and IPv6 over NAT :) which seem to be your solution of
choice.
- What would it buy the cybercaf owner to have IPv6?
Nothing. First, if I needed IPv6 while traveling I would not rely on
availability so I have my own. Second, his tunneling might be worse
than my own (the cybercaf does not run BGP; I do).
You run BGP where? On your laptop, tunneling IPv4/IPv6 over the cafe's
IPv4/IPv6 connectivity? This does not make sense.
Would the
cybercaf owner be able to charge me $2 for 30 minutes instead of $2
per hour? No. Would I choose his cybercaf instead of the one next
door if the sign said IPv6? No.
The question is more: would you pay $2 for 30 minutes of non-NATted
connectivity against $2 for 60
Re: Why people by NATs
On Mon, 2004-11-22 at 14:49 -0500, Eric S. Raymond wrote: Fred Baker [EMAIL PROTECTED]: I submit that if your environment is at all like mine, you don't actually configure 192.168.whatever addresses on the equipment in your house. You run DHCP within the home and it assigns such. That being the case, you actually don't know or care what the addresses are on your equipment. You care that your SIP Proxy and etc know the relationships, and they derive them directly without your intervention. Actually, I do set up static addresses. I'd use DHCP, but if I did that I would not be able to refer to the machines on my local net by name. I do hope that you know you can assign 'static' addresses based on MAC address and a number of other properties that the dhcp client provides. The dhcp server will then just assign the configured prefix. This is actually what most ISP's use, but they will only give people one IP. Until my DHCP client can update my DNS tables with name information on the fly, I'll keep doing doing it this way. Apple's zeroconf technology solves this problem, albeit in a slightly different way, but Linux doesn't deploy it yet. Even Windows can do that ;) But so can any UNIX or basically anything where you can compile bind utils on: http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html or the exact same thing but for Windows: http://unfix.org/~jeroen/archive/Windows_DynamicDNS_Update.zip Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
On Tue, 2004-11-23 at 12:17 +, Tim Chown wrote: On Mon, Nov 22, 2004 at 05:11:26PM +0100, Jeroen Massar wrote: Depends on the type of home user ;) Nevertheless, most homes currently only consist of maybe 3 ethernet segments (wired, wireless, office or something) and maybe a max of 20 hosts. Changing the IP's of those hosts should not be a problem even if you had to do it manually. Most of these NAT boxes come with built-in DHCP support, hopefully the will come with IPv6 and RA and maybe DHCPv6 support too in the near future (Yamaha has them already :) Or you just modify a Linksys router :) Ack, nicely turn that NAT box into a real router by flashing it with a This is unfortunately not something that most people dare to do. Then again, I know that quite a lot of people 'upgraded' their SpeedTouch Home's to Pro's for somewhat the same purpose. And for that matter a lot of people upgrade their Xboxes, PS2's etc. There is always somebody who can do this around. I understood there where Seasoft firmwares for above linksys's that even have aiccu preloaded on it, so that the box can very easily build an IPv6 tunnel in cases there is no native connectivity ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Hi All, It will probably come as no surprise to many of you that I have spent quite a bit of time over the last few years trying to understand why people use NATs and how they could be replaced with more architecturally harmonious mechanisms. I have been completely convinced for several years that IPv6 will not eliminate the (real or perceived) need for NATs, at least not without significant follow-on work from the IETF. Did you ever think of the fact that many participants in the IETF earned a lot of money selling: - NAT solutions - VPN solutions to overcome the NAT problem - Consulting in many ways - Services to 'merge multiple enterprise networks' - ... Maybe some people do not want to solve the problem... Remember that people still need to have food on the plate the next day. We won't be able to eliminate or substantially reduce the use of NAT in the Internet architecture unless we come up with better ways to address the problems that NAT is being used to solve, where better is defined from the user's perspective not from an architectural perspective. For IPv4 you can totally forget the removal/elimination of NAT. For IPv6 there is still a chance that people are educated properly to not even think about it. The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Never heard that gamer complaining that his friends could not join that game server she setup on her computer behind that NAT box? Also any P2P application loves end-2-end because then you don't have to use a 3rd party host to relay the traffic. They care but they don't realize what the problem is especially with the plethora of hacks that allow a NAT to somewhat work like a real end to end address. The problem though is that you have to hack around the NAT every single time. Which IMHO is more costly than getting some extra IP's. These users care about ease of deployment, cost and avoiding unscheduled outages (whether due to security issues or ISP changes). They only want three things: - that it works without problems - with low latency so they can aim correctly in that 3d shoot-em-up. - with high download speeds to get their newest movies and other warez. Home users primarily care about client access to the Web, and enterprise administrators primarily care about keeping internal network connectivity as stable as possible. Web? That is only a _fraction_ of the traffic they are generating. Also web is due to the simplicity of the protocol one of the few generally used protocols that doesn't have any problems with NAT's. Peer-2-Peer (read: end-to-end) is what they are using it for. MSN (and many other similar setups) for instance has this cam addon so that you can view the others person face and chat with the other person. Doesn't work when behind a NAT when you want to broadcast, unless you use the many tricks (eg uPNP) to avoid the NAT. IMO, Internet users are primarily using NATs to solve four problems that the IETF has not reasonably addressed: (1) free IP address space for use on VPNs or other private networks, The world relies on money, nothing is free. RFC1918 came nicely with the problems that we see today with it's usage in combination with NAT's. RFC1918 isn't bad actually, but the thing called NAT is. For IPv6 ULA's should solve this spot quite well. (2) stable provider-independent IP addressing For global or local connectivity? Local see ULA/RFC1918. For Global this cannot be done unless you want 128bit ASN's and 2^128 routing entries. See HIP for instance for one of the solutions to this problem. IP is a routing protocol, not an addressing protocol (DNS is the current addressing protocol in that respect). (3) one-way connectivity to provide protection for client-only nodes You mean firewalls? Could somebody at Cisco wake up and _release_ a working version of Cisco PIX's that support IPv6 please!? They said they had one 3 years ago by now, currently it is 'next release'... (4) zero-configuration home and small office networking. I guess you forgot DHCP for both IPv4 and IPv6 and Router Advertisement for IPv6. Did you read the excellent NAP draft? (Currently draft-vandevelde-v6ops-nap-00 soon, I understood a -01) Let me consider each of these problems separately: (1) Current ISP business models are tied to IP address allocation, and that will need to change to remove the economic/business incentives for enterprises to limit their use of IP addresses. There might be similar changes needed to registry policies and business models. Given that there are some rather large political and financial forces involved, I don't have any idea how/if these changes will come about. In the meantime, the only alternative for the IETF is define portions of the address space that
Re: Why people by NATs
On Tue, 2004-11-23 at 19:02 -0500, Daniel Senie wrote: At 06:00 PM 11/22/2004, Fred Baker wrote: At 12:10 PM 11/22/04 -0800, Chris Palmer wrote: There's another feature of NAT that is desirable that has not yet been mentioned, and which at least some customers may be cognizant of: the fact that NAT is a pretty restrictive firewall. would that it were true. In fact, it is pretty easy to breech. All one has to do is ddos with a the right port prefix, observe a response of any kind, and you can ddos right through it. I take it Cisco NAT implementations are not very well implemented then. Well, in this case I can't blame Cisco, because NAT's are simply made to be implemented well. An actual stateful firewall is a good thing. NAT mostly has the effect of deluding the person behind it into thinking they have a security solution. Stop there. Fred, I am sure you've read or written the code to implement: a) a stateful inspection firewall b) a NAPT implementation (what most folks think of when they talk about NAT). The code is NEARLY identical. In fact, the lookup tables used just need an extra column to track some additional information. That two tools both use bubblesort doesn't mean they fulfill the same function. The same with a lookup table function. Please stop with the argument that NAT and stateful inspection firewalls are different beasts. They are very different. A tiger and a little pussy cat, which one do you pet and take into your lap? Two different beast, though they look the same... The software to implement them is basically identical. If you dislike NATs, say so, but this old argument about NAT boxes not providing security provided by stateful inspection firewalls is just not an honest one. A NAT does not provide security as a NAT doesn't have any rules. Also note that there is usually a _seperate_ firewall component in common NAT boxes (and please don't call them routers as they are not) this is the thing that gives the machine it's little bit of 'security', not that anyone tinkers with the rules, thus keeping the box wide open. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
On Mon, 2004-11-22 at 15:52 +, Tim Chown wrote: On Mon, Nov 22, 2004 at 09:44:18AM -0500, Eric S. Raymond wrote: To sum up, NAT gives me two features: 1. Multiple machines on the single-address allocation the ISP gives me. 2. Decoupling of mt local network addresses from the ISP assignment. I hear a lot of muttering about NATs being evil. I really don't have an opinion on the subject -- I understand some of the theoretical problems, but they've never bitten me. So, asking as a network administrator, how would the implied problems be solved in an IPv6 world? The internet does not only consist of HTTP pages. What if you want to do VoIP from _multiple_ computers or even real VoIP phones. Or something nice as setting up a gameserver behind your NAT. Won't work. That many applications have a lot of tricks to circumvent NAT's, mostly by using some external un-nat-ted server, that is sheer luck, it still is not end to end. For #1, you use IPv6 globals on link for the global connections. For #2, you could (if you wanted) use IPv6 ULAs for intra-site connectivity, if you didn't want to contemplate using globals and renumbering on changing ISP (which is a rare events for a home user?) Depends on the type of home user ;) Nevertheless, most homes currently only consist of maybe 3 ethernet segments (wired, wireless, office or something) and maybe a max of 20 hosts. Changing the IP's of those hosts should not be a problem even if you had to do it manually. Most of these NAT boxes come with built-in DHCP support, hopefully the will come with IPv6 and RA and maybe DHCPv6 support too in the near future (Yamaha has them already :) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
On Wed, 2004-11-17 at 06:55 -0500, Noel Chiappa wrote: From: Brian E Carpenter [EMAIL PROTECTED] You might explain that to the people who say they need IPv6. OK, I'll bite. Grawl back ;) Let's assume what many people now seem to concede, which is that a large part of the Internet is going to continue to be IPv4-only. So, what's the functional difference between: - A host which has an IPv6 only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with IPv4-only hosts out on the global Internet. - A host which has an IPv4 local-only address, which it cannot use (without borrowing a global IPv4 address) to comunicate directly with other IPv4 hosts out on the global Internet. Difference is that the IPv6 host can actually communicate end-2-end globally and not only in it's local network. It is all about *global* communication, not about local communication, you can avoid IANA completely in those cases, simply use 1.2.3.4 as an IP at your convenience, you will have enough 32-bit space then, but you cannot talk to your sister on vacation on japan using VoIP who you really do not want to explain what a NAT box is and how she can get through it with a VoIP tunnel tool or other VPN tricks. Before you argue but there is no IPv6 global connectivity yet, then please check your local Abilene site, with that nice government funded Internet2 and you will find quite a lot of activity there. Asian and European regions are much further in deployment. Not to the doorstep of most houses yet in Europe as they do in Korea and Japan, but with the aid of TunnelBroker systems one can get a long way already and these are also available on your side of the pond of course ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [IETF61] no IPv6?
[off-ietf-topic] On Mon, 2004-11-08 at 09:11 -0500, JORDI PALET MARTINEZ wrote: I saw this: Ordenador-de-Jordi-Palet:~ jordi$ traceroute6 www.6power.org traceroute6 to www.6power.org (2001:800:40:2a03::3) from 2001:468:c12:128:20d:93ff:feeb:73, 30 hops max, 12 byte packets 1 2001:468:c12:128::4 5.709 ms 9.239 ms 7.733 ms 2 2001:468:c12:1::1 25.958 ms 7.548 ms 8.666 ms 3 2001:468:ff:185c::1 9.291 ms 6.951 ms 5.917 ms 4 atlang-washng.abilene.abilene.ucaid.edu 24.813 ms 30.656 ms 22.389 ms 5 hstnng-atlang.abilene.ucaid.edu 52.273 ms 44.055 ms * 6 losang-hstnng.abilene.ucaid.edu 84.828 ms 90.56 ms 74.04 ms 7 3ffe:8140:101:1::2 177.911 ms 187.557 ms 177.877 ms 8 hitachi1.otemachi.wide.ad.jp 177.499 ms 178.498 ms 179.06 ms 9 pc6.otemachi.wide.ad.jp 188.272 ms 188.571 ms 196.552 ms 10 3ffe:1800::3:2d0:b7ff:fe9a:6233 186.833 ms 187.182 ms 198.085 ms 11 3ffe:1800::3:230:48ff:fe41:4e95 194.045 ms 186.767 ms 186.333 ms 12 2001:468:ff:16c1::5 186.615 ms 194.852 ms 187.882 ms 13 v6-tunnel62-uk6x.ipv6.btexact.com 462.663 ms 458.041 ms 459.95 ms 14 2001:800:40:2e02::1 517.889 ms 512.469 ms 515.928 ms 15 2001:800:40:2f02::2 520.688 ms 528.601 ms 513.428 ms 16 ns1.euro6ix.com 532.845 ms 519.352 ms 524.852 ms That has more to do I assume with the connectivity of the last hop, BTExact doesn't really peer nicely with most folks and with the ones whom they do peer it is not good... Why don't you connect this 'euro6ix' site over a real IX? traceroute to ns1.euro6ix.com (2001:800:40:2a03::3) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.381 ms 0.371 ms 0.352 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.587 ms 3.626 ms 3.565 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.189 ms 4.142 ms 5.37 ms 4 ge0-1-0.rtr1.ams-tc2.io.nl (2001:7f8:1::a502:4587:1) 4.424 ms 4.3 ms 4.354 ms 5 ipv6.amsix.m20-tc2.trueserver.nl (2001:7f8:1::a501:5703:1) 4.427 ms 5.112 ms 4.298 ms 6 2001:7f8:5::6334:2 (2001:7f8:5::6334:2) 23.915 ms 12.244 ms 12.48 ms 7 fa-0-0.712-IPv6-omnipotent.sov.kewlio.net.uk (3ffe:4005:fefe::) 12.671 ms 13.072 ms 15.301 ms 8 uk6x.ipv6.btexact.com (2001:7f8:2:1::1) 36.091 ms 40.891 ms 44.18 ms last three hops have broken reverse DNS 9 2001:800:40:2e02::1 87.285 ms 87.96 ms 96.02 ms 10 2001:800:40:2f02::2 97.395 ms 98.563 ms 95.548 ms 11 2001:800:40:2a03::3 89.392 ms 92.025 ms 92.528 ms Notice the 60ms which suddenly appar between hop 8 and 9? $ dig +trace 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.e.2.0.4.0.0.0.0.8.0.1.0.0.2.ip6.arpa 8 0.0.8.0.1.0.0.2.ip6.arpa. 7200 IN NS minerva.ttd.net. 0.0.8.0.1.0.0.2.ip6.arpa. 7200 IN NS artemis.ttd.net. ;; Received 141 bytes from 2001:610:240:0:53::4#53(NS-SEC.RIPE.NET) in 20 ms 0.4.0.0.0.0.8.0.1.0.0.2.ip6.arpa. 172800 IN NS dns1.portalv6.com. ;; Received 149 bytes from 213.0.184.68#53(minerva.ttd.net) in 40 ms --8 ns1/ns2.rcdt.net amongst others should have data for portalv6.com but it doesn't have any, thus the resolving fails there. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: xml2rfc and new RFC3667 requirements
On Wed, 2004-07-07 at 14:34, Tim Chown wrote: I guess many people will use these tools already, but I thought I'd just post that the excellent xml2rfc tool now supports the RFC3667 requirements as per ftp://ftp.ietf.org/ietf/1id-guidelines.txt See http://xml.resource.org/, v1.24. You just need to select the full3667 ipr option, e.g. rfc ipr=full3667 category=... in your XML, where you probably had full2026 beforehand. In other words, you must upgrade your xml2rfc before the I-D cutoff rush next week :) They are already complaining about that since monday with a 'read that url about the new guidelines', while they might just mention that you could turn the ipr option on to the new RFC. You can actually just set the ipr option to 99 and xml2rfc will be compliant for ever as it just checks if it is lower than a certain version when including some text. Quite odd actually, one can't send internet-drafts@ pgp-signed email because their pegasus mua's can't read it but they do dare to complain about some legal crap in a technical document. Submitting .xml's is not an option either apparently, which I would think would be much easier for them to be checked ah they have ipr= wrong. xml2rfc could/should warn about this btw, but then again how many times does this change. Greets, Jeroen PS: For debian users, it is not in there (yet) signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Mon, 2004-06-21 at 14:39, Mark Smith wrote: On Mon, 21 Jun 2004 10:03:46 +0100 Christian de Larrinaga [EMAIL PROTECTED] wrote: snip A traveller cannot change ISP easily so either will just have to accept some things cannot be done or will find a way. As it happens one can preplan and setup a proxy service or a tunnel broker etc that can get round many of these issues. Perhaps the IETF would be wiser to give a warning about the futility of trying to break application transparency. The Internet user may always find a way to communicate on their own terms ... using the following tunnel broker / VPN peer. The neat thing about it is that it uses SSL/TLS over UDP, and you can specify the UDP ports to use. As it uses UDP to encapsulate the IP packets, the outer IP header can be NATted. Also, as it uses UDP, and the ports are selectable, you may be able to punch a pipe through a firewall, by using UDP ports #53 a.k.a. DNS, depending on how well the firewall inspects DNS traffic. If that works out, The Internet user may always find a way to communicate on their own terms, irrespective of NAT. You are forgetting something very big here: Only the smart internet users will find a way out. Normal users, the masses, the ones that bring in the cash, don't know this. The smart ones will pick a real ISP anyways. The others bring in enough cash that even though there are only a few doing the tunneling thing the ISP doing this really doesn't care about those. This are all just normal 'business cases' the same like saying there are not enough IP addresses thus you get only one etc. IETF can't do much about it, except making protocols that can't be NATted and that are of the 'http' or 'p2p' rating, aka something that all the users want but which can't work behind a NAT... enter IPv6 ;) Also the above requires on to tunnel thus you are getting real service from somebody else and basically using your current provider as the l2 provider. The same is the issue with IPv6 Tunnel Brokers which can be seen as ISP's in the fact that they provide IPv6 connectivity. Though the 'l2 medium' is the IPv4 connectivity of another ISP instead of ethernet or cable. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
IPv6 for *.ietf.org services (Was: Re: respect privacy please !)
On Fri, 2004-05-21 at 16:59, JORDI PALET MARTINEZ wrote: SNIP privacy talk The other good example is the IPv6 issue. As I recall, I saw (and even participated) in that debate a couple of times. Today I see no objective reason for not doing that, but we don't have a decision on that. Is that good ? Is this what we expect for an open process ? I heared one reason that there is that the IETF servers don't have IPv6 (yet) is simply because their ISP/transit/upstream doesn't do it and thus it makes it pretty impossible unfortunatly. The software can cope with it without problem mind you. For the web if you really want http://www.ietf.org.sixxs.org et tada you are going through the proxy, thus one can read the website and all of the related sites over IPv6 if you only have IPv6 connectivity, which is quite uncommon I guess, but could happen. As for the rest of the services, namely SMTP, that needs connectivity. It doesn't make much sense of setting up a 'external' mailer which handles the mail over IPv6 and passes it over IPv4 to the real machines. If you need that just make your own MX IPv4+IPv6 complaint, which I think, certainly in the world of today is simply required. Also remember that the roots haven't got any published, that is in the '.' IPv6 DNS addresses thus running 100% IPv6 is unfortunatly not possible yet due to these obstacles... Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Root Anycast
On Tue, 2004-05-18 at 02:16, Paul Vixie wrote: SNIP If you'd like to unify something, perhaps it could be DNS client behaviour and network-owner recursive caching forwarder design. And while you're at it, please outlaw those fiendish DNS-based load balancers. f-root should still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums, and the 500X load 10 years later is due to client stupidity, not population growth or backbone speed increases. Paul, and other rootserveroperators (good scrabble word :), what would your answer/problem/arguments/... be if an ISP would decide to inject routes to the root-servers into their local network and point these request to a local dns cache(s), which would have the correct routes to the the global rootservers of course. It is of course kind of hijacking the connectivity what is happening here. And might this be an idea for a BCP for ISP's? Or another thought that have been raised recently on the 6bone list: Would it be an idea to have 2+ independent globaly routable prefixes, thus in IPv4 2x at least /24 and in IPv6 2x /32 which are allowed to be anycasted by anyone, just like the 6to4 stuff currently. So that ISP's could point these prefixes to their local dns caches, similar to the above but: documented which prefixes those are and no evil hijacking. This could also allow for DNS-client to have hardcoded addresses of these caching DNS prefixes lightening the load on the root servers as with anycast you will always get an answer from the closest one, if all is well and murphy is on his day off of course ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Root Anycast
On Tue, 2004-05-18 at 18:55, Joe Baptista wrote: On 18 May 2004, Paul Vixie wrote: If you'd like to unify something, perhaps it could be DNS client behaviour and network-owner recursive caching forwarder design. And while you're at it, please outlaw those fiendish DNS-based load balancers. f-root should still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums, and the 500X load 10 years later is due to client stupidity, not population growth or backbone speed increases. Not completely due to client stupidity, http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/ it is however a factor :) If you would have even read the CAIDA article you would know why AS112 has been built and that misconfigured _clients_ perform the queries. Also if clients would be using local ISP supplied DNS caches, that would be correctly configured there would be a lot less of a problem. Adding your .god/satan and whatever tld you are trying to advertise won't help at all with the fact that clients are trying to get the RFC1918 and other reverses from the root servers which simply do not exist. That the register even took the article just tells something about their quality, having over 70% advertisement in a 'article'... FYI read up on: http://www.as112.net http://www.chagreslabs.net/jmbrown/research/drafts/draft-brown-pvtipdns-01.html And the current CAIDA work at: http://www.caida.org/projects/dns-analysis/ Greets, Jeroen signature.asc Description: This is a digitally signed message part
RE: callplot tool for generating call flows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Finlayson wrote: At 05:12 PM 3/24/04, Felix, Zhang wrote: It's really a great job, but I can't download the software from the following address, http://sourceforge.net/projects/callplot FYI, this is because the Chinese government's firewall apparently blocks access to the whole of sourceforge.net. Apparently, there's something 'subversive' there :-( Then I guess the solution is to start using IPv6 and use IPv6gate (http://ipv6gate.sixxs.net) already used by many chinese people who are using IPv6. At least Asian sites seem to be the biggest users of the thing as they are able to read all IPv4 sites that are blocked ;) [insert slogan: IPv6: Freedom to the people ] Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQGJElQAAPEoAoJjnmd8LzLjtyW1QpHr+ofmZ ETE5AJ4zQ0HPrj0VdejsyrPUFqzSeZaBQg== =Gx+3 -END PGP SIGNATURE-
