From nick at foobar.org Wed Sep 1 15:20:27 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 01 Sep 2010 14:20:27 +0100 Subject: /48 vs. /56 for customers, was XS4ALL Introduces native IPv6 for DSL customers In-Reply-To: <4C783D2E.8000300@unfix.org> References: <70B48AD4-2913-447F-8AC3-617E03779F38@marcoh.net> <4C7752D1.1000107@ipv6canada.com> <20100827074924.GA4646@srv03.cluenet.de> <1282896054.14629.13934.camel@shane-asus-laptop> <4C7773F5.4030308@unfix.org> <4C777C97.6070500@foobar.org> <4C777F1C.7050303@unfix.org> <4C77C588.2090002@foobar.org> <4C77C88D.1030007@unfix.org> <4C77CC97.6000005@foobar.org> <4C783D2E.8000300@unfix.org> Message-ID: <4C7E531B.2040208@foobar.org> On 27/08/2010 23:33, Jeroen Massar wrote: > It seems you have a rather strong urge to try and cover it too, I wonder > why. If you would not have such a strong opinion you would just state > that you and me disagree and that is it. That is a fact ;) I'll take back what I said, having looked more carefully at: ftp.arin.net:/pub/stats/arin/delegated-arin-latest The 2608::/13 block is carved up into multiple /22s, each of which is registered to MIL-HSTMST-ARIN. My initial understanding was that the US DoD had only been assigned 2 x /22 - one at the beginning of the block, and one at the end, but it would appear that they have been assigned 14 x /22 out of this various chunks from this block, including the /22s at the beginning and the end of the block. No other organisation has received any other allocations out of this block. Regarding whether 2608::/13 is reserved or not, the circumstantial evidence suggests that it is; however, ARIN doesn't appear to have made any public comment on the matter one way or another. Nick From blahu77 at gmail.com Wed Sep 1 17:05:28 2010 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Wed, 1 Sep 2010 16:05:28 +0100 Subject: XS4ALL Introduces native IPv6 for DSL customers In-Reply-To: <9179FBF0-AB70-416D-896B-F563B214C68D@marcoh.net> References: <70B48AD4-2913-447F-8AC3-617E03779F38@marcoh.net> <1282837386.31961.21.camel@daniel> <322E2633-C041-428F-92F3-25F38DAE6F5D@marcoh.net> <20100827072344.636bf9b5@opy.nosense.org> <9179FBF0-AB70-416D-896B-F563B214C68D@marcoh.net> Message-ID: Marco > > Our side is completely passive, so as long as the modem doesn't try to setup IPV6CP nothing will happen. But it still eats a routing entry, address assigment and the whole lot. More over at least now we can see somebody is using IPv6, makes support a whole lot easier. > As I understand this approach is to enable dual stack on the modems/routers. That of course works until you have the IPv4 addresses to hand out. What is your plan for IPV6 only service? How v6 only user will access the old internet ? Or is it the old internet ISPs' problem? -mat From blahu77 at gmail.com Wed Sep 1 17:05:28 2010 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Wed, 1 Sep 2010 16:05:28 +0100 Subject: XS4ALL Introduces native IPv6 for DSL customers In-Reply-To: <9179FBF0-AB70-416D-896B-F563B214C68D@marcoh.net> References: <70B48AD4-2913-447F-8AC3-617E03779F38@marcoh.net> <1282837386.31961.21.camel@daniel> <322E2633-C041-428F-92F3-25F38DAE6F5D@marcoh.net> <20100827072344.636bf9b5@opy.nosense.org> <9179FBF0-AB70-416D-896B-F563B214C68D@marcoh.net> Message-ID: Marco > > Our side is completely passive, so as long as the modem doesn't try to setup IPV6CP nothing will happen. But it still eats a routing entry, address assigment and the whole lot. More over at least now we can see somebody is using IPv6, makes support a whole lot easier. > As I understand this approach is to enable dual stack on the modems/routers. That of course works until you have the IPv4 addresses to hand out. What is your plan for IPV6 only service? How v6 only user will access the old internet ? Or is it the old internet ISPs' problem? -mat From marcoh at marcoh.net Wed Sep 1 17:47:41 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 1 Sep 2010 17:47:41 +0200 Subject: XS4ALL Introduces native IPv6 for DSL customers In-Reply-To: References: <70B48AD4-2913-447F-8AC3-617E03779F38@marcoh.net> <1282837386.31961.21.camel@daniel> <322E2633-C041-428F-92F3-25F38DAE6F5D@marcoh.net> <20100827072344.636bf9b5@opy.nosense.org> <9179FBF0-AB70-416D-896B-F563B214C68D@marcoh.net> Message-ID: On 1 sep 2010, at 17:05, Mateusz Blaszczyk wrote: > Marco > >> >> Our side is completely passive, so as long as the modem doesn't try to setup IPV6CP nothing will happen. But it still eats a routing entry, address assigment and the whole lot. More over at least now we can see somebody is using IPv6, makes support a whole lot easier. >> > > As I understand this approach is to enable dual stack on the > modems/routers. That of course works until you have the IPv4 addresses > to hand out. What is your plan for IPV6 only service? How v6 only user > will access the old internet ? Or is it the old internet ISPs' > problem? The short answer is indeed: 'not my problem'. We did our part. Now it's up to the rest of the internet to follow or loose. The longer answer is we operate in a more or less saturated market, it's unlikely we will grow by such numbers we run into problems the next few years. If we do happen to grow it's probably because we bought a company ands it's likely it will come including some address space. And as we every story the truth will probably be somewhere in the middle. I hope with this step, we showed the world it is possible to deploy IPv6. Together with some other major players like Comcast and Google we are now proving that you can. Hopefully this takes off the next 24 months in such a way that 80 ~ 90 % of the traffic will shift to v6. For the remaining part we can always look into providing some NAT64 solution or the like. For a couple of hundred megabits that won't be a problem. And I'm stepping a bit out of line here. But I can also imagine that access to that NAT64 service will be provided upon payment. Either by the site who doesn't do IPv6 or the end-user who wants to reach them. After all, we invest a nice sum in making this possible. Why should I give you a free ride. MarcoH PS that last comment was a strictly personal view and has nothing to do with my employer or other hats I may wear. From brandon at burn.net Wed Sep 1 19:18:23 2010 From: brandon at burn.net (Brandon Applegate) Date: Wed, 1 Sep 2010 13:18:23 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) Message-ID: Should this work ? I have a working NATPT environment. Using Cisco IOS to do NATPT. Using patched BIND to do DNS64. Doing 'stateless' / option-only DHCPv6. Using Linux client (dibbler for dhcpv6/dns) this behaves wonderful / as expected. All DNS queries get a AAAA (synthesized) back from things that are A only. Clients work just fine (Firefox/Chrome/ssh/$im_client/etc). Tried a Windows 7 laptop this morning - dhcpv6 worked great. Got SLAAC address, got one DNS server (ipv6) via dhcp. Got about a 30% success rate. Google Chrome / IE would connect to ipv4 only sites (sometimes). Ping at command line would ping the NATPT address of ipv4 only host (sometimes). No rhyme / reason that I could see. Am I missing something ? Something wrong with this laptop ? PS: I have tried disabling the 'DNS Client' service to no avail. Thanks in advance - apologizes in advance if this has already been discussed (I did do some quick searching on the list archives though). -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From sesse at google.com Wed Sep 1 19:23:14 2010 From: sesse at google.com (Steinar H. Gunderson) Date: Wed, 1 Sep 2010 19:23:14 +0200 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: Den 1. september 2010 19:18 skrev Brandon Applegate f?lgende: > Should this work ? ?I have a working NATPT environment. ?Using Cisco IOS to > do NATPT. ?Using patched BIND to do DNS64. ?Doing 'stateless' / option-only > DHCPv6. Depending on the router in question, it seems NAT-PT on IOS is extremely buggy and generally no longer supported. Supposedly their new NAT64 solution will fix that, but I think it's only available on ASR1K yet. (I might be very wrong here, of course. =) ) /* Steinar */ -- Software Engineer, Google Switzerland From brandon at burn.net Wed Sep 1 19:44:13 2010 From: brandon at burn.net (Brandon Applegate) Date: Wed, 1 Sep 2010 13:44:13 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: Okay. I guess I'm a bit sloppy in my terminology. I don't know the difference between NATPT and NAT64. I've read through some of Ivan P.'s stuff on his blog but I guess it didn't sink in. Nevertheless, like I said, using Linux as a client this works 100% of the time. I get DNS failures in Windows 7. This is actually using 'resolver code' (browser/ ping) as opposed to a manual nslookup. Eventually it works. I need to set up a sniffer I guess, but my gut feeling is that queries are not leaving the machine to begin with. Just looking for someone to say this should be working / should NOT be working / might work N percent of the time. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From nick at foobar.org Wed Sep 1 19:58:18 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 01 Sep 2010 18:58:18 +0100 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: <4C7E943A.8090300@foobar.org> On 01/09/2010 18:18, Brandon Applegate wrote: > Should this work ? I have a working NATPT environment. Using Cisco IOS > to do NATPT. Using patched BIND to do DNS64. Doing 'stateless' / > option-only DHCPv6. Brandon, Would strongly recommend using Frank Bulk's excellent windows ipv6 configuration scripts here: http://lists.cluenet.de/pipermail/ipv6-ops/2010-March/003267.html These will significantly reduce the level of non-determinism for your windows ipv6 networking requirements, as they completely disable everything except for local LAN ipv6. This will probably not cure your connectivity problems, but at least it will rule out a pile of potential problem sources. Nick From brandon at burn.net Wed Sep 1 21:42:07 2010 From: brandon at burn.net (Brandon Applegate) Date: Wed, 1 Sep 2010 15:42:07 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: Replying to myself here, have some more data. I have a vanilla install of Windows 7 Enterprise. If I ping something, with the following command: c:\> ping www.google.com It fails (DNS). If I immediately run the command again - it works (using the NATPT prefix AAAA record). My next step is to get a SPAN port going and look at the query in real time. On linux, this works immediately / consistently. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From brandon at burn.net Wed Sep 1 22:05:24 2010 From: brandon at burn.net (Brandon Applegate) Date: Wed, 1 Sep 2010 16:05:24 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: Sorry to talk to myself here - but I've figured it out. When my clients were using the patched BIND from http://ecdysis.viagenie.ca/ - both AAAA and A answers come back. I reconfigured the dhcp pool to give out an address that corresponds to the NATPT prefix of our existing resolvers. This triggers the "DNS ALG" functionality in IOS, and I seem to only get AAAA back now. So in short, it appears that Windows 7 fails using the patched BIND DNS64 solution above, but works as expected using the built in DNS ALG in IOS. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 1 23:15:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 2 Sep 2010 06:45:41 +0930 Subject: XS4ALL Introduces native IPv6 for DSL customers In-Reply-To: <20100827080747.GC4646@srv03.cluenet.de> References: <70B48AD4-2913-447F-8AC3-617E03779F38@marcoh.net> <4C7752D1.1000107@ipv6canada.com> <20100827074924.GA4646@srv03.cluenet.de> <41715C4A-E0DF-4E74-8184-DB8ADCDD0A01@marcoh.net> <20100827080747.GC4646@srv03.cluenet.de> Message-ID: <20100902064541.4e662d9a@opy.nosense.org> On Fri, 27 Aug 2010 10:07:47 +0200 Daniel Roesen wrote: > On Fri, Aug 27, 2010 at 09:55:28AM +0200, Marco Hogewoning wrote: > > > Unless you run out of /48s and have to go back to RIPE NCC to get more > > > address space. And then you're judged on /56s, not /48s for efficiency. > > > > No, you are judged on /56 equivalents....the /48 assignment is perfectly valid. > > Sure it is, but it's a difference in the amount of customers you can > support, isn't it? > > With the old /48 HD ratio 0.80 policy, a /32 was to support a customer > base of 52.429 before you qualified for additional address space. With > the new /56 policy with HD ratio 0.94, RIPE NCC asks for 6.183.533 > customers before the /32 allocation is deemed efficiently used. > > Is my understanding of the policy wrong? > I don't think so. However, remember that /32 is the smallest size that anybody can get, so the common size is likely to be quite a bit larger. The cornershop ISP who only has a few thousand customers will be assigned a minimum of a /32. Regards, Mark. From surfer at mauigateway.com Thu Sep 2 00:27:33 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 1 Sep 2010 15:27:33 -0700 Subject: XS4ALL Introduces native IPv6 for DSL customers Message-ID: <20100901152733.8C1D9485@resin07.mta.everyone.net> --- nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: From: Mark Smith I don't think so. However, remember that /32 is the smallest size that anybody can get, so the common size is likely to be quite a bit larger. The cornershop ISP who only has a few thousand customers will be assigned a minimum of a /32. ---------------------------------------------------------------------- Maybe in RIPEland, but not at other RIRs. From experience at a past job (ILEC in Hawaii) I note that ARIN gives a /32 to a network that has 100k+ DSL lines and many leased-line customers. However, they apparently reserve the 2 adjacent /32s for growth. So, you're either forced to hand out /56s or do the CPE part in stages, if you hand out /48s to everyone as a /32 is only 65536 /48s. scott From sesse at google.com Thu Sep 2 01:22:21 2010 From: sesse at google.com (Steinar H. Gunderson) Date: Thu, 2 Sep 2010 01:22:21 +0200 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: Den 1. september 2010 22:05 skrev Brandon Applegate f?lgende: > So in short, it appears that Windows 7 fails using the patched BIND DNS64 > solution above, but works as expected using the built in DNS ALG in IOS. Does the DNS ALG in IOS trigger on TCP DNS on these days? If not, you're in for some fairly unpredictable behavior. (Last time I tested, it would just eat the DNS packets, hanging the request.) /* Steinar */ -- Software Engineer, Google Switzerland From brandon at burn.net Thu Sep 2 01:42:53 2010 From: brandon at burn.net (Brandon Applegate) Date: Wed, 1 Sep 2010 19:42:53 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: On Thu, 2 Sep 2010, Steinar H. Gunderson wrote: > Den 1. september 2010 22:05 skrev Brandon Applegate f?lgende: >> So in short, it appears that Windows 7 fails using the patched BIND DNS64 >> solution above, but works as expected using the built in DNS ALG in IOS. > > Does the DNS ALG in IOS trigger on TCP DNS on these days? If not, > you're in for some fairly unpredictable behavior. > > (Last time I tested, it would just eat the DNS packets, hanging the request.) > > /* Steinar */ > -- > Software Engineer, Google Switzerland > Yes, I just tried it. TCP gets eaten and EDNS doesn't do any better. So yes, IOS DNS ALG (at least in the IOS I'm running) is nowhere near ready to use in the real world. I really liked the BIND DNS64. Would like to do some more captures to see if I can figure out what is making Windows7 unhappy. I'm guessing it's the fact that the BIND DNS64 gives back the A record answers as well as the synthesized AAAA when the question was only AAAA. Linux doesn't seem to care about this. Windows gets tied in a knot (initially, subsequent (after cache) queries work). -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From marcelo at it.uc3m.es Thu Sep 2 07:35:17 2010 From: marcelo at it.uc3m.es (marcelo bagnulo braun) Date: Thu, 02 Sep 2010 07:35:17 +0200 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: Message-ID: <4C7F3795.1070706@it.uc3m.es> El 02/09/10 1:42, Brandon Applegate escribi?: > On Thu, 2 Sep 2010, Steinar H. Gunderson wrote: > >> Den 1. september 2010 22:05 skrev Brandon Applegate >> f?lgende: >>> So in short, it appears that Windows 7 fails using the patched BIND >>> DNS64 >>> solution above, but works as expected using the built in DNS ALG in >>> IOS. >> >> Does the DNS ALG in IOS trigger on TCP DNS on these days? If not, >> you're in for some fairly unpredictable behavior. >> >> (Last time I tested, it would just eat the DNS packets, hanging the >> request.) >> >> /* Steinar */ >> -- >> Software Engineer, Google Switzerland >> > > Yes, I just tried it. TCP gets eaten and EDNS doesn't do any better. > So yes, IOS DNS ALG (at least in the IOS I'm running) is nowhere near > ready to use in the real world. > > I really liked the BIND DNS64. Would like to do some more captures to > see if I can figure out what is making Windows7 unhappy. I'm guessing > it's the fact that the BIND DNS64 gives back the A record answers as > well as the synthesized AAAA when the question was only AAAA. Linux > doesn't seem to care about this. Windows gets tied in a knot > (initially, subsequent (after cache) queries work). but this shouldn't be happening in the general case, afaict. In section 5.1 of draft-ietf-behave-dns64-10 it reads: " If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response" The motivations for not complying with this SHOULD as well as the implications of failing to comply with this should and possible ways to deal with these implications are described in the apendix A of the spec, where it reads: Appendix A. Motivations and Implications of synthesizing AAAA Resource Records when real AAAA Resource Records exist The motivation for synthesizing AAAA RRs when real AAAA RRs exist is to support the following scenario: An IPv4-only server application (e.g. web server software) is running on a dual-stack host. There may also be dual-stack server applications running on the same host. That host has fully routable IPv4 and IPv6 addresses and hence the authoritative DNS server has an A and a AAAA record. An IPv6-only client (regardless of whether the client application is IPv6-only, the client stack is IPv6-only, or it only has an Bagnulo, et al. Expires January 6, 2011 [Page 29] Internet-Draft DNS64 July 2010 IPv6 address) wants to access the above server. The client issues a DNS query to a DNS64 resolver. If the DNS64 only generates a synthetic AAAA if there's no real AAAA, then the communication will fail. Even though there's a real AAAA, the only way for communication to succeed is with the translated address. So, in order to support this scenario, the administrator of a DNS64 service may want to enable the synthesis of AAAA RRs even when real AAAA RRs exist. The implication of including synthetic AAAA RRs when real AAAA RRs exist is that translated connectivity may be preferred over native connectivity in some cases where the DNS64 is operated in DNS server mode. RFC3484 [RFC3484 ] rules use longest prefix match to select the preferred destination address to use. So, if the DNS64 resolver returns both the synthetic AAAA RRs and the real AAAA RRs, then if the DNS64 is operated by the same domain as the initiating host, and a global unicast prefix (called an NSP in [I-D.ietf-behave-address-format ]) is used, then a synthetic AAAA RR is likely to be preferred. This means that without further configuration: In the "An IPv6 network to the IPv4 Internet" scenario, the host will prefer translated connectivity if an NSP is used. If the Well-Known Prefix defined in [I-D.ietf-behave-address-format ] is used, it will probably prefer native connectivity. In the "IPv6 Internet to an IPv4 network" scenario, it is possible to bias the selection towards the real AAAA RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when an NSP is used (the Well-Known Prefix usage is not supported in this case) In the "An IPv6 network to IPv4 network" scenario, for local destinations (i.e., target hosts inside the local site), it is likely that the NSP and the destination prefix are the same, so we can use the order of RR in the DNS reply to bias the selection through native connectivity. If the Well-Known Prefix is used, the longest prefix match rule will select native connectivity. The problem can be solved by properly configuring theRFC3484 [RFC3484 ] policy table. You can find the full spec at http://tools.ietf.org/html/draft-ietf-behave-dns64-10 Regards, marcelo > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 > "SH1-0151. This is the serial number, of our orbital gun." > From chris at timico.net Thu Sep 2 10:47:00 2010 From: chris at timico.net (Chris Nicholls) Date: Thu, 2 Sep 2010 09:47:00 +0100 Subject: Monitoring IPv6 Message-ID: <20100902084700.GA41728@atsuko> Hello all, Congrats to XS4ALL :) I'm having a hard time finding solid monitoring solutions for our v6 deployment, we currently use a mixture of systems with the dominate being nagios. Does anyone have any light they can shed on monitoring topics. past experience, what has worked well in other deployments, etc... Regards -- Chris Nicholls Timico Network Operations chris at timico.net From jeroen at unfix.org Thu Sep 2 10:50:45 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 02 Sep 2010 10:50:45 +0200 Subject: Monitoring IPv6 In-Reply-To: <20100902084700.GA41728@atsuko> References: <20100902084700.GA41728@atsuko> Message-ID: <4C7F6565.3080501@unfix.org> On 2010-09-02 10:47, Chris Nicholls wrote: > Hello all, > > Congrats to XS4ALL :) > > I'm having a hard time finding solid monitoring solutions for our v6 > deployment, we currently use a mixture of systems with the dominate > being nagios. > > Does anyone have any light they can shed on monitoring topics. past > experience, what has worked well in other deployments, etc... See NANOG for a lot of similar "I want a monitor" questions, and their answers, which either are a list of tools that people like, own, support or sell, or the better answer: what do you want to monitor. Especially as that includes the type of devices/hosts that you want to monitor and what properties of them you want to look at and in which way. In the end you most likely end up either mixing up a bunch of tools or something that you build yourself. Greets, Jeroen From phrickman at upcbroadband.com Thu Sep 2 10:55:58 2010 From: phrickman at upcbroadband.com (Rickman, Phil) Date: Thu, 2 Sep 2010 10:55:58 +0200 Subject: Monitoring IPv6 In-Reply-To: <4C7F6565.3080501@unfix.org> References: <20100902084700.GA41728@atsuko>,<4C7F6565.3080501@unfix.org> Message-ID: would start with smoke ping seems to work well enough as an interim solution Phil ________________________________________ From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Jeroen Massar [jeroen at unfix.org] Sent: 02 September 2010 10:50 To: Chris Nicholls Cc: ipv6-ops at lists.cluenet.de Subject: Re: Monitoring IPv6 On 2010-09-02 10:47, Chris Nicholls wrote: > Hello all, > > Congrats to XS4ALL :) > > I'm having a hard time finding solid monitoring solutions for our v6 > deployment, we currently use a mixture of systems with the dominate > being nagios. > > Does anyone have any light they can shed on monitoring topics. past > experience, what has worked well in other deployments, etc... See NANOG for a lot of similar "I want a monitor" questions, and their answers, which either are a list of tools that people like, own, support or sell, or the better answer: what do you want to monitor. Especially as that includes the type of devices/hosts that you want to monitor and what properties of them you want to look at and in which way. In the end you most likely end up either mixing up a bunch of tools or something that you build yourself. Greets, Jeroen From teun at teun.tv Thu Sep 2 11:27:30 2010 From: teun at teun.tv (Teun Vink) Date: Thu, 02 Sep 2010 11:27:30 +0200 Subject: Monitoring IPv6 In-Reply-To: <20100902084700.GA41728@atsuko> References: <20100902084700.GA41728@atsuko> Message-ID: <1283419650.25222.113.camel@moridin.office.bit.nl.office.bit.nl> On Thu, 2010-09-02 at 09:47 +0100, Chris Nicholls wrote: > Hello all, > > Congrats to XS4ALL :) > > I'm having a hard time finding solid monitoring solutions for our v6 > deployment, we currently use a mixture of systems with the dominate > being nagios. > > Does anyone have any light they can shed on monitoring topics. past > experience, what has worked well in other deployments, etc... > We use nagios for monitoring. For each relevant host and service we check both IPv4 and IPv6 by adding them twice (IP based) to the nagios config. It works fine, though you can get duplicate notifications in some cases. -- Teun From marcoh at marcoh.net Thu Sep 2 13:26:29 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 2 Sep 2010 13:26:29 +0200 Subject: Monitoring IPv6 In-Reply-To: <1283419650.25222.113.camel@moridin.office.bit.nl.office.bit.nl> References: <20100902084700.GA41728@atsuko> <1283419650.25222.113.camel@moridin.office.bit.nl.office.bit.nl> Message-ID: On 2 sep 2010, at 11:27, Teun Vink wrote: > On Thu, 2010-09-02 at 09:47 +0100, Chris Nicholls wrote: >> Hello all, >> >> Congrats to XS4ALL :) >> >> I'm having a hard time finding solid monitoring solutions for our v6 >> deployment, we currently use a mixture of systems with the dominate >> being nagios. >> >> Does anyone have any light they can shed on monitoring topics. past >> experience, what has worked well in other deployments, etc... >> > > We use nagios for monitoring. For each relevant host and service we > check both IPv4 and IPv6 by adding them twice (IP based) to the nagios > config. It works fine, though you can get duplicate notifications in > some cases. Same here, just add them again. Groet, MarcoH From d.bay at rrbone-bb.net Thu Sep 2 14:44:40 2010 From: d.bay at rrbone-bb.net (Dominik Bay) Date: Thu, 2 Sep 2010 14:44:40 +0200 Subject: Motorola Conopy IPv6 Support Message-ID: <20100902144440.438d959d@libelle.kk18.dtm.openap.net> Hi List, did anyone experience problems with IPv6 on Canopy Wireless Equipment? I'm currently using it with IPv4, which is already working fine and want to expand my setup as I'm satisfied with the wireless performance. As far as I can see, it's pure Ethernet Layer2 and the only thing which is not available over IPv6 are the management features. Curious about caveats, Dominik From lists at quux.de Thu Sep 2 14:48:21 2010 From: lists at quux.de (Jens Link) Date: Thu, 02 Sep 2010 14:48:21 +0200 Subject: Monitoring IPv6 In-Reply-To: <1283419650.25222.113.camel@moridin.office.bit.nl.office.bit.nl> (Teun Vink's message of "Thu, 02 Sep 2010 11:27:30 +0200") References: <20100902084700.GA41728@atsuko> <1283419650.25222.113.camel@moridin.office.bit.nl.office.bit.nl> Message-ID: <87mxs0tip6.fsf@oban.berlin.quux.de> Teun Vink writes: > We use nagios for monitoring. For each relevant host and service we > check both IPv4 and IPv6 by adding them twice (IP based) to the nagios > config. It works fine, though you can get duplicate notifications in > some cases. Same here and there is even a patch for Icingas nrpe version to work with IPv6: http://github.com/fobser/icinga-nrpe-ipv6 Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From simon.perreault at viagenie.ca Thu Sep 2 14:06:11 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 02 Sep 2010 08:06:11 -0400 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: <4C7F3795.1070706@it.uc3m.es> References: <4C7F3795.1070706@it.uc3m.es> Message-ID: <4C7F9333.9040100@viagenie.ca> > El 02/09/10 1:42, Brandon Applegate escribi?: >> I really liked the BIND DNS64. Would like to do some more captures to >> see if I can figure out what is making Windows7 unhappy. I'm guessing >> it's the fact that the BIND DNS64 gives back the A record answers as >> well as the synthesized AAAA when the question was only AAAA. Linux >> doesn't seem to care about this. Windows gets tied in a knot >> (initially, subsequent (after cache) queries work). Which version are you using? We fixed this bug on 2009-12-11. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From brandon at burn.net Thu Sep 2 15:28:26 2010 From: brandon at burn.net (Brandon Applegate) Date: Thu, 2 Sep 2010 09:28:26 -0400 (EDT) Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: <4C7F9333.9040100@viagenie.ca> References: <4C7F3795.1070706@it.uc3m.es> <4C7F9333.9040100@viagenie.ca> Message-ID: On Thu, 2 Sep 2010, Simon Perreault wrote: > > Which version are you using? We fixed this bug on 2009-12-11. I'm running ecdysis-bind-9.6.0-P1-20090601.tgz. Looks like that explains it. I will grab the newer package and try out Win7 later tonight. Thanks for the reply and info. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From marc.blanchet at viagenie.ca Thu Sep 2 15:30:35 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Thu, 02 Sep 2010 09:30:35 -0400 Subject: Windows Vista / 7 - pure IPv6 (NATPT) In-Reply-To: References: <4C7F3795.1070706@it.uc3m.es> <4C7F9333.9040100@viagenie.ca> Message-ID: <4C7FA6FB.6070903@viagenie.ca> Le 10-09-02 09:28, Brandon Applegate a ?crit : > On Thu, 2 Sep 2010, Simon Perreault wrote: > >> >> Which version are you using? We fixed this bug on 2009-12-11. > > I'm running ecdysis-bind-9.6.0-P1-20090601.tgz. Looks like that explains > it. I will grab the newer package and try out Win7 later tonight. Thanks > for the reply and info. > suggestion for next time: we have created a -announce mailing list (see web site: http://ecdysis.viagenie.ca) so that when new releases are out, you get to know it. Marc. > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 > "SH1-0151. This is the serial number, of our orbital gun." -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From paul at paulstewart.org Thu Sep 2 15:54:23 2010 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 2 Sep 2010 06:54:23 -0700 Subject: Motorola Conopy IPv6 Support In-Reply-To: <20100902144440.438d959d@libelle.kk18.dtm.openap.net> References: <20100902144440.438d959d@libelle.kk18.dtm.openap.net> Message-ID: <003f01cb4aa6$6000c1c0$20024540$@org> Hi Dominik... I have it running to my house over Canopy 2.4 and haven't noticed anything weird - having said that I'm purely a test case.... We've been pressuring Motorola for over a year now to add it to their management but so far no luck, just "coming in future" Paul -----Original Message----- From: ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de [mailto:ipv6-ops-bounces+paul=paulstewart.org at lists.cluenet.de] On Behalf Of Dominik Bay Sent: Thursday, September 02, 2010 5:45 AM To: ipv6-ops at lists.cluenet.de Subject: Motorola Conopy IPv6 Support Hi List, did anyone experience problems with IPv6 on Canopy Wireless Equipment? I'm currently using it with IPv4, which is already working fine and want to expand my setup as I'm satisfied with the wireless performance. As far as I can see, it's pure Ethernet Layer2 and the only thing which is not available over IPv6 are the management features. Curious about caveats, Dominik From ipv6-ops at c0mplx.org Fri Sep 3 15:48:25 2010 From: ipv6-ops at c0mplx.org (Kurt Jaeger) Date: Fri, 3 Sep 2010 15:48:25 +0200 Subject: UPS with ethernet && ipv6 ? Message-ID: <20100903134825.GY2551@home.opsec.eu> Hi! Does anyone have pointers to IPv6-enabled UPS hardware/vendors ? -- pi at opsec.eu +49 171 3101372 10 years to go ! From ipv6-ops at otoh.org Fri Sep 3 16:39:51 2010 From: ipv6-ops at otoh.org (Paul Armstrong) Date: Fri, 3 Sep 2010 14:39:51 +0000 Subject: UPS with ethernet && ipv6 ? In-Reply-To: <20100903134825.GY2551@home.opsec.eu> References: <20100903134825.GY2551@home.opsec.eu> Message-ID: <20100903143951.GC12857@suricate.otoh.org> At 2010-09-03T15:48+0200, Kurt Jaeger wrote: > Does anyone have pointers to IPv6-enabled UPS hardware/vendors ? I don't know of a full list, but I just purchased an Eaton because they do. http://powerquality.eaton.com/Products-services/Power-Management/Connectivity/ConnectUPS.asp From david at sargasso.net Fri Sep 3 16:57:03 2010 From: david at sargasso.net (David Croft) Date: Fri, 3 Sep 2010 15:57:03 +0100 Subject: UPS with ethernet && ipv6 ? In-Reply-To: <20100903134825.GY2551@home.opsec.eu> References: <20100903134825.GY2551@home.opsec.eu> Message-ID: Recent APC devices (with the new network management card) apparently support IPv6 using the 5.x AOS train. Unfortunately older devices can't be upgraded past 3.x though. http://emea-en.apc.com/app/answers/detail/a_id/8970 David On 3 September 2010 14:48, Kurt Jaeger wrote: > Hi! > > Does anyone have pointers to IPv6-enabled UPS hardware/vendors ? > > -- > pi at opsec.eu ? ? ? ? ? ?+49 171 3101372 ? ? ? ? ? ? ? ? ? ? ? ?10 years to go ! > From dunc at lemonia.org Fri Sep 3 17:14:39 2010 From: dunc at lemonia.org (Dunc) Date: Fri, 03 Sep 2010 16:14:39 +0100 Subject: UPS with ethernet && ipv6 ? In-Reply-To: <20100903134825.GY2551@home.opsec.eu> References: <20100903134825.GY2551@home.opsec.eu> Message-ID: <4C8110DF.9020101@lemonia.org> On 03/09/10 14:48, Kurt Jaeger wrote: > Hi! > > Does anyone have pointers to IPv6-enabled UPS hardware/vendors ? > Our Riello ones have v6 support. Cheers, Dunc From ron at spawar.navy.mil Fri Sep 3 21:12:18 2010 From: ron at spawar.navy.mil (Ron Broersma) Date: Fri, 3 Sep 2010 12:12:18 -0700 Subject: UPS with ethernet && ipv6 ? In-Reply-To: References: <20100903134825.GY2551@home.opsec.eu> Message-ID: <0570E6F6-799E-46E1-90DF-9DDB99495CA6@spawar.navy.mil> We recently bought a lot of the APC units specifically because of the IPv6 support, since our management network is trying to be IPv6-only. They work pretty well, but we did have a number of problems at first, related to (im)maturity of the IPv6 implementation. They have been very supportive of addressing our issues, so we are happy with them. --Ron On Sep 3, 2010, at 7:57 AM, David Croft wrote: > Recent APC devices (with the new network management card) apparently > support IPv6 using the 5.x AOS train. Unfortunately older devices > can't be upgraded past 3.x though. > > http://emea-en.apc.com/app/answers/detail/a_id/8970 > > David > > On 3 September 2010 14:48, Kurt Jaeger wrote: >> Hi! >> >> Does anyone have pointers to IPv6-enabled UPS hardware/vendors ? >> >> -- >> pi at opsec.eu +49 171 3101372 10 years to go ! >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100903/6abad270/attachment.bin From devon at noved.org Thu Sep 9 23:18:14 2010 From: devon at noved.org (Devon True) Date: Thu, 09 Sep 2010 17:18:14 -0400 Subject: Addressing Plans -- Bottom-up? Message-ID: <4C894F16.1010007@noved.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All: Talking with a co-worker about our IPv6 addressing plan and he mentioned reading about some providers starting at the end of their /32 rather than the beginning. I did some Google searching and reading through this list's archives, but could not find anyone talking about that. Is anyone addressing from the "bottom-up"? The approaches I saw were "top-down". - -- Devon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJTxYACgkQWP2WrBTHBS+1GgCfbCu9xtWj+rgqd5/DphqsJUFi BP8AoNCCG6i8qwJvD4ys54xtPHdJe0xD =oslE -----END PGP SIGNATURE----- From gert at space.net Thu Sep 9 23:26:43 2010 From: gert at space.net (Gert Doering) Date: Thu, 9 Sep 2010 23:26:43 +0200 Subject: Addressing Plans -- Bottom-up? In-Reply-To: <4C894F16.1010007@noved.org> References: <4C894F16.1010007@noved.org> Message-ID: <20100909212643.GL74702@Space.Net> Hi, On Thu, Sep 09, 2010 at 05:18:14PM -0400, Devon True wrote: > Talking with a co-worker about our IPv6 addressing plan and he mentioned > reading about some providers starting at the end of their /32 rather > than the beginning. I did some Google searching and reading through this > list's archives, but could not find anyone talking about that. Is anyone > addressing from the "bottom-up"? The approaches I saw were "top-down". We do "all across the place"... :-) It really depends on the structure of your network. If you have many POPs and don't know how much address space each individual POP is going to need, and POPs keep getting added all the time, you want something like the "binary chop" algorithm, helping per-POP aggregation. If your network is fairly static, just distribute your /32 (or whatever) to your pops, like "a /36 for each of my 10 POPs, keeping 6 in reserve", and then assign linearily in there - bottom-up, top-down, whatever you gives you a warm and fuzzy feeling... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Sep 9 23:50:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 10 Sep 2010 07:20:41 +0930 Subject: Addressing Plans -- Bottom-up? In-Reply-To: <4C894F16.1010007@noved.org> References: <4C894F16.1010007@noved.org> Message-ID: <20100910072041.5e410027@opy.nosense.org> On Thu, 09 Sep 2010 17:18:14 -0400 Devon True wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All: > > Talking with a co-worker about our IPv6 addressing plan and he mentioned > reading about some providers starting at the end of their /32 rather > than the beginning. > I did some Google searching and reading through this > list's archives, but could not find anyone talking about that. Is anyone > addressing from the "bottom-up"? The approaches I saw were "top-down". > What did your co-worker say when you asked them why they were doing that or where did he or she read about it? > - -- > Devon > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkyJTxYACgkQWP2WrBTHBS+1GgCfbCu9xtWj+rgqd5/DphqsJUFi > BP8AoNCCG6i8qwJvD4ys54xtPHdJe0xD > =oslE > -----END PGP SIGNATURE----- From surfer at mauigateway.com Fri Sep 10 00:46:35 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 9 Sep 2010 15:46:35 -0700 Subject: Addressing Plans -- Bottom-up? Message-ID: <20100909154635.EECCE19A@resin06.mta.everyone.net> --- devon at noved.org wrote: From: Devon True Talking with a co-worker about our IPv6 addressing plan and he mentioned reading about some providers starting at the end of their /32 rather than the beginning. I did some Google searching and reading through this list's archives, but could not find anyone talking about that. Is anyone addressing from the "bottom-up"? The approaches I saw were "top-down". ------------------------------------------------- One thing to think about is the allocations that may be reserved for you. Here in ARINland we got a /32 and the following two other /32s were reserved. If you take blocks out that you want to reserve for testing and you do it from the end of the /32, they become the middle of the block when you get the neighboring space. <--- /32 ---> <--- /32 ---> <--- /32 ---> ^ ^ | | reserved customers in reserved for 'stuff' the middle for 'stuff' scott From pnl at ielo.net Fri Sep 10 11:14:17 2010 From: pnl at ielo.net (Bertrand Yvain) Date: Fri, 10 Sep 2010 11:14:17 +0200 Subject: Addressing Plans -- Bottom-up? In-Reply-To: <20100909212643.GL74702@Space.Net> References: <4C894F16.1010007@noved.org> <20100909212643.GL74702@Space.Net> Message-ID: <20100910091417.GV2465@nexus6.adm.ielo.net> Hi, On Thu, Sep 09, 2010 at 11:26:43PM +0200, Gert Doering wrote: > It really depends on the structure of your network. If you have many > POPs and don't know how much address space each individual POP is going > to need, and POPs keep getting added all the time, you want something > like the "binary chop" algorithm, helping per-POP aggregation. This "binary chop" algorithm, or sparse allocation, is (notably) described here: http://www.ripe.net/docs/ipv6-sparse.html -- Bertrand Yvain http://www.IELO.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100910/48646d0e/attachment.bin From huggie at earth.li Fri Sep 10 16:02:49 2010 From: huggie at earth.li (Simon Huggins) Date: Fri, 10 Sep 2010 15:02:49 +0100 Subject: Egress of multiple machines through one IP Message-ID: <20100910140249.GD24304@paranoidfreak.co.uk> It's been a few years since I used IPv6 for real but new work are about to look at it. Previously, I was part of an ISP that provided ADSL, dialup, colo and some of our own services over v6 so I have been helping give them some ideas for our v6 deployment. I do have one problem that has me stumped though. We run lots of web proxies with multiple nodes. We should be able to do the ingress load balancing in a similar way to v4 though I'm a little unclear on the implications of neighbour discovery here. But I have an issue with egrees. We proxy web traffic so we want every outgoing request to come from the same IP. We know from experience that some websites that are security conscious will reject sessions that don't continue to come from the same IP to prevent session stealing. In v4 this is easy; we just have a nat pool and everything comes from the egress IP we've assigned to that group of servers. In v6 I... can't think of a way we can do it without introducing some sort of application proxy between our servers and the websites which would be the single point of failure we were trying to avoid. We could try with different public addresses on each server but there's no guarantee at the moment that a users' browser will keep going through the same server (it might be taken out of service for upgrades or be overloaded or die etc). I'm fairly sure we'd hit the "session from different IP is bogus" issue. Noone does do v6 NAT for this (possibly edge) use case do they? Anyone any other good ideas? Simon. -- oOoOo "The Abbots... charming couple" - Basil "Yes. All three of oOoOo oOoOo them." - Sybil, Fawlty Towers. oOoOo oOoOo oOoOo htag.pl 0.0.24 ::::::: http://www.earth.li/~huggie/ From md at Linux.IT Fri Sep 10 16:36:29 2010 From: md at Linux.IT (Marco d'Itri) Date: Fri, 10 Sep 2010 16:36:29 +0200 Subject: Egress of multiple machines through one IP In-Reply-To: <20100910140249.GD24304@paranoidfreak.co.uk> References: <20100910140249.GD24304@paranoidfreak.co.uk> Message-ID: <20100910143629.GA9084@bongo.bofh.it> On Sep 10, Simon Huggins wrote: > Anyone any other good ideas? Two redundant load balancers with sticky sessions in front of the proxies, then the outgoing IP will not matter anymore. You can easily install LVS on two of the proxy nodes, its CPU usage is negligible (but you will need a recent kernel for IPv6 support). -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100910/b5199162/attachment.bin From fernando at gont.com.ar Fri Sep 10 22:22:08 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 10 Sep 2010 17:22:08 -0300 Subject: List of Teredo servers and teredo relays Message-ID: <4C8A9370.2050905@gont.com.ar> Hi, folks, Does any body maintain a list of Teredo servers and Teredo relays? Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Fri Sep 10 22:36:52 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 10 Sep 2010 17:36:52 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? Message-ID: <4C8A96E4.1050101@gont.com.ar> Hi, I'm told that in some scenarios, IPv6 operates over link-layers that do not provide an MTU gretear than or equal to 1280 bytes (the IPv6 required minimum MTU). Has anybody seen such a thing? P.S.: Yes, I'm aware of what RFC 2460 requires. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bmanning at vacation.karoshi.com Fri Sep 10 23:35:58 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 10 Sep 2010 21:35:58 +0000 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8A96E4.1050101@gont.com.ar> References: <4C8A96E4.1050101@gont.com.ar> Message-ID: <20100910213558.GB476@vacation.karoshi.com.> yes - we see MTUs of 1220 with some regularity. --bill On Fri, Sep 10, 2010 at 05:36:52PM -0300, Fernando Gont wrote: > Hi, > > I'm told that in some scenarios, IPv6 operates over link-layers that do > not provide an MTU gretear than or equal to 1280 bytes (the IPv6 > required minimum MTU). > > Has anybody seen such a thing? > > P.S.: Yes, I'm aware of what RFC 2460 requires. > > Thanks, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From fernando at gont.com.ar Fri Sep 10 23:40:19 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 10 Sep 2010 18:40:19 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100910213558.GB476@vacation.karoshi.com.> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> Message-ID: <4C8AA5C3.405@gont.com.ar> Hi, Bill, Thanks so much for your response. Just to double-check: is this the actual MTU, or do you infer such MTU as a result of he advertised TCP MSS option? Thanks! Fernando bmanning at vacation.karoshi.com wrote: > yes - we see MTUs of 1220 with some regularity. > > --bill > > > On Fri, Sep 10, 2010 at 05:36:52PM -0300, Fernando Gont wrote: >> Hi, >> >> I'm told that in some scenarios, IPv6 operates over link-layers that do >> not provide an MTU gretear than or equal to 1280 bytes (the IPv6 >> required minimum MTU). >> >> Has anybody seen such a thing? >> >> P.S.: Yes, I'm aware of what RFC 2460 requires. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando at gont.com.ar || fgont at acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> > -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bmanning at vacation.karoshi.com Sat Sep 11 02:49:19 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 11 Sep 2010 00:49:19 +0000 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8AA5C3.405@gont.com.ar> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> Message-ID: <20100911004919.GB963@vacation.karoshi.com.> i will admit to truting what my tools tell me, and they report an MTU of 1220. It appears to be from a single vendors kit. --bill On Fri, Sep 10, 2010 at 06:40:19PM -0300, Fernando Gont wrote: > Hi, Bill, > > Thanks so much for your response. Just to double-check: is this the > actual MTU, or do you infer such MTU as a result of he advertised TCP > MSS option? > > Thanks! > > Fernando > > > > > bmanning at vacation.karoshi.com wrote: > > yes - we see MTUs of 1220 with some regularity. > > > > --bill > > > > > > On Fri, Sep 10, 2010 at 05:36:52PM -0300, Fernando Gont wrote: > >> Hi, > >> > >> I'm told that in some scenarios, IPv6 operates over link-layers that do > >> not provide an MTU gretear than or equal to 1280 bytes (the IPv6 > >> required minimum MTU). > >> > >> Has anybody seen such a thing? > >> > >> P.S.: Yes, I'm aware of what RFC 2460 requires. > >> > >> Thanks, > >> -- > >> Fernando Gont > >> e-mail: fernando at gont.com.ar || fgont at acm.org > >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >> > >> > >> > >> > > > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > From gert at space.net Sat Sep 11 21:09:06 2010 From: gert at space.net (Gert Doering) Date: Sat, 11 Sep 2010 21:09:06 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8A96E4.1050101@gont.com.ar> References: <4C8A96E4.1050101@gont.com.ar> Message-ID: <20100911190906.GP74702@Space.Net> Hi, On Fri, Sep 10, 2010 at 05:36:52PM -0300, Fernando Gont wrote: > I'm told that in some scenarios, IPv6 operates over link-layers that do > not provide an MTU gretear than or equal to 1280 bytes (the IPv6 > required minimum MTU). There seems to be quite some misunderstandings about link-layers like ATM or X.25 that have a smaller segment size - but since those layers do layer 2 segmentation/reassembly without the need of a reduced IP/IPv6 MTU, I don't see a problem there. So if there's indeed link-layers that cannot handle 1280, I'd also like to know more details :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Sat Sep 11 21:09:52 2010 From: gert at space.net (Gert Doering) Date: Sat, 11 Sep 2010 21:09:52 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100911004919.GB963@vacation.karoshi.com.> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> Message-ID: <20100911190952.GQ74702@Space.Net> Hi, On Sat, Sep 11, 2010 at 12:49:19AM +0000, bmanning at vacation.karoshi.com wrote: > i will admit to truting what my tools tell me, and > they report an MTU of 1220. It appears to be from a > single vendors kit. Is that due to a broken implementation, or due to actual link-layer technology that cannot handle more than 1220? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From bmanning at vacation.karoshi.com Sun Sep 12 07:51:22 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 12 Sep 2010 05:51:22 +0000 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100911190952.GQ74702@Space.Net> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> Message-ID: <20100912055122.GA12452@vacation.karoshi.com.> On Sat, Sep 11, 2010 at 09:09:52PM +0200, Gert Doering wrote: > Hi, > > On Sat, Sep 11, 2010 at 12:49:19AM +0000, bmanning at vacation.karoshi.com wrote: > > i will admit to truting what my tools tell me, and > > they report an MTU of 1220. It appears to be from a > > single vendors kit. > > Is that due to a broken implementation, or due to actual link-layer > technology that cannot handle more than 1220? are these two different? --bill > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 155817 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From lucab at debian.org Fri Sep 10 22:30:09 2010 From: lucab at debian.org (Luca Bruno) Date: Fri, 10 Sep 2010 22:30:09 +0200 Subject: List of Teredo servers and teredo relays In-Reply-To: <4C8A9370.2050905@gont.com.ar> References: <4C8A9370.2050905@gont.com.ar> Message-ID: <20100910223009.df2a6816.lucab@debian.org> Fernando Gont scrisse: > Hi, folks, > Does any body maintain a list of Teredo servers and Teredo relays? With regards to relays, you may want to start looking at http://bgpmon.net/teredo.php Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S. | lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100910/a2a462bc/attachment.bin From marcoh at marcoh.net Sun Sep 12 12:44:05 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 12 Sep 2010 12:44:05 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100912055122.GA12452@vacation.karoshi.com.> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> Message-ID: <45F6C995-B8D2-42A8-947C-1ABF05CCFB61@marcoh.net> On 12 sep 2010, at 07:51, bmanning at vacation.karoshi.com wrote: > On Sat, Sep 11, 2010 at 09:09:52PM +0200, Gert Doering wrote: >> Hi, >> >> On Sat, Sep 11, 2010 at 12:49:19AM +0000, bmanning at vacation.karoshi.com wrote: >>> i will admit to truting what my tools tell me, and >>> they report an MTU of 1220. It appears to be from a >>> single vendors kit. >> >> Is that due to a broken implementation, or due to actual link-layer >> technology that cannot handle more than 1220? > > are these two different? Is it really the MTU or do they report payload ? MarcoH From gert at space.net Sun Sep 12 13:56:14 2010 From: gert at space.net (Gert Doering) Date: Sun, 12 Sep 2010 13:56:14 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100912055122.GA12452@vacation.karoshi.com.> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> Message-ID: <20100912115614.GR74702@Space.Net> Hi, On Sun, Sep 12, 2010 at 05:51:22AM +0000, bmanning at vacation.karoshi.com wrote: > On Sat, Sep 11, 2010 at 09:09:52PM +0200, Gert Doering wrote: > > On Sat, Sep 11, 2010 at 12:49:19AM +0000, bmanning at vacation.karoshi.com wrote: > > > i will admit to truting what my tools tell me, and > > > they report an MTU of 1220. It appears to be from a > > > single vendors kit. > > > > Is that due to a broken implementation, or due to actual link-layer > > technology that cannot handle more than 1220? > > are these two different? Yes. Broken implementations can be fixed or replaced by a different vendor's working implementation. Technology that cannot do larger MTUs because of the way the technology is specified (imagine ATM without SAR at the VC endpoints) cannot be fixed without changing standards, upgrading lots of different vendor implementations, etc. Just to spell out why I think there is a difference :-) - in the specific moment in time "I want to transfer a packet now and it does not go through", there is no effective difference, of course. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100912/7f64470d/attachment.bin From fernando at gont.com.ar Sun Sep 12 21:01:42 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 12 Sep 2010 16:01:42 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100911004919.GB963@vacation.karoshi.com.> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> Message-ID: <4C8D2396.8050605@gont.com.ar> Hi, Bill, COmments inline... bmanning at vacation.karoshi.com wrote: > i will admit to truting what my tools tell me, and > they report an MTU of 1220. It appears to be from a > single vendors kit. Ok, put another way: what's the mechanism these tools use to report such MTUs? I'm wondering if the reported MTUs correspond to link-layers that cannot convey packets of 1280 bytes, or e.g. they are reporting "errors" because they want your node to include a fragmentation header (but would nevertheless *be* able to convery a packet of 1280 bytes), or maybe the tool is inferring the MTU from the TCP MSS options. -- These two things are different from a real link MTU smaller than 1280 bytes. Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fred at cisco.com Sun Sep 12 22:00:09 2010 From: fred at cisco.com (Fred Baker) Date: Sun, 12 Sep 2010 13:00:09 -0700 Subject: draft-ietf-v6ops-incremental-cgn WGLC Message-ID: <47B501FE-B7AA-4028-99BD-FAB1D6F181C1@cisco.com> The IETF IPv6 Operations Working Group is initiating a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, Brian Carpenter, 18-Jun-10 This is in essence a discussion of the use of IPv4/IPv4 Carrier Grade Network Address Translation to keep an operator's IPv4 network running while they deploy or finish deploying IPv6 and until their customers are heavily using IPv6. If you find issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to v6ops at ietf.org. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100912/4c8df774/attachment.html From brian.e.carpenter at gmail.com Sun Sep 12 22:40:12 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 13 Sep 2010 08:40:12 +1200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100912115614.GR74702@Space.Net> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> Message-ID: <4C8D3AAC.9000003@gmail.com> Gert On 2010-09-12 23:56, Gert Doering wrote: > Hi, > > On Sun, Sep 12, 2010 at 05:51:22AM +0000, bmanning at vacation.karoshi.com wrote: >> On Sat, Sep 11, 2010 at 09:09:52PM +0200, Gert Doering wrote: >>> On Sat, Sep 11, 2010 at 12:49:19AM +0000, bmanning at vacation.karoshi.com wrote: >>>> i will admit to truting what my tools tell me, and >>>> they report an MTU of 1220. It appears to be from a >>>> single vendors kit. >>> Is that due to a broken implementation, or due to actual link-layer >>> technology that cannot handle more than 1220? >> are these two different? > > Yes. Broken implementations can be fixed or replaced by a different > vendor's working implementation. > > Technology that cannot do larger MTUs because of the way the technology > is specified (imagine ATM without SAR at the VC endpoints) cannot be > fixed without changing standards, upgrading lots of different vendor > implementations, etc. What's supposed to happen then is that the logical link layer handles fragmentation as a link layer (or maybe layer 2.5) function, so that the IPv6 layer still sees at least 1280. > Just to spell out why I think there is a difference :-) - in the specific > moment in time "I want to transfer a packet now and it does not go through", > there is no effective difference, of course. Indeed not. Brian > > Gert Doering > -- NetMaster From fernando at gont.com.ar Sun Sep 12 23:02:50 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 12 Sep 2010 18:02:50 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8D3AAC.9000003@gmail.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> Message-ID: <4C8D3FFA.2020309@gont.com.ar> Brian E Carpenter wrote: >> Technology that cannot do larger MTUs because of the way the technology >> is specified (imagine ATM without SAR at the VC endpoints) cannot be >> fixed without changing standards, upgrading lots of different vendor >> implementations, etc. > > What's supposed to happen then is that the logical link layer handles > fragmentation as a link layer (or maybe layer 2.5) function, so that > the IPv6 layer still sees at least 1280. I am told there are technologies for which IPv6 does not see at least 1280 bytes -- hence the original question, and the request for details about how bill manning found such <1280 MTUs. Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gert at space.net Mon Sep 13 08:20:15 2010 From: gert at space.net (Gert Doering) Date: Mon, 13 Sep 2010 08:20:15 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8D3AAC.9000003@gmail.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> Message-ID: <20100913062015.GS74702@Space.Net> Hi, On Mon, Sep 13, 2010 at 08:40:12AM +1200, Brian E Carpenter wrote: > > Technology that cannot do larger MTUs because of the way the technology > > is specified (imagine ATM without SAR at the VC endpoints) cannot be > > fixed without changing standards, upgrading lots of different vendor > > implementations, etc. > > What's supposed to happen then is that the logical link layer handles > fragmentation as a link layer (or maybe layer 2.5) function, so that > the IPv6 layer still sees at least 1280. Yes - which is, specifically, why I'm asking whether technology is out there today that has "small MTU" limitations but at the same time does not provide L2 (L2.5) segmentation and reassembly. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100913/ec993c72/attachment.bin From fred at cisco.com Mon Sep 13 15:26:21 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 13 Sep 2010 06:26:21 -0700 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100913062015.GS74702@Space.Net> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> Message-ID: <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> On Sep 12, 2010, at 11:20 PM, Gert Doering wrote: > Hi, > > On Mon, Sep 13, 2010 at 08:40:12AM +1200, Brian E Carpenter wrote: >>> Technology that cannot do larger MTUs because of the way the technology >>> is specified (imagine ATM without SAR at the VC endpoints) cannot be >>> fixed without changing standards, upgrading lots of different vendor >>> implementations, etc. >> >> What's supposed to happen then is that the logical link layer handles >> fragmentation as a link layer (or maybe layer 2.5) function, so that >> the IPv6 layer still sees at least 1280. > > Yes - which is, specifically, why I'm asking whether technology is out > there today that has "small MTU" limitations but at the same time does not > provide L2 (L2.5) segmentation and reassembly. IEEE 802.15.4-2006 (133 octets, part of which is an ethernet-like header and trailer) is an example. In March, 802.15.4g added options to increase the size to 2047 bytes and include a four byte CRC, which is a good thing, but up until recently we have been looking at very small frames. To be honest, I'm not sure what L2, apart from ATM, *does* provide L2 segmentation and reassembly. Certainly not anything from CCITT (anything HDLC-based) or IEEE 802. > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 155817 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Mon Sep 13 15:32:57 2010 From: gert at space.net (Gert Doering) Date: Mon, 13 Sep 2010 15:32:57 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> Message-ID: <20100913133257.GB74702@Space.Net> Hi, On Mon, Sep 13, 2010 at 06:26:21AM -0700, Fred Baker wrote: > > Yes - which is, specifically, why I'm asking whether technology is out > > there today that has "small MTU" limitations but at the same time does not > > provide L2 (L2.5) segmentation and reassembly. > > IEEE 802.15.4-2006 (133 octets, part of which is an ethernet-like > header and trailer) is an example. In March, 802.15.4g added options > to increase the size to 2047 bytes and include a four byte CRC, > which is a good thing, but up until recently we have been looking > at very small frames. Thanks. So how do people adapt IPv6 to 802.15.4-2006? > To be honest, I'm not sure what L2, apart from ATM, *does* provide L2 > segmentation and reassembly. Certainly not anything from CCITT X.25 :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 155817 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100913/b857553a/attachment.bin From fred at cisco.com Mon Sep 13 15:43:26 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 13 Sep 2010 06:43:26 -0700 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <20100913133257.GB74702@Space.Net> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> Message-ID: <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> On Sep 13, 2010, at 6:32 AM, Gert Doering wrote: > Hi, > > On Mon, Sep 13, 2010 at 06:26:21AM -0700, Fred Baker wrote: >>> Yes - which is, specifically, why I'm asking whether technology is out >>> there today that has "small MTU" limitations but at the same time does not >>> provide L2 (L2.5) segmentation and reassembly. >> >> IEEE 802.15.4-2006 (133 octets, part of which is an ethernet-like >> header and trailer) is an example. In March, 802.15.4g added options >> to increase the size to 2047 bytes and include a four byte CRC, >> which is a good thing, but up until recently we have been looking >> at very small frames. > > Thanks. So how do people adapt IPv6 to 802.15.4-2006? They're using PMTU. On the local side you can know that it is 802.15.4 and set a TCP MSS very small, but unless one side does that the other has no way to detect the problem apart from PMTU. >> To be honest, I'm not sure what L2, apart from ATM, *does* provide L2 >> segmentation and reassembly. Certainly not anything from CCITT > > X.25 :-) Well, not really. X.25 PLP isn't link layer; that's the LAPB layer. But you are correct that X.25's PLP can provide what amounts to an octet stream for its user, which may be an octet stream for the upper layer's entire transmission or only for payload messages. From fernando at gont.com.ar Mon Sep 13 16:39:40 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 13 Sep 2010 11:39:40 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> Message-ID: <4C8E37AC.2040808@gont.com.ar> Hi, Fred, >> Thanks. So how do people adapt IPv6 to 802.15.4-2006? > > They're using PMTU. On the local side you can know that it is > 802.15.4 and set a TCP MSS very small, but unless one side does that > the other has no way to detect the problem apart from PMTU. Just double checking: So... these link layers do not support MTUs of 1280 bytes? e.g., what if the flow does not implement PMTUD? FWIW, I'm just trying to figure out if, when receiving an ICMP PTB that advertises a Next-Hop MTU smaller than 1280, it is really safe to *not* fragment the original packet in fragments of (at most) the advertised MTU. If there are link layers that do not support an MTU of 1280 bytes then, despite of what RFC 2460 requires, one may need to be more careful in this case, as sticking to 1280-byte packets may result in interoperability problems. Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fred at cisco.com Mon Sep 13 17:58:53 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 13 Sep 2010 08:58:53 -0700 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8E37AC.2040808@gont.com.ar> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> Message-ID: <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: > Hi, Fred, > >>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >> >> They're using PMTU. On the local side you can know that it is >> 802.15.4 and set a TCP MSS very small, but unless one side does that >> the other has no way to detect the problem apart from PMTU. > > Just double checking: So... these link layers do not support MTUs of > 1280 bytes? > > e.g., what if the flow does not implement PMTUD? > > FWIW, I'm just trying to figure out if, when receiving an ICMP PTB that > advertises a Next-Hop MTU smaller than 1280, it is really safe to *not* > fragment the original packet in fragments of (at most) the advertised MTU. > > If there are link layers that do not support an MTU of 1280 bytes then, > despite of what RFC 2460 requires, one may need to be more careful in > this case, as sticking to 1280-byte packets may result in > interoperability problems. duh. :-) If you get a message back telling you to fragment to 50 bytes, I'd suggest you do so. From rdroms at cisco.com Mon Sep 13 18:00:46 2010 From: rdroms at cisco.com (Ralph Droms) Date: Mon, 13 Sep 2010 18:00:46 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> Message-ID: <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> Just to be clear - the 6lowpan adaptation layer for IPv6-over-802.15.4 does define its own fragmentation, which should appear to provide an MTU of 1280 to IPv6. - Ralph On Sep 13, 2010, at 5:58 PM 9/13/10, Fred Baker wrote: > > On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: > >> Hi, Fred, >> >>>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >>> >>> They're using PMTU. On the local side you can know that it is >>> 802.15.4 and set a TCP MSS very small, but unless one side does that >>> the other has no way to detect the problem apart from PMTU. >> >> Just double checking: So... these link layers do not support MTUs of >> 1280 bytes? >> >> e.g., what if the flow does not implement PMTUD? >> >> FWIW, I'm just trying to figure out if, when receiving an ICMP PTB that >> advertises a Next-Hop MTU smaller than 1280, it is really safe to *not* >> fragment the original packet in fragments of (at most) the advertised MTU. >> >> If there are link layers that do not support an MTU of 1280 bytes then, >> despite of what RFC 2460 requires, one may need to be more careful in >> this case, as sticking to 1280-byte packets may result in >> interoperability problems. > > duh. :-) > > If you get a message back telling you to fragment to 50 bytes, I'd suggest you do so. From fred at cisco.com Mon Sep 13 18:18:12 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 13 Sep 2010 09:18:12 -0700 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> Message-ID: On Sep 13, 2010, at 9:00 AM, Ralph Droms wrote: > Just to be clear - the 6lowpan adaptation layer for IPv6-over-802.15.4 does define its own fragmentation, which should appear to provide an MTU of 1280 to IPv6. OK, that's true. Of course, if the March change to 802.15.4g stays, that (and 6lowpan?) may no longer be needed. > - Ralph > > On Sep 13, 2010, at 5:58 PM 9/13/10, Fred Baker wrote: > >> >> On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: >> >>> Hi, Fred, >>> >>>>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >>>> >>>> They're using PMTU. On the local side you can know that it is >>>> 802.15.4 and set a TCP MSS very small, but unless one side does that >>>> the other has no way to detect the problem apart from PMTU. >>> >>> Just double checking: So... these link layers do not support MTUs of >>> 1280 bytes? >>> >>> e.g., what if the flow does not implement PMTUD? >>> >>> FWIW, I'm just trying to figure out if, when receiving an ICMP PTB that >>> advertises a Next-Hop MTU smaller than 1280, it is really safe to *not* >>> fragment the original packet in fragments of (at most) the advertised MTU. >>> >>> If there are link layers that do not support an MTU of 1280 bytes then, >>> despite of what RFC 2460 requires, one may need to be more careful in >>> this case, as sticking to 1280-byte packets may result in >>> interoperability problems. >> >> duh. :-) >> >> If you get a message back telling you to fragment to 50 bytes, I'd suggest you do so. > From rdroms at cisco.com Mon Sep 13 18:27:06 2010 From: rdroms at cisco.com (Ralph Droms (rdroms)) Date: Mon, 13 Sep 2010 18:27:06 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> Message-ID: <98A599DB-A899-48B7-9B8B-8D10FC5B8D5B@cisco.com> ... At least not for future devices. There is significant demand for IPv6 over 802.15.4 devices already deployed. On Sep 13, 2010, at 6:18 PM, "Fred Baker" wrote: > > On Sep 13, 2010, at 9:00 AM, Ralph Droms wrote: > >> Just to be clear - the 6lowpan adaptation layer for IPv6-over-802.15.4 does define its own fragmentation, which should appear to provide an MTU of 1280 to IPv6. > > OK, that's true. Of course, if the March change to 802.15.4g stays, that (and 6lowpan?) may no longer be needed. > >> - Ralph >> >> On Sep 13, 2010, at 5:58 PM 9/13/10, Fred Baker wrote: >> >>> >>> On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: >>> >>>> Hi, Fred, >>>> >>>>>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >>>>> >>>>> They're using PMTU. On the local side you can know that it is >>>>> 802.15.4 and set a TCP MSS very small, but unless one side does that >>>>> the other has no way to detect the problem apart from PMTU. >>>> >>>> Just double checking: So... these link layers do not support MTUs of >>>> 1280 bytes? >>>> >>>> e.g., what if the flow does not implement PMTUD? >>>> >>>> FWIW, I'm just trying to figure out if, when receiving an ICMP PTB that >>>> advertises a Next-Hop MTU smaller than 1280, it is really safe to *not* >>>> fragment the original packet in fragments of (at most) the advertised MTU. >>>> >>>> If there are link layers that do not support an MTU of 1280 bytes then, >>>> despite of what RFC 2460 requires, one may need to be more careful in >>>> this case, as sticking to 1280-byte packets may result in >>>> interoperability problems. >>> >>> duh. :-) >>> >>> If you get a message back telling you to fragment to 50 bytes, I'd suggest you do so. >> > From fernando at gont.com.ar Mon Sep 13 23:23:22 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 13 Sep 2010 18:23:22 -0300 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> Message-ID: <4C8E964A.2000901@gont.com.ar> Hi, Ralph, Does 802.15.4 predate 6lowpan? Put another way: maybe there are deployments of IPv6 (no 6lowpan) over 802.15.4? Thanks! Kind regards, Fernando Ralph Droms wrote: > Just to be clear - the 6lowpan adaptation layer for > IPv6-over-802.15.4 does define its own fragmentation, which should > appear to provide an MTU of 1280 to IPv6. > > - Ralph > > On Sep 13, 2010, at 5:58 PM 9/13/10, Fred Baker wrote: > >> On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: >> >>> Hi, Fred, >>> >>>>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >>>> They're using PMTU. On the local side you can know that it is >>>> 802.15.4 and set a TCP MSS very small, but unless one side does >>>> that the other has no way to detect the problem apart from >>>> PMTU. >>> Just double checking: So... these link layers do not support MTUs >>> of 1280 bytes? >>> >>> e.g., what if the flow does not implement PMTUD? >>> >>> FWIW, I'm just trying to figure out if, when receiving an ICMP >>> PTB that advertises a Next-Hop MTU smaller than 1280, it is >>> really safe to *not* fragment the original packet in fragments of >>> (at most) the advertised MTU. >>> >>> If there are link layers that do not support an MTU of 1280 bytes >>> then, despite of what RFC 2460 requires, one may need to be more >>> careful in this case, as sticking to 1280-byte packets may result >>> in interoperability problems. >> duh. :-) >> >> If you get a message back telling you to fragment to 50 bytes, I'd >> suggest you do so. > > -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cb.list6 at gmail.com Tue Sep 14 04:17:02 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 13 Sep 2010 19:17:02 -0700 Subject: T-Mobile USA IPv6 Beta Message-ID: Sorry to folks who might have seen this before on other lists, but it was suggested to me that this list may be interested as well. T-Mobile USA has launched an IPv6 beta with Nokia phones. The service is IPv6-only + NAT64 / DNS64. The beta service has been up for over 6 months with positive feedback. Here are some associated links: >From forums.t-mobile.com http://bit.ly/9s0Ed3 >From talk.maemo.org for the N900 users http://bit.ly/9i7Q3P And, finally this is the Google group that you can use to track announcements and sign up http://groups.google.com/group/tmoipv6beta Best regards, Cameron From rdroms at cisco.com Tue Sep 14 09:11:02 2010 From: rdroms at cisco.com (Ralph Droms) Date: Tue, 14 Sep 2010 09:11:02 +0200 Subject: IPv6 MTUs smaller than 1280 bytes? In-Reply-To: <4C8E964A.2000901@gont.com.ar> References: <4C8A96E4.1050101@gont.com.ar> <20100910213558.GB476@vacation.karoshi.com.> <4C8AA5C3.405@gont.com.ar> <20100911004919.GB963@vacation.karoshi.com.> <20100911190952.GQ74702@Space.Net> <20100912055122.GA12452@vacation.karoshi.com.> <20100912115614.GR74702@Space.Net> <4C8D3AAC.9000003@gmail.com> <20100913062015.GS74702@Space.Net> <46B5FE3D-4F94-4676-A2A4-12F604301E1E@cisco.com> <20100913133257.GB74702@Space.Net> <15CE4772-72CD-4925-A413-90FE32CDA6D1@cisco.com> <4C8E37AC.2040808@gont.com.ar> <403808EB-94D8-4905-A1BC-407A5F67A9B0@cisco.com> <57634636-CAB1-47F9-97E4-6F48691BA945@cisco.com> <4C8E964A.2000901@gont.com.ar> Message-ID: As far as I know, the 6lowpan adaptation layer is the first definition of IPv6-over-802.15.4 - Ralph On Sep 13, 2010, at 11:23 PM 9/13/10, Fernando Gont wrote: > Hi, Ralph, > > Does 802.15.4 predate 6lowpan? Put another way: maybe there are > deployments of IPv6 (no 6lowpan) over 802.15.4? > > Thanks! > > Kind regards, > Fernando > > > > > Ralph Droms wrote: >> Just to be clear - the 6lowpan adaptation layer for >> IPv6-over-802.15.4 does define its own fragmentation, which should >> appear to provide an MTU of 1280 to IPv6. >> >> - Ralph >> >> On Sep 13, 2010, at 5:58 PM 9/13/10, Fred Baker wrote: >> >>> On Sep 13, 2010, at 7:39 AM, Fernando Gont wrote: >>> >>>> Hi, Fred, >>>> >>>>>> Thanks. So how do people adapt IPv6 to 802.15.4-2006? >>>>> They're using PMTU. On the local side you can know that it is >>>>> 802.15.4 and set a TCP MSS very small, but unless one side does >>>>> that the other has no way to detect the problem apart from >>>>> PMTU. >>>> Just double checking: So... these link layers do not support MTUs >>>> of 1280 bytes? >>>> >>>> e.g., what if the flow does not implement PMTUD? >>>> >>>> FWIW, I'm just trying to figure out if, when receiving an ICMP >>>> PTB that advertises a Next-Hop MTU smaller than 1280, it is >>>> really safe to *not* fragment the original packet in fragments of >>>> (at most) the advertised MTU. >>>> >>>> If there are link layers that do not support an MTU of 1280 bytes >>>> then, despite of what RFC 2460 requires, one may need to be more >>>> careful in this case, as sticking to 1280-byte packets may result >>>> in interoperability problems. >>> duh. :-) >>> >>> If you get a message back telling you to fragment to 50 bytes, I'd >>> suggest you do so. >> >> > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From huggie at earth.li Tue Sep 14 13:13:06 2010 From: huggie at earth.li (Simon Huggins) Date: Tue, 14 Sep 2010 12:13:06 +0100 Subject: Egress of multiple machines through one IP In-Reply-To: <20100910143629.GA9084@bongo.bofh.it> References: <20100910140249.GD24304@paranoidfreak.co.uk> <20100910143629.GA9084@bongo.bofh.it> Message-ID: <20100914111306.GM24304@paranoidfreak.co.uk> On Fri, Sep 10, 2010 at 04:36:29PM +0200, Marco d'Itri wrote: > On Sep 10, Simon Huggins wrote: > > Anyone any other good ideas? > Two redundant load balancers with sticky sessions in front of the > proxies, then the outgoing IP will not matter anymore. > You can easily install LVS on two of the proxy nodes, its CPU usage is > negligible (but you will need a recent kernel for IPv6 support). The nature of our traffic means stickiness doesn't work so well for us. We basically proxy for lots of large corporates. They often have the same IP from our point of view for lots of their users. So we can't easily balance that traffic on the way in based on IP. It's possible we could balance on something else but I'm sure some of our dear customers would confound our plans. I'm still pondering this one. -- Simon [ huggie at earth.li ] *\ "There's no emoticon for what I'm \** ****** ]-+-+-+-+-+-+-+-+-[ **\ feeling!" -- Comic Book Guy, The \* ****** [ Htag.pl 0.0.24 ] ***\ Simpsons. \ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100914/65742f2e/attachment.bin From kubah at janter.net Wed Sep 15 13:26:56 2010 From: kubah at janter.net (Jakub Heichman) Date: Wed, 15 Sep 2010 13:26:56 +0200 (CEST) Subject: Egress of multiple machines through one IP Message-ID: <43321.85.115.54.180.1284550016.squirrel@poczta.janter.net> > Noone does do v6 NAT for this (possibly edge) use case do they? I have never tried it, but perhaps this would help a bit? http://c-skills.blogspot.com/2009/01/ipv6-nat.html Jakub From cb.list6 at gmail.com Sun Sep 19 19:22:17 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 19 Sep 2010 10:22:17 -0700 Subject: 6VPE Route Reflector Message-ID: I made some assumption about how Cisco 7609 SRC4 code acts when configured as a BGP route reflector. I assumed the route reflector process was pure control plane and i would be able to use my existing IPv4 BGP route reflectors to work for the 6VPE routes. I just activate this new vpnv6 address family and it would just work. But, in my lab, when i went to configure address-family vpnv6, the router informed me that i would need to turn on IPv6 unicast routing first. (config)#router bgp 65100 (config-router)#address-family vpnv6 % IPv6 routing not enabled (config-router)# This is not a huge setback, but it was an unexpected step. Does anyone know a way around this requirement on a route reflector? I assume adding "ipv6 unicast-routing" enables some code pieces that are required for the route reflector to choose routes and handle the ipv6 data structures, but my concern is that it also turns on other IPv6 bits that i don't want to have on my route reflector at this point. Cameron From fernando at gont.com.ar Mon Sep 20 13:23:53 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 20 Sep 2010 08:23:53 -0300 Subject: BIND and multicast requests Message-ID: <4C974449.5030707@gont.com.ar> Hi, folks, [H D Moore, 2008] found that some versions of BIND respond to UDP-based requests directed to IPv6 multicast addresses. As far as I can see, this is a bug in BIND (or am I missing something?) Does anybody knows if this has been fixed? Any bug report or the like published about this issue? Note: H D Moore. 2008. Exploiting Tomorrow?s Internet Today: Penetration Testing with IPv6. Available at: http://uninformed.org/?v=10&a=3&t=pdf Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Sep 20 15:59:30 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 20 Sep 2010 23:29:30 +0930 Subject: BIND and multicast requests In-Reply-To: <4C974449.5030707@gont.com.ar> References: <4C974449.5030707@gont.com.ar> Message-ID: <20100920232930.38c684c2@opy.nosense.org> On Mon, 20 Sep 2010 08:23:53 -0300 Fernando Gont wrote: > Hi, folks, > > [H D Moore, 2008] found that some versions of BIND respond to UDP-based > requests directed to IPv6 multicast addresses. > > As far as I can see, this is a bug in BIND (or am I missing something?) > Does anybody knows if this has been fixed? Any bug report or the like > published about this issue? > The document seems to be observing it as a difference in behaviour rather than saying what security issue it creates. I'm not sure I can think of any sort of security issue other than an "all BIND servers" multicast amplification attack, which would be a pretty weak one I'd think, because there typically wouldn't be many DNS servers to solicit responses from. Any of the other all-scope multicast groups might be as much of or more of an issue, if there are enough group members available within the scope and the source address of the request is spoofed. > Note: > H D Moore. 2008. Exploiting Tomorrow?s Internet Today: Penetration > Testing with IPv6. Available at: http://uninformed.org/?v=10&a=3&t=pdf > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From tore.anderson at redpill-linpro.com Mon Sep 20 20:02:26 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 20 Sep 2010 20:02:26 +0200 Subject: Mac OS X IPv6 behaviour update Message-ID: <4C97A1B2.5090905@redpill-linpro.com> Hi guys, I've managed to get hold of an OS X 10.6.5 beta (build 10H542) and play a bit with it in my lab. It looks like Apple have been listening; the IPv6 behaviour is much improved. Worth noting: - 6to4 is no longer preferred over IPv4. I've tried both setting up a local 6to4 interface on the OS X host, advertising an autoconf prefix with RA, using both global and RFC 1918 IPv4 addresses on the Ethernet interface, using Safari/Firefox/Chrome - and I've so far not been able to reproduce any dualstack brokenness. - The local 6to4 adapter now deactivates itself automatically when the Ethernet interface is numbered with RFC 1918 addresses (unlike OS X 10.6.4). It's not 100% perfect though, some issues still remain: - Teredo is still preferred over IPv4, at least when it is configured with using SLAAC (OS X has no built-in support for Teredo, as far as I know). - If OS X has a default IPv6 route, but only link-local addresses (for example if it has received an RA without any prefix information), Firefox fails to connect to dual-stack sites. tcpdump doesn't see any IPv6 traffic on the wire though, so I'm not sure what's going on here. Chrome and Safari handles the situation fine - they don't bother to ask for AAAAs at all. In any case, this is an improvement over 10.6.4, where Safari too had the same problem as Firefox still do. I believe, however, that the vast majority of brokenness from the OS X clients are caused by the 6to4 issues. OS X 10.6.5 is therefore likely to have a very positive impact on the dualstack brokenness content providers struggle with these days. THANK YOU for fixing this, Apple! :-D Now I'm just hoping that their update notification service is aggressive enough to make most of their users upgrade to 10.6.5 shortly after it's been released... Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From jimjv38 at verizon.net Mon Sep 20 20:02:51 2010 From: jimjv38 at verizon.net (James Vaglia) Date: Mon, 20 Sep 2010 14:02:51 -0400 Subject: Nothing on the web site: www.ipve6.org Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100920/2ff51de9/attachment.html From berni at birkenwald.de Mon Sep 20 21:36:22 2010 From: berni at birkenwald.de (Bernhard Schmidt) Date: Mon, 20 Sep 2010 21:36:22 +0200 Subject: Mac OS X IPv6 behaviour update In-Reply-To: <4C97A1B2.5090905@redpill-linpro.com> References: <4C97A1B2.5090905@redpill-linpro.com> Message-ID: <4C97B7B6.5060301@birkenwald.de> On 20.09.2010 20:02, Tore Anderson wrote: Hi Tore, > I've managed to get hold of an OS X 10.6.5 beta (build 10H542) and play > a bit with it in my lab. It looks like Apple have been listening; the > IPv6 behaviour is much improved. Worth noting: Do you know whether the resolver has been fixed, too (MacOS X 10.6 querying both AAAA/A at the same time, but only accepting the first answer -> broken failover and non-deterministic AFI selection)? Best Regards, Bernhard From tore.anderson at redpill-linpro.com Tue Sep 21 11:29:57 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 21 Sep 2010 11:29:57 +0200 Subject: Mac OS X IPv6 behaviour update In-Reply-To: <4C97B7B6.5060301@birkenwald.de> References: <4C97A1B2.5090905@redpill-linpro.com> <4C97B7B6.5060301@birkenwald.de> Message-ID: <4C987B15.9040403@redpill-linpro.com> * Bernhard Schmidt > Do you know whether the resolver has been fixed, too (MacOS X 10.6 > querying both AAAA/A at the same time, but only accepting the first > answer -> broken failover and non-deterministic AFI selection)? Hi, from what I can tell, there appears to be a timeout of approx. 125ms before the resolver stops waiting for AAAA responses. In other words, if the AAAA response is received > ~125ms later than the A response (or this could possibly be 125ms since the AAAA query was transmitted), IPv4 connectivity is used even though IPv6 would normally be preferred. It is much more insistent on getting A responses, though. If it doesn't receive a response quickly, it retransmits the query several times. It didn't start preferring 6to4 to IPv4 until I delayed the A responses more than 25 seconds. I don't know if these timeouts have changed since OS X 10.6.4, though. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From fernando at gont.com.ar Wed Sep 22 10:49:53 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 22 Sep 2010 05:49:53 -0300 Subject: ToS-like processing of the IPv6 Traffic Class? Message-ID: <4C99C331.4040507@gont.com.ar> Hi, folks, I'm told that many deployments of IPv6 use the RFC 791 ToS (Type of Service) semantics/definitions for the IPv6 Traffic Class field, e.g. allowing strict precedence queuing. Can anybody confirm this? If this is the case, does this thing have to be explicitly enabled, or is it the "default" behavior in some implementations? Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter at gmail.com Thu Sep 23 02:01:54 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 23 Sep 2010 12:01:54 +1200 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <4C99C331.4040507@gont.com.ar> References: <4C99C331.4040507@gont.com.ar> Message-ID: <4C9A98F2.5080407@gmail.com> Fernando, I can't comment on what people do in practice, but RFC 2474 (which grandfathers IP Precedence from RFC 791) applies in strictly the same way to IPv4 and IPv6. Whether a particular network domain chooses to deploy diffserv or not is an entirely local operational decision. I would personally advocate deploying diffserv identically for IPv4 and IPv6, simply to minimise surprises, if products allow it. Brian On 2010-09-22 20:49, Fernando Gont wrote: > Hi, folks, > > I'm told that many deployments of IPv6 use the RFC 791 ToS (Type of > Service) semantics/definitions for the IPv6 Traffic Class field, e.g. > allowing strict precedence queuing. > > Can anybody confirm this? > > If this is the case, does this thing have to be explicitly enabled, or > is it the "default" behavior in some implementations? > > Thanks! > > Kind regards, From ek at google.com Thu Sep 23 10:40:37 2010 From: ek at google.com (Erik Kline) Date: Thu, 23 Sep 2010 17:40:37 +0900 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <4C9A98F2.5080407@gmail.com> References: <4C99C331.4040507@gont.com.ar> <4C9A98F2.5080407@gmail.com> Message-ID: > Whether a particular network domain chooses to deploy diffserv > or not is an entirely local operational decision. I would > personally advocate deploying diffserv identically for IPv4 > and IPv6, simply to minimise surprises, if products allow it. Agreed. Cross-protocol uniformity generally lowers operational overhead. (At the very least it reduces cognitive overload.) From maho at nic.dtag.de Fri Sep 24 16:12:15 2010 From: maho at nic.dtag.de (Martin Horneffer) Date: Fri, 24 Sep 2010 16:12:15 +0200 Subject: 6VPE Route Reflector In-Reply-To: References: Message-ID: <20100924141215.GF338@nic.dtag.de> On Sun, Sep 19, 2010 at 10:22:17AM -0700, Cameron Byrne wrote: [..] > This is not a huge setback, but it was an unexpected step. Does > anyone know a way around this requirement on a route reflector? I > assume adding "ipv6 unicast-routing" enables some code pieces that are > required for the route reflector to choose routes and handle the ipv6 > data structures, but my concern is that it also turns on other IPv6 > bits that i don't want to have on my route reflector at this point. My situation is a bit different, but the software was close to your version and I experienced the same. But anyways - what kind is your concern of? As for security: I would suppose that as long as you don't configure IPv6 on any interface still no IPv6 communication between the outside and your router should be possible. As for activating new code paths: I guess this happens anyways if you activate RR functionality for a new address-family. Best regards, Martin > > Cameron -- Dr. Martin Horneffer Deutsche Telekom Netzproduktion GmbH Technical Engineering Center Deutsche Telekom Netzproduktion GmbH Supervisory Board: Dr. Steffen Roehn (Chairman) Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, Klaus Peren Commercial register: Amtsgericht Bonn HRB 14190 Registered office: Bonn VAT ident. no.: DE 814645262 From cb.list6 at gmail.com Fri Sep 24 16:42:48 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 24 Sep 2010 07:42:48 -0700 Subject: 6VPE Route Reflector In-Reply-To: <20100924141215.GF338@nic.dtag.de> References: <20100924141215.GF338@nic.dtag.de> Message-ID: On Fri, Sep 24, 2010 at 7:12 AM, Martin Horneffer wrote: > On Sun, Sep 19, 2010 at 10:22:17AM -0700, Cameron Byrne wrote: > [..] >> This is not a huge setback, but it was an unexpected step. ?Does >> anyone know a way around this requirement on a route reflector? ?I >> assume adding "ipv6 unicast-routing" enables some code pieces that are >> required for the route reflector to choose routes ?and handle the ipv6 >> data structures, but my concern is that it also turns on other IPv6 >> bits that i don't want to have on my route reflector at this point. > > My situation is a bit different, but the software was close to your > version and I experienced the same. > > But anyways - what kind is your concern of? > Mostly surprise, but in my mind, 6VPE only had edge impacts for IPv6 deployment, but i consider route reflector changes of this nature to be a core impact. This impact cascades into the scope of what it means to bring IPv6 into operations. So, operational concerns are what first came to mind and that includes security and exposure to bugs from new code paths in the core. I was told this requirement of IPv6 routing on route reflectors is only for IOS, IOS-XR does not have the same requirement. > As for security: I would suppose that as long as you don't configure > IPv6 on any interface still no IPv6 communication between the outside > and your router should be possible. > Correct, but do those new code paths open up silent loopback interfaces? Or link local addresses? From looking at the router, i would say no. But, this is the risk of turning on IPv6 routing when you do not expect it. It is probably still prudent to put an IPv6 ACL on the VTY even though there is no IPv6 address configured. If for no other reason that some other engineer will see IPv6 unicast routing turned on any may add an address later.... or later version of code will enable link local addresses by default and that may be a path to access the router and circumvent the security controls. > As for activating new code paths: I guess this happens anyways if you > activate RR functionality for a new address-family. > But the scope would be just for BGP route reflection verses system wide enablement. Cameron From nick at foobar.org Fri Sep 24 17:41:10 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 24 Sep 2010 16:41:10 +0100 Subject: Spam from V6 World Congress? Message-ID: <4C9CC696.7040207@foobar.org> Did anyone else get spammed by "V6 World Congress": http://www.upperside.fr/v6world2011/v6world2011program_over.html Looks like there are a lot of clued-in people presenting at this conference. I hope they don't mind that the organisers are spammers. Nick From ben at bjencks.net Fri Sep 24 17:42:54 2010 From: ben at bjencks.net (Ben Jencks) Date: Fri, 24 Sep 2010 11:42:54 -0400 Subject: Egress of multiple machines through one IP In-Reply-To: <20100910140249.GD24304@paranoidfreak.co.uk> References: <20100910140249.GD24304@paranoidfreak.co.uk> Message-ID: On Fri, Sep 10, 2010 at 10:02, Simon Huggins wrote: > It's been a few years since I used IPv6 for real but new work are about > to look at it. ?Previously, I was part of an ISP that provided ADSL, > dialup, colo and some of our own services over v6 so I have been helping > give them some ideas for our v6 deployment. > > I do have one problem that has me stumped though. > > We run lots of web proxies with multiple nodes. ?We should be able to do > the ingress load balancing in a similar way to v4 though I'm a little > unclear on the implications of neighbour discovery here. > But I have an issue with egrees. > > We proxy web traffic so we want every outgoing request to come from the > same IP. ?We know from experience that some websites that are security > conscious will reject sessions that don't continue to come from the same > IP to prevent session stealing. > > In v4 this is easy; we just have a nat pool and everything comes from > the egress IP we've assigned to that group of servers. > > In v6 I... can't think of a way we can do it without introducing some > sort of application proxy between our servers and the websites which > would be the single point of failure we were trying to avoid. v4 nat is stateful, that's a SPOF too. Presumably you're doing some sort of failover on the nat boxes; do the same thing on the application proxy boxes. I don't know of any implementations that synchronize TCP state to the secondary box the way some higher-end nat implementations do, but there's no reason it's not possible. Or you could just have the "originating" applications retry if the proxy fails over. For the proxy to operate at the tcp level, it could even be a middlebox and take the dest address from the original packet... then it starts to look a lot like a NAT, but maybe people will be less scared if it's presented as a lightweight TCP proxy. -Ben From jeroen at unfix.org Fri Sep 24 18:16:31 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Sep 2010 18:16:31 +0200 Subject: Spam from V6 World Congress? In-Reply-To: <4C9CC696.7040207@foobar.org> References: <4C9CC696.7040207@foobar.org> Message-ID: <4C9CCEDF.80909@unfix.org> On 2010-09-24 17:41, Nick Hilliard wrote: > Did anyone else get spammed by "V6 World Congress": > > http://www.upperside.fr/v6world2011/v6world2011program_over.html > > Looks like there are a lot of clued-in people presenting at this > conference. > > I hope they don't mind that the organisers are spammers. Can you elaborate on the 'spam' portion? Headers are always nice. Greets, Jeroen From nick at foobar.org Fri Sep 24 18:20:47 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 24 Sep 2010 17:20:47 +0100 Subject: Spam from V6 World Congress? In-Reply-To: <4C9CCEDF.80909@unfix.org> References: <4C9CC696.7040207@foobar.org> <4C9CCEDF.80909@unfix.org> Message-ID: <4C9CCFDF.9070007@foobar.org> On 24/09/2010 17:16, Jeroen Massar wrote: > Can you elaborate on the 'spam' portion? Headers are always nice. http://pastebin.com/baPrg4hr Nick From ryanczak at arin.net Fri Sep 24 18:26:18 2010 From: ryanczak at arin.net (Matt Ryanczak) Date: Fri, 24 Sep 2010 12:26:18 -0400 Subject: Spam from V6 World Congress? In-Reply-To: <4C9CCEDF.80909@unfix.org> References: <4C9CC696.7040207@foobar.org> <4C9CCEDF.80909@unfix.org> Message-ID: <4C9CD12A.60309@arin.net> On 09/24/2010 12:16 PM, Jeroen Massar wrote: >> > Can you elaborate on the 'spam' portion? Headers are always nice. > Perhaps he is referring to the unsolicited bulk mail nature of the messages. I'm getting them too. mail list harvesting? From jeroen at unfix.org Fri Sep 24 18:36:08 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 24 Sep 2010 18:36:08 +0200 Subject: Spam from V6 World Congress? / www.upperside.fr In-Reply-To: <4C9CCFDF.9070007@foobar.org> References: <4C9CC696.7040207@foobar.org> <4C9CCEDF.80909@unfix.org> <4C9CCFDF.9070007@foobar.org> Message-ID: <4C9CD378.9060304@unfix.org> Latif, can you explain to the people of "Upperside" that spamming folks is really unacceptable and thus that that means we'll simply ignore anything they do? Thanks. On 2010-09-24 18:20, Nick Hilliard wrote: > On 24/09/2010 17:16, Jeroen Massar wrote: >> Can you elaborate on the 'spam' portion? Headers are always nice. > > http://pastebin.com/baPrg4hr They just flooded in on a couple of addresses of mine which are 'ipv6 related' but which I don't use for mailing outbound, thus clearly they have scraped them indeed. Same host btw, thus the header path is more or less the same. I've cc'd Latif on this he should be able to kick some sense in those people. I also do not mind a little bit of promotion of IPv6 (even though some people are just pushing it too hard IMHO while not adding anything new) but this is just scraping addresses and spamming and then they want you to pay for their conference too, no thanks. This portion: < kind of completely proves that it is a spam run and nothing else. Mass marketing and nobody asked for it... Clearly nobody is interested in their little conference that they have to resort to these kind of tactics. Greets, Jeroen From fred at cisco.com Sat Sep 25 08:51:05 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 24 Sep 2010 23:51:05 -0700 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt References: <20100924194512.4C6EA3A69AE@core3.amsl.com> Message-ID: <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> I would appreciate opinions from the operators forum; please post comments to v6ops at ietf.org. The IPv6 Operations Working Group has been asked to adopt this document as a working group draft. In essence, the outcome would become a suggestion to the RIR and *NOG communities regarding the way the IETF would suggest that IPv6 prefixes be allocated. Note the use of the word "suggest". In summary, what this says is that the IETF holds no strong opinions about specific prefix lengths or boundaries, but strongly feels that the allocation policies should be scalable - which means that PI allocations to edge networks should be done only when Really Truly Appropriate. My question is: is this something that the operational community would consider helpful, or is it something the operational community would prefer the IETF kept its nose out of? If the operational community would find it helpful, is the specific suggestion reasonable from an operational perspective? Fred Baker Chair IPv6 Operations WG Begin forwarded message: > From: Internet-Drafts at ietf.org > Date: September 24, 2010 12:45:06 PM PDT > To: i-d-announce at ietf.org > Subject: I-D Action:draft-azinger-scalable-addressing-00.txt > Reply-To: internet-drafts at ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : A Scalable Addressing Allocation Architecture for IPv6 > Author(s) : M. Azinger, et al. > Filename : draft-azinger-scalable-addressing-00.txt > Pages : 14 > Date : 2010-09-24 > > This document presents a scalable architecture for assigning and > aggregating IPv6 address space. The current IPv4 addressing > aggregation strategy was defined in [RFC1519] (and updated in > [RFC4632]) and the IPv4 address allocation architecture was defined > in [RFC1518]. A similar address allocation architecture was proposed > for IPv6 in [RFC1887]. The objective of this document is to update > the previous documents and provide the best current guidance on an > address allocation architecture to help manage the growth of routing > tables in IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-azinger-scalable-addressing-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/plain
content-id: < Size: 0 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100924/dd3585ab/attachment.bin -------------- next part -------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From spz at serpens.de Sat Sep 25 12:35:00 2010 From: spz at serpens.de (S.P.Zeidler) Date: Sat, 25 Sep 2010 12:35:00 +0200 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> Message-ID: <20100925103459.GB27830@serpens.de> Hi, I'm not currently with a provider, so personally I'm only a very small scale v6 op at present. :) Things that struck me but may be seen differently by people with current operational experience: Points 4+5: "People should just get PA from one of their providers when they want to multihome, and talk them into allowing other providers to announce it" been there, done that, finally got over it. Anyone not seeing that as a dead horse? Also, how does a PA /48 that gets announced more specific have a smaller impact on the routing tables than a PI /48? even the provider it's PA to must announce it more specific or have to accept being the loser in routing decisions because more specific has to win (and in all traffic accounted contracts, that idea will not sit well). Aggregating this at a higher tier would require checking that there didn't exist any announcement through a non-customer and de-aggregating as soon as one was seen; I'm not sure the collective computational load for that would be so much lower than just announcing the prefix. Next: The analysis in point 6 looks bogus to me. point one (rephrased a lot): "If v6 ASes grow by 54% now, it will continue to grow by at least 50%. It is not existing v4 ASes adding v6 and being naturally limited by all current v4 ASes having added the one v6 prefix necessary to survive, after which point the growth rate will drop drastically to the yearly growth rate in ASes we see in v4 now". Obviously, we are in a flood fill period that is rather not representative for the long run. point two (also rephrased): "If you only have one upstream in v6 at present you are likely an end user who never will have more than one upstream and could as well use PA" That's an assertion that thoroughly underestimates both getting the upstreams one has for v4 to provide v6, and introduction periods where one irons out the kinks and learns the ropes with one friendly and knowledgeable upstream before tackling v6 with the rest of the upstream zoo. Could someone with a grab on current data do a comparison of what the ASes that are recognized as stubs in v6 do in v4, please, just to replace guessing (either way) with information? Overall document: Given that even huge ASes will only originate a small number of prefixes in v6 compared to dozens to hundreds in v4 now, what problem exactly is this trying to fix? As long as getting PI space is bound to getting or having an AS I don't really see the scaling problem. Running an AS requires the necessary routers, time by skilled engineers (even most IT workers only have a very vague idea how networking works and are definitely not able to set up BGP; you can contract the service but that costs money), and the usually more expensive upstream contracts that allow BGP sessions. Businesses tend to be able to do the math and decide that a server or two in housing and two independently numbered upstreams are way cheaper; if they serve their needs as well, they will pick that option. The danger of every corner shop in the world trying to get PI is not actually there IMHO. Comments to my comments? regards, spz -- spz at serpens.de (S.P.Zeidler) From merike at aristanetworks.com Thu Sep 23 11:39:09 2010 From: merike at aristanetworks.com (Merike Kaeo) Date: Thu, 23 Sep 2010 02:39:09 -0700 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <4C99C331.4040507@gont.com.ar> References: <4C99C331.4040507@gont.com.ar> Message-ID: <95AFC34C-B796-408D-A5CA-B6E17E678EFE@doubleshotsecurity.com> Here's two pointers that may help: http://www.juniper.net/techpubs/en_US/junos9.4/topics/concept/cos-ipv6-protocols-overview-solution.html http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-qos.html [especially the troubleshooting part] It's been a few years since I dealt with configuring and knowing how to deal with buffers and queueing but I think you did have to specify explicitly how you'd want the queueing to be handled - there wasn't just a default 'allow strict precedence queueing'. And while I'd agree that using same policies and configurations for IPv4/IPv6 will reduce operational headaches and confusion, I'd be curious to know if some people out there ARE using different QoS configurations for application traffic going over v4 vs v6 and why. - merike On Sep 22, 2010, at 1:49 AM, Fernando Gont wrote: > Hi, folks, > > I'm told that many deployments of IPv6 use the RFC 791 ToS (Type of > Service) semantics/definitions for the IPv6 Traffic Class field, e.g. > allowing strict precedence queuing. > > Can anybody confirm this? > > If this is the case, does this thing have to be explicitly enabled, or > is it the "default" behavior in some implementations? > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From michael at rancid.berkeley.edu Sat Sep 25 21:29:55 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 25 Sep 2010 12:29:55 -0700 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> Message-ID: <4C9E4DB3.3040704@rancid.berkeley.edu> On 09/24/10 23:51, Fred Baker wrote: > I would appreciate opinions from the operators forum; please post > comments to v6ops at ietf.org. > > The IPv6 Operations Working Group has been asked to adopt this > document as a working group draft. In essence, the outcome would > become a suggestion to the RIR and *NOG communities regarding the way > the IETF would suggest that IPv6 prefixes be allocated. Note the use > of the word "suggest". In summary, what this says is that the IETF > holds no strong opinions about specific prefix lengths or boundaries, > but strongly feels that the allocation policies should be scalable - > which means that PI allocations to edge networks should be done only > when Really Truly Appropriate. > > My question is: is this something that the operational community > would consider helpful, or is it something the operational community > would prefer the IETF kept its nose out of? If the operational > community would find it helpful, is the specific suggestion > reasonable from an operational perspective? I may be a bit of a curmudgeon here, but I think one sentiment you might hear from the operations community is: "No thank-you. The IETF has already done more than enough to place obstacles in front of IPv6 adoption, particularly by 'end sites'. We don't need to add to that." On a slightly more constructive note: It's very clear to me that the belief that we could limit the routing table growth by massively aggregating prefixes and creating a strong distinction between "end sites" and "service providers" has been discredited--and IPv6 almost failed as a result. I don't think turning the clock back is going to help at all and I think such an effort will be largely ignored (as was the original effort to make IPv6 largely PA-only). Three major issues I have with this and similar efforts: 1. It presupposes a particular economic architecture within the Internet, one where there is a relatively clear distinction between service providers and end sites, specific relationships between service providers and end sites, and a particular arrangement of these entities. Even if I accept this as matching the reality of today's Internet--and that point is certainly arguable, I can't know that this arrangement will exist throughout the lifetime of IPv6--it certainly didn't for the full life of IPv4. Moreover, the policy recommendations are driven by this economic characterization. The draft goes through a number of logical gyrations in section 2.3 to show that the recommendations are based on technical grounds in order to justify the IETF's jurisdiction. Strikingly, this is the longest section of the document, and by far the longest section of original content, as opposed to quotations from other RFCs. Nevertheless, the recommendations rest entirely on a particular economic reality (or characterization thereof) and therefore make little sense coming from a standards body. 2. It is service-provider-centric. This is justified by topological considerations in section 4 (the second-longest section of the document), but this justification is misplaced, partly due to its assumption that aggregation among *end sites* is the only way to reduce routing table growth. The recommendations impose costs on end sites by making them renumber when they want to change service providers or by making them convince service providers to poke holes in their announcements--requests which service providers could easily ignore. It makes multi-homing of end sites more difficult. It imposes no costs on service providers who happily have access to portable addresses, derive additional benefit from a smaller routing table, and share zero cost for either of these benefits. It doesn't require much thought to see why the operations community might be opposed to this. Standards shouldn't merely reflect the interests of those who only make up a portion of the overall Internet community. 3. It makes an extrapolated projection of the IPv6 prefix growth rate, while characterizing that growth based solely on current IPv6 address growth, rather than including the richness of IPv4 experience. The current IPv4 stats tell us that IPv4 table bloat is caused by announcement of disaggregated prefixes that could be aggregated, and by announcement of multiple non-aggregable prefixes by the same AS. A rather draconian policy would be to assert that no AS can ever announce more than one IPv6 prefix. If someone acquires additional prefixes from mergers and acquisitions, they must renumber. It imposes costs on end sites and service providers alike, which is why it would never be adopted. It also forces the AS allocation policy to be the limiting policy for address growth and might put pressure on that policy. But unlike a PA-only policy, it takes into account more factors in routing table growth. Anyway, my point is not to say that my suggestion is better; rather it is intended as a straw man to show how stilted the proposed draft is regarding service providers (#2 above) and our limited IPv6 experience (#3 above). On a more general note, these arguments are best left to the RIRs and their constituents and the NRO--and they are well versed in this topic. Having the IETF get involved at this stage of the game would be counter-productive. On the other hand, having the IETF work on new protocols that scale better would probably be appreciated. michael From brian.e.carpenter at gmail.com Sat Sep 25 21:37:51 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 26 Sep 2010 08:37:51 +1300 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100925103459.GB27830@serpens.de> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <20100925103459.GB27830@serpens.de> Message-ID: <4C9E4F8F.3040807@gmail.com> Just commenting on a few points, and cross-posting in response to Fred's request: On 2010-09-25 22:35, S.P.Zeidler wrote: > Hi, > > I'm not currently with a provider, so personally I'm only a very small > scale v6 op at present. :) Things that struck me but may be seen > differently by people with current operational experience: > > Points 4+5: > "People should just get PA from one of their providers when they want to > multihome, and talk them into allowing other providers to announce it" > > been there, done that, finally got over it. Anyone not seeing that as a > dead horse? > Also, how does a PA /48 that gets announced more specific have a smaller > impact on the routing tables than a PI /48? It doesn't. The effect is exactly the same, for all practical purposes. This emperor has no clothes. As we have known for many years, it's only if multihoming is achieved by running a different PA prefix for each provider that we don't blow out the BGP4 table. Hence RFC3582, RFC4177, shim6, ILNP, LISP and a host of other work (see draft-irtf-rrg-recommendation). > even the provider it's PA to > must announce it more specific or have to accept being the loser in > routing decisions because more specific has to win (and in all traffic > accounted contracts, that idea will not sit well). > Aggregating this at a higher tier would require checking that there > didn't exist any announcement through a non-customer and de-aggregating > as soon as one was seen; I'm not sure the collective computational load > for that would be so much lower than just announcing the prefix. > > Next: > The analysis in point 6 looks bogus to me. > > point one (rephrased a lot): > "If v6 ASes grow by 54% now, it will continue to grow by at least 50%. > It is not existing v4 ASes adding v6 and being naturally limited by all > current v4 ASes having added the one v6 prefix necessary to survive, > after which point the growth rate will drop drastically to the yearly > growth rate in ASes we see in v4 now". > Obviously, we are in a flood fill period that is rather not > representative for the long run. Well, if every active AS that announces IPv4 prefix(es) today also announced IPv6 prefix(es), guess what, we'd have about 35,000 active ASes announcing IPv6 prefixes. That doesn't really matter; the question is whether we would also have 330,000 IPv6 prefixes, or significantly fewer, and how these numbers will evolve in future. And that, truly, I cannot guess. > > point two (also rephrased): > "If you only have one upstream in v6 at present you are likely an end user > who never will have more than one upstream and could as well use PA" > > That's an assertion that thoroughly underestimates both getting > the upstreams one has for v4 to provide v6, and introduction periods > where one irons out the kinks and learns the ropes with one friendly > and knowledgeable upstream before tackling v6 with the rest of the > upstream zoo. Not to mention the expected increase in multihoming in the future. > > Could someone with a grab on current data do a comparison of what the ASes > that are recognized as stubs in v6 do in v4, please, just to replace > guessing (either way) with information? Data are always nice, and I suspect that these data are available at potaroo.net, but actually, I would hesitate to extrapolate from the early-adopter IPv6 deployment today. > > Overall document: > Given that even huge ASes will only originate a small number of > prefixes in v6 compared to dozens to hundreds in v4 now, what problem > exactly is this trying to fix? That depends entirely on user sites and ISPs following good (CIDR-like) practice. So I think encouraging that is the useful goal of this draft. > As long as getting PI space is bound to getting or having an AS I don't > really see the scaling problem. Well, unless it encourages a gold rush on AS numbers. > Running an AS requires the necessary routers, time by skilled engineers > (even most IT workers only have a very vague idea how networking works > and are definitely not able to set up BGP; you can contract the service > but that costs money), and the usually more expensive upstream contracts > that allow BGP sessions. > Businesses tend to be able to do the math and decide that a server or > two in housing and two independently numbered upstreams are way cheaper; > if they serve their needs as well, they will pick that option. I really hope you're correct. But if word gets around the world of CIOs that the thing to do is get your own AS and a PI prefix, then you can't be sure that sanity will prevail. And frankly, site managers that I've talked to are puzzled and worried by the prospect of running several simultaneous PA prefixes, and having to renumber when they add or drop an ISP. See RFC 5887. > The danger of every corner shop in the world trying to get PI is not > actually there IMHO. Again, I hope you're correct, but why not document the fact that it's highly undesirable? Brian > > Comments to my comments? > > regards, > spz From brian.e.carpenter at gmail.com Sat Sep 25 21:51:30 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sun, 26 Sep 2010 08:51:30 +1300 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9E4DB3.3040704@rancid.berkeley.edu> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4DB3.3040704@rancid.berkeley.edu> Message-ID: <4C9E52C2.5070502@gmail.com> Michael, Again, cross-posting to v6ops - I think your arguments must be discussed there. (Normally, I avoid cross-posting like the plague.) Three comments on your points below: 1. I agree that it is not the IETF's place to assert policy in this area. Actually we are not supposed to, under the terms of RFC2860 (which, as it happens, Fred and I both signed in ink). 2. But it is our place to document the technical implications of various alternatives, as they affect the future scaling of the Internet. It's certainly correct that the operator community has most of the data and experience, of course. So I would advocate that any IETF document in this area is written with the benefit of that experience, and that it keeps away from asserting policy. 3. Finally, you say: >> On the other hand, having the IETF work on new >> protocols that scale better would probably be appreciated. Er, yes, but see my previous message - we've been on this topic in the IRTF and IETF for ten years and more, and it's hard. Regards Brian Carpenter On 2010-09-26 08:29, Michael Sinatra wrote: > On 09/24/10 23:51, Fred Baker wrote: >> I would appreciate opinions from the operators forum; please post >> comments to v6ops at ietf.org. >> >> The IPv6 Operations Working Group has been asked to adopt this >> document as a working group draft. In essence, the outcome would >> become a suggestion to the RIR and *NOG communities regarding the way >> the IETF would suggest that IPv6 prefixes be allocated. Note the use >> of the word "suggest". In summary, what this says is that the IETF >> holds no strong opinions about specific prefix lengths or boundaries, >> but strongly feels that the allocation policies should be scalable - >> which means that PI allocations to edge networks should be done only >> when Really Truly Appropriate. >> >> My question is: is this something that the operational community >> would consider helpful, or is it something the operational community >> would prefer the IETF kept its nose out of? If the operational >> community would find it helpful, is the specific suggestion >> reasonable from an operational perspective? > > I may be a bit of a curmudgeon here, but I think one sentiment you might > hear from the operations community is: "No thank-you. The IETF has > already done more than enough to place obstacles in front of IPv6 > adoption, particularly by 'end sites'. We don't need to add to that." > > On a slightly more constructive note: > > It's very clear to me that the belief that we could limit the routing > table growth by massively aggregating prefixes and creating a strong > distinction between "end sites" and "service providers" has been > discredited--and IPv6 almost failed as a result. I don't think turning > the clock back is going to help at all and I think such an effort will > be largely ignored (as was the original effort to make IPv6 largely > PA-only). > > Three major issues I have with this and similar efforts: > > 1. It presupposes a particular economic architecture within the > Internet, one where there is a relatively clear distinction between > service providers and end sites, specific relationships between service > providers and end sites, and a particular arrangement of these entities. > Even if I accept this as matching the reality of today's Internet--and > that point is certainly arguable, I can't know that this arrangement > will exist throughout the lifetime of IPv6--it certainly didn't for the > full life of IPv4. > > Moreover, the policy recommendations are driven by this economic > characterization. The draft goes through a number of logical gyrations > in section 2.3 to show that the recommendations are based on technical > grounds in order to justify the IETF's jurisdiction. Strikingly, this > is the longest section of the document, and by far the longest section > of original content, as opposed to quotations from other RFCs. > Nevertheless, the recommendations rest entirely on a particular economic > reality (or characterization thereof) and therefore make little sense > coming from a standards body. > > 2. It is service-provider-centric. This is justified by topological > considerations in section 4 (the second-longest section of the > document), but this justification is misplaced, partly due to its > assumption that aggregation among *end sites* is the only way to reduce > routing table growth. The recommendations impose costs on end sites by > making them renumber when they want to change service providers or by > making them convince service providers to poke holes in their > announcements--requests which service providers could easily ignore. It > makes multi-homing of end sites more difficult. It imposes no costs on > service providers who happily have access to portable addresses, derive > additional benefit from a smaller routing table, and share zero cost for > either of these benefits. It doesn't require much thought to see why > the operations community might be opposed to this. Standards shouldn't > merely reflect the interests of those who only make up a portion of the > overall Internet community. > > 3. It makes an extrapolated projection of the IPv6 prefix growth rate, > while characterizing that growth based solely on current IPv6 address > growth, rather than including the richness of IPv4 experience. The > current IPv4 stats tell us that IPv4 table bloat is caused by > announcement of disaggregated prefixes that could be aggregated, and by > announcement of multiple non-aggregable prefixes by the same AS. A > rather draconian policy would be to assert that no AS can ever announce > more than one IPv6 prefix. If someone acquires additional prefixes from > mergers and acquisitions, they must renumber. It imposes costs on end > sites and service providers alike, which is why it would never be > adopted. It also forces the AS allocation policy to be the limiting > policy for address growth and might put pressure on that policy. But > unlike a PA-only policy, it takes into account more factors in routing > table growth. > > Anyway, my point is not to say that my suggestion is better; rather it > is intended as a straw man to show how stilted the proposed draft is > regarding service providers (#2 above) and our limited IPv6 experience > (#3 above). > > On a more general note, these arguments are best left to the RIRs and > their constituents and the NRO--and they are well versed in this topic. > Having the IETF get involved at this stage of the game would be > counter-productive. On the other hand, having the IETF work on new > protocols that scale better would probably be appreciated. > > michael > From fred at cisco.com Sat Sep 25 22:03:58 2010 From: fred at cisco.com (Fred Baker) Date: Sat, 25 Sep 2010 13:03:58 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9E4F8F.3040807@gmail.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <20100925103459.GB27830@serpens.de> <4C9E4F8F.3040807@gmail.com> Message-ID: <0AF337A7-7EA7-4199-9B14-5FD605CD7AE8@cisco.com> >> Overall document: >> Given that even huge ASes will only originate a small number of >> prefixes in v6 compared to dozens to hundreds in v4 now, what problem >> exactly is this trying to fix? > > That depends entirely on user sites and ISPs following good (CIDR-like) > practice. So I think encouraging that is the useful goal of this draft. Which is where the draft is trying to go. >> As long as getting PI space is bound to getting or having an AS I don't >> really see the scaling problem. > > Well, unless it encourages a gold rush on AS numbers. >> The danger of every corner shop in the world trying to get PI is not >> actually there IMHO. > > Again, I hope you're correct, but why not document the fact that it's > highly undesirable? We are in fact seeing quite a growth in AS numbers and in requests for PI allocation. You might look at http://www.potaroo.net/tools/asn16/ The growth rate of the AS number space is not spiking up per se, but it is non-linear, with increases in rate circa 2000 (with the dot-com bubble bursting, there was an increase in the assignment rate of AS numbers) and 2009-2010. I would imagine these are not "to get PI space" but "to multihome using BGP". If anything, I see that as the argument for solutions like ILNP or NAT66 (the draft, which does stateless prefix translation, not the idea of making stateful IPv6/IPv6 network ADDRESS translators). They enable the transit operators to view their networks as PA while their customers view themselves as pseudo-PI. Yes, it has issues similar to those described in RFC 2993. From ms at berkeley.edu Sat Sep 25 21:28:46 2010 From: ms at berkeley.edu (Michael Sinatra) Date: Sat, 25 Sep 2010 12:28:46 -0700 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> Message-ID: <4C9E4D6E.2040605@berkeley.edu> On 09/24/10 23:51, Fred Baker wrote: > I would appreciate opinions from the operators forum; please post > comments to v6ops at ietf.org. > > The IPv6 Operations Working Group has been asked to adopt this > document as a working group draft. In essence, the outcome would > become a suggestion to the RIR and *NOG communities regarding the way > the IETF would suggest that IPv6 prefixes be allocated. Note the use > of the word "suggest". In summary, what this says is that the IETF > holds no strong opinions about specific prefix lengths or boundaries, > but strongly feels that the allocation policies should be scalable - > which means that PI allocations to edge networks should be done only > when Really Truly Appropriate. > > My question is: is this something that the operational community > would consider helpful, or is it something the operational community > would prefer the IETF kept its nose out of? If the operational > community would find it helpful, is the specific suggestion > reasonable from an operational perspective? I may be a bit of a curmudgeon here, but I think one sentiment you might hear from the operations community is: "No thank-you. The IETF has already done more than enough to place obstacles in front of IPv6 adoption, particularly by 'end sites'. We don't need to add to that." On a slightly more constructive note: It's very clear to me that the belief that we could limit the routing table growth by massively aggregating prefixes and creating a strong distinction between "end sites" and "service providers" has been discredited--and IPv6 almost failed as a result. I don't think turning the clock back is going to help at all and I think such an effort will be largely ignored (as was the original effort to make IPv6 largely PA-only). Three major issues I have with this and similar efforts: 1. It presupposes a particular economic architecture within the Internet, one where there is a relatively clear distinction between service providers and end sites, specific relationships between service providers and end sites, and a particular arrangement of these entities. Even if I accept this as matching the reality of today's Internet--and that point is certainly arguable, I can't know that this arrangement will exist throughout the lifetime of IPv6--it certainly didn't for the full life of IPv4. Moreover, the policy recommendations are driven by this economic characterization. The draft goes through a number of logical gyrations in section 2.3 to show that the recommendations are based on technical grounds in order to justify the IETF's jurisdiction. Strikingly, this is the longest section of the document, and by far the longest section of original content, as opposed to quotations from other RFCs. Nevertheless, the recommendations rest entirely on a particular economic reality (or characterization thereof) and therefore make little sense coming from a standards body. 2. It is service-provider-centric. This is justified by topological considerations in section 4 (the second-longest section of the document), but this justification is misplaced, partly due to its assumption that aggregation among *end sites* is the only way to reduce routing table growth. The recommendations impose costs on end sites by making them renumber when they want to change service providers or by making them convince service providers to poke holes in their announcements--requests which service providers could easily ignore. It makes multi-homing of end sites more difficult. It imposes no costs on service providers who happily have access to portable addresses, derive additional benefit from a smaller routing table, and share zero cost for either of these benefits. It doesn't require much thought to see why the operations community might be opposed to this. Standards shouldn't merely reflect the interests of those who only make up a portion of the overall Internet community. 3. It makes an extrapolated projection of the IPv6 prefix growth rate, while characterizing that growth based solely on current IPv6 address growth, rather than including the richness of IPv4 experience. The current IPv4 stats tell us that IPv4 table bloat is caused by announcement of disaggregated prefixes that could be aggregated, and by announcement of multiple non-aggregable prefixes by the same AS. A rather draconian policy would be to assert that no AS can ever announce more than one IPv6 prefix. If someone acquires additional prefixes from mergers and acquisitions, they must renumber. It imposes costs on end sites and service providers alike, which is why it would never be adopted. It also forces the AS allocation policy to be the limiting policy for address growth and might put pressure on that policy. But unlike a PA-only policy, it takes into account more factors in routing table growth. Anyway, my point is not to say that my suggestion is better; rather it is intended as a straw man to show how stilted the proposed draft is regarding service providers (#2 above) and our limited IPv6 experience (#3 above). On a more general note, these arguments are best left to the RIRs and their constituents and the NRO--and they are well versed in this topic. Having the IETF get involved at this stage of the game would be counter-productive. On the other hand, having the IETF work on new protocols that scale better would probably be appreciated. michael From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Sep 26 05:15:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 26 Sep 2010 12:45:57 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9E4D6E.2040605@berkeley.edu> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> Message-ID: <20100926124557.12500631@opy.nosense.org> On Sat, 25 Sep 2010 12:28:46 -0700 Michael Sinatra wrote: > On 09/24/10 23:51, Fred Baker wrote: > > I would appreciate opinions from the operators forum; please post > > comments to v6ops at ietf.org. > > > > The IPv6 Operations Working Group has been asked to adopt this > > document as a working group draft. In essence, the outcome would > > become a suggestion to the RIR and *NOG communities regarding the way > > the IETF would suggest that IPv6 prefixes be allocated. Note the use > > of the word "suggest". In summary, what this says is that the IETF > > holds no strong opinions about specific prefix lengths or boundaries, > > but strongly feels that the allocation policies should be scalable - > > which means that PI allocations to edge networks should be done only > > when Really Truly Appropriate. > > > > My question is: is this something that the operational community > > would consider helpful, or is it something the operational community > > would prefer the IETF kept its nose out of? If the operational > > community would find it helpful, is the specific suggestion > > reasonable from an operational perspective? > > I may be a bit of a curmudgeon here, but I think one sentiment you might > hear from the operations community is: "No thank-you. The IETF has > already done more than enough to place obstacles in front of IPv6 > adoption, particularly by 'end sites'. We don't need to add to that." > I'm curious as to what specifically these obstacles are or have been? From drc at virtualized.org Sun Sep 26 05:31:08 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 25 Sep 2010 20:31:08 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926124557.12500631@opy.nosense.org> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: On Sep 25, 2010, at 8:15 PM, Mark Smith wrote: >> I may be a bit of a curmudgeon here, but I think one sentiment you might >> hear from the operations community is: "No thank-you. The IETF has >> already done more than enough to place obstacles in front of IPv6 >> adoption, particularly by 'end sites'. We don't need to add to that." > I'm curious as to what specifically these obstacles are or have been? http://tools.ietf.org/html/rfc5887 Regards, -drc From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Sep 26 06:00:58 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 26 Sep 2010 13:30:58 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: <20100926133058.26d52ab4@opy.nosense.org> On Sat, 25 Sep 2010 20:31:08 -0700 David Conrad wrote: > On Sep 25, 2010, at 8:15 PM, Mark Smith wrote: > >> I may be a bit of a curmudgeon here, but I think one sentiment you might > >> hear from the operations community is: "No thank-you. The IETF has > >> already done more than enough to place obstacles in front of IPv6 > >> adoption, particularly by 'end sites'. We don't need to add to that." > > I'm curious as to what specifically these obstacles are or have been? > > http://tools.ietf.org/html/rfc5887 > So renumbering not being easy is an obstacle that the IETF has put in place to hold back adoption, as per the original assertion? IOW, are you asserting that renumbering is actually easy, but the IETF have chosen to make it hard? Regards, Mark. From drc at virtualized.org Sun Sep 26 07:00:21 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 25 Sep 2010 22:00:21 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926133058.26d52ab4@opy.nosense.org> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> Message-ID: Mark, On Sep 25, 2010, at 9:00 PM, Mark Smith wrote: > So renumbering not being easy is an obstacle that the IETF has put in > place to hold back adoption, as per the original assertion? Apologies for being too terse. Let me try again: One of the issues facing acceptance of IPv6 was initial assertions by the IETF that for the Internet to scale, IPv6 address allocations had to be strictly hierarchical (see RFC 2450 for an example of the mindset). This might (_might_) have been acceptable to end users if the downsides of provider aggregatable addresses had been dealt with. However, as Brian (et al.) documented in the RFC I referenced, one of the key downsides, that renumbering is hard, was not (and still has not been) addressed by the IETF. The result (in my view) was a long period in which the RIRs, attempting to abide by recommendations made by the IETF, did not have policies for allocating address blocks to non-ISPs. Not surprisingly, those non-ISPs indicated the lack of ability to obtain provider independent addressing was a show stopper. Since that time, all of the RIRs now have policies that allow for allocation of provider independent addresses[1]. There are, of course, other examples (lack of DHCP as ISPs were used to/wanted, lack of routing scalability, etc.) but I suspect the inability for enterprises to obtain IPv6 addresses was one of the larger impediment to acceptance of IPv6. > IOW, are you > asserting that renumbering is actually easy, but the IETF have chosen > to make it hard? In my view, the decision by the IETF that identity and location are overloaded into a single value in IPv6 (just like in IPv4) pretty much guarantees renumbering will be hard. The fact that the initial recommendations on address allocation policy made by the IETF ignored the fact that renumbering is hard greatly reduced the desirability of IPv6 to larger scale end users. Does that clarify? Regards, -drc [1] The fact that this is likely to result in routing scalability problems in the long term does not seem to be a major concern. I suspect analogies can be made to CO2 production and global warming, but that rathole isn't particularly relevant here. From tony.li at tony.li Sun Sep 26 07:05:15 2010 From: tony.li at tony.li (Tony Li) Date: Sat, 25 Sep 2010 22:05:15 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> Message-ID: On Sep 25, 2010, at 10:00 PM, David Conrad wrote: > In my view, the decision by the IETF that identity and location are overloaded into a single value in IPv6 (just like in IPv4) pretty much guarantees renumbering will be hard. The fact that the initial recommendations on address allocation policy made by the IETF ignored the fact that renumbering is hard greatly reduced the desirability of IPv6 to larger scale end users. > > Does that clarify? Not really. If I understand your argument, you're suggesting that because the IETF didn't fix renumbering, it doesn't get to insist on aggregation now. I'm just not following the logic. Tony From drc at virtualized.org Sun Sep 26 07:22:10 2010 From: drc at virtualized.org (David Conrad) Date: Sat, 25 Sep 2010 22:22:10 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> Message-ID: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> Tony, On Sep 25, 2010, at 10:05 PM, Tony Li wrote: >> Does that clarify? > Not really. If I understand your argument, you're suggesting that because the IETF didn't fix renumbering, it doesn't get to insist on aggregation now. The protocol doesn't easily support renumbering. As a (non-exclusive) result, provider aggregatable is less desirable (from an enterprise perspective) than provider independent. From my perspective, attempting to "insist on aggregation" (that is, discouraging enterprise PI) implies attempting to define a particular relationship between networks operators. Haven't we been here before? Regards, -drc From fred at cisco.com Sun Sep 26 07:27:55 2010 From: fred at cisco.com (Fred Baker) Date: Sat, 25 Sep 2010 22:27:55 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: On Sep 25, 2010, at 8:31 PM, David Conrad wrote: > On Sep 25, 2010, at 8:15 PM, Mark Smith wrote: >>> I may be a bit of a curmudgeon here, but I think one sentiment you might >>> hear from the operations community is: "No thank-you. The IETF has >>> already done more than enough to place obstacles in front of IPv6 >>> adoption, particularly by 'end sites'. We don't need to add to that." >> I'm curious as to what specifically these obstacles are or have been? > > http://tools.ietf.org/html/rfc5887 OK, so it sounds like Michaels comment was that the IETF has actively make it hard to deploy IPv6. The response is "Renumbering still needs work", and the upshot of the discussion in RFC 4192 ("renumbering a network without a flag day") is that the things that make renumbering hard are the places where people take shortcuts with things magically knowing addresses instead of using names, or put addresses into configuration files. interface foo ipv6 address 2001:0db8::1/32 So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers? Or is there another complaint? I'm serious. If the IETF has actively gotten in the way, there's something we need to fix. If it's something that neither the operators nor the IETF can solve, that's an unfair response. From tony.li at tony.li Sun Sep 26 07:28:47 2010 From: tony.li at tony.li (Tony Li) Date: Sat, 25 Sep 2010 22:28:47 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> Message-ID: <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> On Sep 25, 2010, at 10:22 PM, David Conrad wrote: > The protocol doesn't easily support renumbering. As a (non-exclusive) result, provider aggregatable is less desirable (from an enterprise perspective) than provider independent. From my perspective, attempting to "insist on aggregation" (that is, discouraging enterprise PI) implies attempting to define a particular relationship between networks operators. Haven't we been here before? Yes, we have. However, I'm still unsure as to what recommendation you are making for how we proceed. We have attempted to make many architectural changes, we have recommended renumbering, and all of these have pretty much fallen flat on their face. Yes, we are in the same place that we were before, unsurprisingly. Thus, we need to apply the same band-aids. Tony From fred at cisco.com Sun Sep 26 07:33:52 2010 From: fred at cisco.com (Fred Baker) Date: Sat, 25 Sep 2010 22:33:52 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> Message-ID: <5EE5DE22-74B2-4CBA-93AC-E5D0E7FA9DDD@cisco.com> On Sep 25, 2010, at 10:00 PM, David Conrad wrote: > In my view, the decision by the IETF that identity and location are overloaded into a single value in IPv6 (just like in IPv4) pretty much guarantees renumbering will be hard. The fact that the initial recommendations on address allocation policy made by the IETF ignored the fact that renumbering is hard greatly reduced the desirability of IPv6 to larger scale end users. I agree that identity and location should be separated, and I am in favor of solutions like ILNP that do so. That's actually not a renumbering question - I'll argue that renumbering remains a bear even with network prefix translation, because people will still take shortcuts of various kinds, as discussed in RFC 4192. Network Prefix Translation makes it easier to multihome, but doesn't address what happens when you change stop using a given ISP that gave you a certain prefix, or change the EID on a device (change its NIC card for example), and something else "knows" that the old prefix or EID is the right one. Location/Identity separation doesn't solve human stupidity/laziness. From drc at virtualized.org Sun Sep 26 09:16:46 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 26 Sep 2010 00:16:46 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> Message-ID: <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> Tony, On Sep 25, 2010, at 10:28 PM, Tony Li wrote: >> From my perspective, attempting to "insist on aggregation" (that is, discouraging enterprise PI) implies attempting to define a particular relationship between networks operators. Haven't we been here before? > Yes, we have. However, I'm still unsure as to what recommendation you are making for how we proceed. As I believe others have pointed out, there now exist forums in which address allocation policy is intensively discussed. Those forums have already voted with their feet against exactly what this draft recommends. I guess I don't see what value this draft is going to bring if it progresses to BCP -- have the RIRs given the slightest indication they will revise their policies to match the recommendation? In the past, I believe all of the RIRs have indicated they will do what their members tell them to do. Is the theory that this draft (as a BCP) will convince the RIR members to reverse their decision? As to my recommendation on how to proceed, I believe we need to deal with reality as it is. Reality is that enterprises prefer PI to PA for sound business reasons. One approach forward appropriate for the IETF would be to identify and attempt to address those business reasons within the current architectural constraints (RFC 5887 is one step in that direction). Another way forward for the IETF would be to revise the architecture (see RRG, LISP, ILNP, etc). Another way forward for the IETF (or somebody) to identify where the actual pressures are in routing system growth (TE?, PI?, multi-homing?, spurious deaggregation?) and try to address those specific pressures (See GROW). But you know all this. Pragmatically speaking, I guess I believe the right answer would be to refer the authors to the RIR public policy mechanisms (and trust me when I say you have no idea how ironic me making this statement is). As I learned in the post-2050 IRE days, the IETF isn't the best venue to try to discuss address policy. > Yes, we are in the same place that we were before, unsurprisingly. Thus, we need to apply the same band-aids. Are you expecting a different result? (see Albert Einstein's quote). It isn't a band-aid. It is King Canute waving his hands at the tide. I (as I believe you too) have heard well known router vendors get up in public venues and state there is no immediate routing scalability problem and that they can handle FIBs of 10,000,000 entries today (who am I to dispute these assertions?). According to the projections in the draft, this means today's technology can support routing table loads projected in (call it) 2027. 17 years. Remember what things were like in 1993? From my perspective, there appears to be a disconnect here. Don't get me wrong, as you may be aware, I think routing scalability is a significant issue that needs to be addressed. I just don't see how having the IETF attempt to dictate allocation policy (e.g., "In addition Internet Registries should severely limit or eliminate the amount of PI assignments in order to help facilitate the decrease in routing table growth.") is going to be effective. Regards, -drc From tony.li at tony.li Sun Sep 26 09:59:21 2010 From: tony.li at tony.li (Tony Li) Date: Sun, 26 Sep 2010 00:59:21 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> Message-ID: Hi David, > As I believe others have pointed out, there now exist forums in which address allocation policy is intensively discussed. Those forums have already voted with their feet against exactly what this draft recommends. I guess I don't see what value this draft is going to bring if it progresses to BCP -- have the RIRs given the slightest indication they will revise their policies to match the recommendation? In the past, I believe all of the RIRs have indicated they will do what their members tell them to do. Is the theory that this draft (as a BCP) will convince the RIR members to reverse their decision? Well, as we point out in the draft, the RIRs indirectly work for the IETF. They are obliged to work within the architecture that IETF lays out. > As to my recommendation on how to proceed, I believe we need to deal with reality as it is. Reality is that enterprises prefer PI to PA for sound business reasons. One approach forward appropriate for the IETF would be to identify and attempt to address those business reasons within the current architectural constraints (RFC 5887 is one step in that direction). The IETF doesn't pretend to be involved in economic issues, as you well know. > Another way forward for the IETF would be to revise the architecture (see RRG, LISP, ILNP, etc). Those are in progress, as you well know, but none of our work has yielded anything that appears to be vaguely miraculous. In fact, if anything, it all seems to have fairly long term effects. Given that the problem is now, and even most of the long term solutions require effective, strong aggregation, we need to start moving in that direction. > Another way forward for the IETF (or somebody) to identify where the actual pressures are in routing system growth (TE?, PI?, multi-homing?, spurious deaggregation?) and try to address those specific pressures (See GROW). Those pressures have been enumerated already. Within the v6 space, PI appears to be a substantial contributor. Thus, our proposal. > But you know all this. And you know full well that I've been at the forefront of driving this for a very long time. > Pragmatically speaking, I guess I believe the right answer would be to refer the authors to the RIR public policy mechanisms (and trust me when I say you have no idea how ironic me making this statement is). As I learned in the post-2050 IRE days, the IETF isn't the best venue to try to discuss address policy. Again, we're not here to discuss policy. Our point is about architecture. Policy decides who qualifies for what role. Architecture is deciding how the technical pieces must be put together to scale. > Are you expecting a different result? (see Albert Einstein's quote). It isn't a band-aid. It is King Canute waving his hands at the tide. Actually, the aggregation that we put in place in 1992 was significantly effective. It's not sufficient, but in terms of reducing the growth rate and keeping the table manageable, it has been successful. It is certainly preferable to the unconstrained growth that we saw prior to aggregation. > I (as I believe you too) have heard well known router vendors get up in public venues and state there is no immediate routing scalability problem and that they can handle FIBs of 10,000,000 entries today (who am I to dispute these assertions?). There is no immediate global warming problem, either. You might also ask those same routing vendors what their BGP convergence times for those situations are. ;-) > According to the projections in the draft, this means today's technology can support routing table loads projected in (call it) 2027. 17 years. Remember what things were like in 1993? From my perspective, there appears to be a disconnect here. First, those are NOT projections. We do not have nearly enough data to extrapolate a meaningful rate. The data that we have is effectively a single point: 2009. We present the impact of that rate, so that people understand the qualitative issues at hand, but we cannot reasonably suggest that that is necessarily the outcome. > Don't get me wrong, as you may be aware, I think routing scalability is a significant issue that needs to be addressed. I just don't see how having the IETF attempt to dictate allocation policy (e.g., "In addition Internet Registries should severely limit or eliminate the amount of PI assignments in order to help facilitate the decrease in routing table growth.") is going to be effective. Our goal is to put strong aggregation into effective practice. If we can't do that, then v6 is already dead. It's IETF's job to put into place the Engineering to ensure that v6 does scale. We're trying to help do that. Regards, Tony From michael at rancid.berkeley.edu Sun Sep 26 10:41:51 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 26 Sep 2010 01:41:51 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926124557.12500631@opy.nosense.org> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: <4C9F074F.5060102@rancid.berkeley.edu> On 09/25/10 20:15, Mark Smith wrote: > On Sat, 25 Sep 2010 12:28:46 -0700 > Michael Sinatra wrote: > >> On 09/24/10 23:51, Fred Baker wrote: >>> I would appreciate opinions from the operators forum; please post >>> comments to v6ops at ietf.org. >>> >>> The IPv6 Operations Working Group has been asked to adopt this >>> document as a working group draft. In essence, the outcome would >>> become a suggestion to the RIR and *NOG communities regarding the way >>> the IETF would suggest that IPv6 prefixes be allocated. Note the use >>> of the word "suggest". In summary, what this says is that the IETF >>> holds no strong opinions about specific prefix lengths or boundaries, >>> but strongly feels that the allocation policies should be scalable - >>> which means that PI allocations to edge networks should be done only >>> when Really Truly Appropriate. >>> >>> My question is: is this something that the operational community >>> would consider helpful, or is it something the operational community >>> would prefer the IETF kept its nose out of? If the operational >>> community would find it helpful, is the specific suggestion >>> reasonable from an operational perspective? >> >> I may be a bit of a curmudgeon here, but I think one sentiment you might >> hear from the operations community is: "No thank-you. The IETF has >> already done more than enough to place obstacles in front of IPv6 >> adoption, particularly by 'end sites'. We don't need to add to that." >> > > I'm curious as to what specifically these obstacles are or have been? The thread has moved a bit beyond this topic, but I think it's useful to go over this, since my statement has been characterized as stating the the IETF has deliberately put obstacles in the way of v6 adoption. While there probably are some in the ops community that believe this, I don't quite agree. However, regardless of the intent of the IETF, IPv6 adoption has been less than seamless (to say the least), and the IETF bears some responsibility for that, despite their good efforts (more on that later). Obstacle 1: IPv6 is on-the-wire incompatible with IPv4. This has been pointed out by many others (including Randy Bush in his various IPv6 vs. Operational Reality presentations), but the point still stands. Could the IETF have created a protocol that was sufficiently compatible? I honestly don't know, but the IETF is ultimately responsible for IPv6 and for asking the operations community to adopt an incompatible protocol. I think it's reasonable for the ops community to make a good faith effort to adopt, but that brings us to obstacle 2. Obstacle 2: IPv6 was designed to be massively aggregable with only PA addressing. However, no reasonable mechanism was ever deployed or even proffered to deal with multi-homing and the routing policy derived from that (cf. shim6), nor for renumbering (cf. A6 DNS records). I actually agree with Fred that ILNP and even stateless prefix translation are promising, but we have to move forward now with the IPv6 we have, not the one we want. While this probably isn't the IETF's fault, a reasonable response from the ops community is "so you want me to deploy this thing, but it is incompatible *and* it doesn't give me as much freedom to multi-home and change providers as IPv4 does. Great!" Obstacle 3: IPv6 was designed with service-providers, not end-users, in mind. Keep in mind that I am actually coming at this from a service-provider perspective. As I said before, IPv6's PA-only addressing architecture imposes more costs on end users and generates more benefit for service-providers. There simply hasn't been incentive for end sites to adopt IPv6, and that's led to a situation where IPv6 adoption is well behind where most of us think it needs to be. The RIRs have responded to these obstacles in pretty much the only way they can: In response to the demands of their paying members, they have liberalized the PI assignment of IPv6 address space. There is no disagreement that this has serious implications for the DFZ routing table. There is also no disagreement that this is a critical time, and the previous anemic adoption of IPv6 has been a big problem given the current state of IPv4 address run-out. I don't fault the IETF for producing these obstacles in the first place. What I do fault the IETF for doing is for essentially ignoring the obstacles and how the ops community has attempted to overcome them and insisting that we go back the the beginning with an essentially PA-only IPv6 Internet. michael From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Sep 26 10:44:08 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 26 Sep 2010 18:14:08 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: <20100926181408.2af7353f@opy.nosense.org> On Sat, 25 Sep 2010 22:27:55 -0700 Fred Baker wrote: > > On Sep 25, 2010, at 8:31 PM, David Conrad wrote: > > > On Sep 25, 2010, at 8:15 PM, Mark Smith wrote: > >>> I may be a bit of a curmudgeon here, but I think one sentiment you might > >>> hear from the operations community is: "No thank-you. The IETF has > >>> already done more than enough to place obstacles in front of IPv6 > >>> adoption, particularly by 'end sites'. We don't need to add to that." > >> I'm curious as to what specifically these obstacles are or have been? > > > > http://tools.ietf.org/html/rfc5887 > > OK, so it sounds like Michaels comment was that the IETF has actively make it hard to deploy IPv6. The response is "Renumbering still needs work", and the upshot of the discussion in RFC 4192 ("renumbering a network without a flag day") is that the things that make renumbering hard are the places where people take shortcuts with things magically knowing addresses instead of using names, or put addresses into configuration files. > > interface foo > ipv6 address 2001:0db8::1/32 > > So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers? Or is there another complaint? > > I'm serious. If the IETF has actively gotten in the way, there's something we need to fix. If it's something that neither the operators nor the IETF can solve, that's an unfair response. I agree, which is why I asked the question. I think the IETF has done most of what it does - provide protocol specifications that can be implemented. A lot of vendors have implemented them, and they've been mostly subversively deployed because IPv6 has been shipped in products by default in a lot of cases. My opinion is that the lack of IPv6 deployment by operators is primarily apathy - the problem has been a long way off for a long time, so there has been quite a lot of "talk about it" in the operator community, but not all that much action. Then, two or so years (i.e. in the last six months) before there is a real impact that is within short term planning time frames for organisations, there is now a flurry of action. Sounds exactly like the timeline of what happened with Y2K. The unfortunate thing about this time frame is that the opportunity for a smooth migration away from IPv4 has disappeared, so now we're going to have to put up with IPv4 getting even worse as we try to stretch the life of it's address space even further via large scale NAT etc. Regards, Mark. From michael at rancid.berkeley.edu Sun Sep 26 11:11:39 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 26 Sep 2010 02:11:39 -0700 Subject: Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9E52C2.5070502@gmail.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4DB3.3040704@rancid.berkeley.edu> <4C9E52C2.5070502@gmail.com> Message-ID: <4C9F0E4B.7080204@rancid.berkeley.edu> On 09/25/10 12:51, Brian E Carpenter wrote: > Michael, > > Again, cross-posting to v6ops - I think your arguments must be discussed > there. (Normally, I avoid cross-posting like the plague.) > > Three comments on your points below: > > 1. I agree that it is not the IETF's place to assert policy > in this area. Actually we are not supposed to, under the terms > of RFC2860 (which, as it happens, Fred and I both signed in ink). > > 2. But it is our place to document the technical implications > of various alternatives, as they affect the future scaling of > the Internet. It's certainly correct that the operator community > has most of the data and experience, of course. So I would > advocate that any IETF document in this area is written with > the benefit of that experience, and that it keeps away from > asserting policy. I heartily agree, and I would support a statement from the IETF that carefully laid out the implications. I think these are well-known in the ops community, but it doesn't hurt to say them again. However, I also think the IETF can do better than say "let's go back to the good old PA days." Either offer a set of solutions (including perhaps something that limits how many prefixes an AS can orginate in IPv6). The shift toward PA addressing can be one of several options. Then let the ops communities and RIRs choose the options. The other possibility is to keep quiet and let the other communities come up with options. > 3. Finally, you say: > >>> On the other hand, having the IETF work on new >>> protocols that scale better would probably be appreciated. > > Er, yes, but see my previous message - we've been on this > topic in the IRTF and IETF for ten years and more, and it's hard. You'll get no argument here. The general issue of providing a massively scalable address space while limiting the DFZ routing table is a very hard one--and it demands difficult solutions. I very much appreciate the work the IETF is doing toward this end. At the same time, I don't think the current draft under consideration moves us any closer to solving the problem. michael From gert at space.net Sun Sep 26 11:18:46 2010 From: gert at space.net (Gert Doering) Date: Sun, 26 Sep 2010 11:18:46 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> Message-ID: <20100926091846.GU32268@Space.Net> Hi, On Sun, Sep 26, 2010 at 12:59:21AM -0700, Tony Li wrote: > Well, as we point out in the draft, the RIRs indirectly work for the IETF. Now that's an interesting statement. I always thought that the RIRs work for their members. > They are obliged to work within the architecture that IETF lays out. As long as the IETF creates an architecture that enables the RIRs and the members to actually make good use of the technology, I can see good coorporation happen. (Obligation? Where is this written down? Signed by whom?). If the IETF tries to mandate something that the RIR members don't accept, what then? [..] > The IETF doesn't pretend to be involved in economic issues, as you well know. Address allocation is massively influenced by economic factors. So trying to dictate allocation policy and at the same time claiming "economics are of no interest to us" is FAIL. (The IETF tried this before, with the "there must only be 8192 TLAs in the default-free zone" approach - and never came up with any guidance that enabled anyone to decide who is big enough to receive a TLA, and who has to adjust their business model to "no, you are too small, base your whole ISP operation on 3rd-party space". FAIL.). > Again, we're not here to discuss policy. Our point is about > architecture. Policy decides who qualifies for what role. Architecture > is deciding how the technical pieces must be put together to scale. So, where is the bit in an IPv6 header that says "this address is PA" and "that address is PI"? >From an architecture point of view, both PI and PA are just "blocks of addresses used to number devices and visible in the global routing table". The difference is purely policy-wise: what strings are attached to this specific block of addresses, what price tag is attached. Now, I'm not saying that PI is the "right" or "only" way forward - but some of the statements made above just don't reflect my pocket of reality. Gert Doering -- RIPE address policy wrangler -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From fred at cisco.com Sun Sep 26 20:00:06 2010 From: fred at cisco.com (Fred Baker) Date: Sun, 26 Sep 2010 11:00:06 -0700 Subject: draft-ietf-v6ops-tunnel-loops WGLC Message-ID: <6065153E-6C9A-4625-9C72-CC652F754032@cisco.com> The IETF IPv6 Operations Working Group is initiating a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Gabi Nakibly, Fred Templin, 11-Sep-10 If you find issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to v6ops at ietf.org. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100926/578c3e0c/attachment.html From tony.li at tony.li Sun Sep 26 20:14:58 2010 From: tony.li at tony.li (Tony Li) Date: Sun, 26 Sep 2010 11:14:58 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926091846.GU32268@Space.Net> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> Message-ID: <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> Hi Gert, >> They are obliged to work within the architecture that IETF lays out. > > As long as the IETF creates an architecture that enables the RIRs and > the members to actually make good use of the technology, I can see good > coorporation happen. (Obligation? Where is this written down? Signed > by whom?). RFC 2860. As quoted in our draft: The MoU directs IANA to comply with "the criteria and procedures specified in RFCs, including Proposed, Draft, and full Internet Standards and Best Current Practice documents" (section 4.1). > If the IETF tries to mandate something that the RIR members don't accept, > what then? I'm very hopeful that we don't have to explore that path. > Address allocation is massively influenced by economic factors. So trying > to dictate allocation policy and at the same time claiming "economics are > of no interest to us" is FAIL. Again, there is a separation between policy and architecture. No one is trying to dictate anything, we're simply trying to agree on a scalable architecture. It is in everyone's interest to have a sustainable Internet and in no one's interest to see it collapse. Tony From paul at timmins.net Sun Sep 26 22:20:20 2010 From: paul at timmins.net (Paul Timmins) Date: Sun, 26 Sep 2010 16:20:20 -0400 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926091846.GU32268@Space.Net> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> Message-ID: <4C9FAB04.3050308@timmins.net> Gert Doering wrote: >> They are obliged to work within the architecture that IETF lays out. >> > If the IETF tries to mandate something that the RIR members don't accept, > what then? > And as a RIR member who needs to see IPv6 adoption happen, I'll expend all my available resources in that arena to ensure that a return to this 'only ISPs can have PI addressing' nonsense dies a quick death. And I say that as an ISP. My customers need more reasons to migrate, not less. >> The IETF doesn't pretend to be involved in economic issues, as you well know. >> > Address allocation is massively influenced by economic factors. So trying > to dictate allocation policy and at the same time claiming "economics are > of no interest to us" is FAIL. > > (The IETF tried this before, with the "there must only be 8192 TLAs in > the default-free zone" approach - and never came up with any guidance > that enabled anyone to decide who is big enough to receive a TLA, and who > has to adjust their business model to "no, you are too small, base your > whole ISP operation on 3rd-party space". FAIL.). > Double fail, and as an ISP that has grown drastically in the last 3 years, I'm glad that died a quick death. I've already renumbered my network once, back when it truly was small. Never again. >> Again, we're not here to discuss policy. Our point is about >> architecture. Policy decides who qualifies for what role. Architecture >> is deciding how the technical pieces must be put together to scale. [snip] >> >From an architecture point of view, both PI and PA are just "blocks of >> addresses used to number devices and visible in the global routing table". >> >> The difference is purely policy-wise: what strings are attached to this >> specific block of addresses, what price tag is attached. >> >> Now, I'm not saying that PI is the "right" or "only" way forward - but some of >> the statements made above just don't reflect my pocket of reality Too many times I hear IETF members saying 'we need more input from the operations community, you all should join our mailing lists'. This to me poses 2 obvious issues: 1) You recognize you are making decisions in a vacuum and do it anyway 2) The burden is on the people doing this stuff every day to make sure some ivory tower policy doesn't pop out of nowhere and stomp on whatever they were doing to get stuff done. I propose the IETF do two things to help scalability: 1) Sit on their hands. Until they know what's happening out here, any policy making is completely stupid. 2) Listen to what people are saying. I hear all sorts of terrible arguments for why IPv6 should have NAT. I disagree this should happen. I *do* agree the customers shouldn't have to renumber their entire networks every time they switch IPs. There are currently two ways of doing this: a) NAT b) Large scale PI distribution, for free, so networks can get stable addressing. As much as I favor the vendor lockin that forcing my customers to use my space on their internal networks creates, I want them to see the benefits, and I don't want them locked into SOMEONE ELSE'S PA space. So if the IETF wants to do something, solve that dictomy and we'll be much further along. and As for the routing table growth? Well, IPv6 has the above problem, either we need NAT or PI addresses for everyone before the majority of businesses will accept it. So if we're going forward, let's either decide to create a standard way to do NAT, and a way to detect it, and a way to request translations. Individual sites can decide to restrict the ability to request translations, sure, that's their right, but that will give me ammo as an operator to explain who just broke protocol X (them, as they're not fully implementing the RFC) Or let's give everyone PI space and find a good protocol to aggregate it where possible. As far as routing bloat without changes to this policy, that is a self fixing problem. Currently we are announcing 4 IP blocks via BGP, and will probably be announcing 6 before we start to not need them anymore, or maybe even more. Under IPv6 we will need one. That's a 6:1 aggregation ratio just by switching to IPv6. Not bad! And quite representative of the internet as a whole. The slow start policies the RIRs had to use kept them from giving us a /18 to start with, so now we have two /21s, a /20, and a /22. -Paul From spz at serpens.de Sun Sep 26 22:26:49 2010 From: spz at serpens.de (S.P.Zeidler) Date: Sun, 26 Sep 2010 22:26:49 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: <20100926202647.GD27830@serpens.de> Hi, Thus wrote Fred Baker (fred at cisco.com): > OK, so it sounds like Michaels comment was that the IETF has actively make it hard to deploy IPv6. The response is "Renumbering still needs work", and the upshot of the discussion in RFC 4192 ("renumbering a network without a flag day") is that the things that make renumbering hard are the places where people take shortcuts with things magically knowing addresses instead of using names, or put addresses into configuration files. > > interface foo > ipv6 address 2001:0db8::1/32 > > So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers? Or is there another complaint? > > I'm serious. If the IETF has actively gotten in the way, there's something we need to fix. If it's something that neither the operators nor the IETF can solve, that's an unfair response. No NAT at present is my greatest problem. I am currently in charge of a network that is multihomed in v4 using PA spaces from 5 different uplinks. Different uplinks are supposed to carry traffic to different destinations, and I need to be able to failover fairly quickly if one link goes down. For IPv6, at present, I'll have to pray that all the hosts in my network actually are RFC4191 type C hosts and don't collect too many bugs around it, not now and not with any future update, where I don't have control over when they update (or to what). Instead of having a routing decision made at the pair of inner firewalls, I get a zoo that hopefully will get it right. If they don't, they'll use the wrong originating prefix and the communication will die at the next filtering router, and I will have no ends of fun. If I could get the wish fairy to attend, I'd get RFC1493 addresses internally, and a stateless prefix NAT of whatever kind by the firewalls that lets the firewalls make sure that routing works as it should. (ILNP sounds fine but has the drawback that it only allows locator changes when the responder does ILNP too). regards, spz -- spz at serpens.de (S.P.Zeidler) From nick at foobar.org Sun Sep 26 22:58:34 2010 From: nick at foobar.org (Nick Hilliard) Date: Sun, 26 Sep 2010 22:58:34 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> Message-ID: <4C9FB3FA.3050908@foobar.org> Tony, Several comments. 1: declaring that PI is bad without providing a viable alternative is really not a credible proposition. We know PI is bad. Every piece of documentation related to PI assignment states this in black and white. PI is used, not because we like it, but because there is no alternative if you need to multi-home your network. What we need from the IETF is a functional multi-homing protocol, not finger wagging about a policy practice to make up for the lack of such a protocol. 2: Ignoring the personality issues which are clouding this discussion, I believe Randy and others are correct in pointing out that address allocation is not the business of the IETF. The critical part of this I-D is the section entitled "Recommendations" which is a very clear statement on the topic of addressing policy. Here's a positive suggestion: if you word it differently, the draft may work better. E.g. if you tabulate the baseline ipv6 PA allocation and PI assignment sizes from each of the RIRs, then note that they are - or are not - compatible with the routing / architectural issues noted in the document, and that should any move occur to change these standard block sizes, that the architectural concerns of this document or its successor should be noted. Would this not say what needs to be said, except that you're no longer issuing a policy directive? 3: Where did you pull the /32 and /48 figures from? And don't answer "from current addressing policy, of course" :-) If you're going to make a specific technical recommendation from the point of view of architectural and technical concerns, would it not be advisable to give specific reasons for the exact numbers chosen, without so obviously looking into the can to see what address registries are already doing? 4: Section 2 does not belong in this document. 5: Section 4 is not useful, as worded. As operators, we understand that aggregation is a good thing. Could this not be reworded in one short paragraph, or else simple references to RFC 4632? 6: Section 6.2 is a straw man. Given that other people appear to be taking the position that there are ivory tower characteristics appearing in this document, creating a straw man position like this is unlikely to be useful to the worthy cause of aggregation. 7: Not sure why sections 7 or 8 are necessary? 8: The recommendations rfc 4632 are _radically_ different to the recommendations of this I-D. It is simply not correct to note in section 14: "Much of that work has been incorporated directly into this document as it is conceptually identical and simply translated to IPv6 herein." Nick From joelja at bogus.com Sun Sep 26 19:29:49 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 26 Sep 2010 10:29:49 -0700 Subject: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9F0E4B.7080204@rancid.berkeley.edu> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4DB3.3040704@rancid.berkeley.edu> <4C9E52C2.5070502@gmail.com> <4C9F0E4B.7080204@rancid.berkeley.edu> Message-ID: <8C361336-9F9B-4E5B-9570-D008C2B4502B@bogus.com> On Sep 26, 2010, at 2:11, Michael Sinatra wrote: > On 09/25/10 12:51, Brian E Carpenter wrote: >> Michael, >> >> Again, cross-posting to v6ops - I think your arguments must be discussed >> there. (Normally, I avoid cross-posting like the plague.) >> >> Three comments on your points below: >> >> 1. I agree that it is not the IETF's place to assert policy >> in this area. Actually we are not supposed to, under the terms >> of RFC2860 (which, as it happens, Fred and I both signed in ink). >> >> 2. But it is our place to document the technical implications >> of various alternatives, as they affect the future scaling of >> the Internet. It's certainly correct that the operator community >> has most of the data and experience, of course. So I would >> advocate that any IETF document in this area is written with >> the benefit of that experience, and that it keeps away from >> asserting policy. > > I heartily agree, and I would support a statement from the IETF that carefully laid out the implications. I think these are well-known in the ops community, but it doesn't hurt to say them again. > > However, I also think the IETF can do better than say "let's go back to the good old PA days." Either offer a set of solutions (including perhaps something that limits how many prefixes an AS can orginate in IPv6). Given that there's no real bound on getting additional ASes I'm not sure that heading down that road has the implication you think it does. Someone who qualifies for one as qualifies for more. > The shift toward PA addressing can be one of several options. Networks that need to multi home in v4 are going to need to in v6. So long as we acknowledge that reality we're fine. > Then let the ops communities and RIRs choose the options. The other possibility is to keep quiet and let the other communities come up with options. > >> 3. Finally, you say: >> >>>> On the other hand, having the IETF work on new >>>> protocols that scale better would probably be appreciated. >> >> Er, yes, but see my previous message - we've been on this >> topic in the IRTF and IETF for ten years and more, and it's hard. > > You'll get no argument here. The general issue of providing a massively scalable address space while limiting the DFZ routing table is a very hard one--and it demands difficult solutions. I very much appreciate the work the IETF is doing toward this end. At the same time, I don't think the current draft under consideration moves us any closer to solving the problem. > > michael > _______________________________________________ > v6ops mailing list > v6ops at ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Sep 27 01:00:13 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 27 Sep 2010 08:30:13 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9FAB04.3050308@timmins.net> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> Message-ID: <20100927083013.428c58be@opy.nosense.org> On Sun, 26 Sep 2010 16:20:20 -0400 Paul Timmins wrote: > Gert Doering wrote: > >> They are obliged to work within the architecture that IETF lays out. > >> > > If the IETF tries to mandate something that the RIR members don't accept, > > what then? > > > And as a RIR member who needs to see IPv6 adoption happen, I'll expend > all my available resources in that arena to ensure that a return to this > 'only ISPs can have PI addressing' nonsense dies a quick death. > > And I say that as an ISP. My customers need more reasons to migrate, not > less. > >> The IETF doesn't pretend to be involved in economic issues, as you well know. > >> > > Address allocation is massively influenced by economic factors. So trying > > to dictate allocation policy and at the same time claiming "economics are > > of no interest to us" is FAIL. > > > > (The IETF tried this before, with the "there must only be 8192 TLAs in > > the default-free zone" approach - and never came up with any guidance > > that enabled anyone to decide who is big enough to receive a TLA, and who > > has to adjust their business model to "no, you are too small, base your > > whole ISP operation on 3rd-party space". FAIL.). > > > Double fail, and as an ISP that has grown drastically in the last 3 > years, I'm glad that died a quick death. I've already renumbered my > network once, back when it truly was small. Never again. > >> Again, we're not here to discuss policy. Our point is about > >> architecture. Policy decides who qualifies for what role. Architecture > >> is deciding how the technical pieces must be put together to scale. > [snip] > >> >From an architecture point of view, both PI and PA are just "blocks of > >> addresses used to number devices and visible in the global routing table". > >> > >> The difference is purely policy-wise: what strings are attached to this > >> specific block of addresses, what price tag is attached. > >> > >> Now, I'm not saying that PI is the "right" or "only" way forward - but some of > >> the statements made above just don't reflect my pocket of reality > Too many times I hear IETF members saying 'we need more input from the > operations community, you all should join our mailing lists'. > > This to me poses 2 obvious issues: > 1) You recognize you are making decisions in a vacuum and do it anyway > 2) The burden is on the people doing this stuff every day to make > sure some ivory tower policy doesn't pop out of nowhere and stomp on > whatever they were doing to get stuff done. > > I propose the IETF do two things to help scalability: > 1) Sit on their hands. Until they know what's happening out here, > any policy making is completely stupid. > 2) Listen to what people are saying. I hear all sorts of terrible > arguments for why IPv6 should have NAT. I disagree this should happen. I > *do* agree the customers shouldn't have to renumber their entire > networks every time they switch IPs. There are currently two ways of > doing this: > a) NAT > b) Large scale PI distribution, for free, so networks can get > stable addressing. Your "currently" doesn't seem to include IPv6's preferred and valid address lifetime methods, used to phase addressing in and out over time, and ULAs to create stable internal addressing independent of their current global addressing. This is one problem that some operators need to work on - they sprout off about how IPv6 should work and what the IETF has done wrong with it, yet don't seem to know how it actually does work. And just in case somebody accuses me of living in a fantasy land, phasing address spaces in and out and ULAs aren't perfect, but then neither is NAT and PI. It's about picking the compromises you're willing to make. I've personally made enough with NAT, so I want to see it die. > As much as I favor the vendor lockin that forcing my customers to > use my space on their internal networks creates, I want them to see the > benefits, and I don't want them locked into SOMEONE ELSE'S PA space. > > So if the IETF wants to do something, solve that dictomy and we'll be > much further along. > and > As for the routing table growth? Well, IPv6 has the above problem, > either we need NAT or PI addresses for everyone before the majority of > businesses will accept it. > > So if we're going forward, let's either decide to create a standard way > to do NAT, and a way to detect it, and a way to request translations. > Individual sites can decide to restrict the ability to request > translations, sure, that's their right, but that will give me ammo as an > operator to explain who just broke protocol X (them, as they're not > fully implementing the RFC) > > Or let's give everyone PI space and find a good protocol to aggregate it > where possible. > > As far as routing bloat without changes to this policy, that is a self > fixing problem. Currently we are announcing 4 IP blocks via BGP, and > will probably be announcing 6 before we start to not need them anymore, > or maybe even more. > > Under IPv6 we will need one. That's a 6:1 aggregation ratio just by > switching to IPv6. Not bad! And quite representative of the internet as > a whole. > > The slow start policies the RIRs had to use kept them from giving us a > /18 to start with, so now we have two /21s, a /20, and a /22. > > -Paul From brian.e.carpenter at gmail.com Mon Sep 27 01:09:19 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 27 Sep 2010 12:09:19 +1300 Subject: "Compatible on the wire" myth [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4C9F074F.5060102@rancid.berkeley.edu> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <4C9F074F.5060102@rancid.berkeley.edu> Message-ID: <4C9FD29F.70502@gmail.com> On 2010-09-26 21:41, Michael Sinatra wrote: .... > Obstacle 1: IPv6 is on-the-wire incompatible with IPv4. This has been > pointed out by many others (including Randy Bush in his various IPv6 vs. > Operational Reality presentations), but the point still stands. Could > the IETF have created a protocol that was sufficiently compatible? Ever since I saw that slide of Randy's, it has been bothering me greatly. Randy isn't known for propagating myths, but this is a myth. An IPv4 host has no way to deal with an incoming packet that doesn't conform to RFC 791. It has no way to deal with a version number other than 4, and it has no way to deal with a destination address that (unknown to it) is longer than 32 bits. There is no such thing as an IP protocol with extended addressing that is on-the-wire compatible with IPv4. There are many ways we could have extended addressing to more than 32 bits with fewer changes than introduced by IPv6, but *none* of them would be on-the-wire compatible with IPv4. In retrospect, I wish we'd made fewer changes, but let's not turn that into a myth that we could have been backwards compatible at layer 3 without dual stack or NAT/PT. Brian From paul at timmins.net Mon Sep 27 01:11:17 2010 From: paul at timmins.net (Paul Timmins) Date: Sun, 26 Sep 2010 19:11:17 -0400 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100927083013.428c58be@opy.nosense.org> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> Message-ID: <4C9FD315.6030301@timmins.net> Mark Smith wrote: > Your "currently" doesn't seem to include IPv6's preferred and valid > address lifetime methods, used to phase addressing in and out over > time, and ULAs to create stable internal addressing independent of > their current global addressing. > > This is one problem that some operators need to work on - > they sprout off about how IPv6 should work and what the IETF has done > wrong with it, yet don't seem to know how it actually does work. > > And just in case somebody accuses me of living in a fantasy land, > phasing address spaces in and out and ULAs aren't perfect, but > then neither is NAT and PI. It's about picking the compromises you're > willing to make. I've personally made enough with NAT, so I want to see > it die. > Mechanisms of which I'm very aware, however there are 3 problems: 1) When we switch over the network of a customer, they often require a flag day due to how the losing carrier processes orders (usually porting out all the voice on a circuit is a signal to cut off the internet as well on an integrated T1 circuit. Changing this is sometimes possible with a large 'change fee' from the losing carrier who no longer has any incentive to play nice, or often is simply impossible (due to the TRRO, as soon as you cut off our voice circuits, we can't legally leave it in place for internet in many places, so we fit unavoidably into column B on that one.) 2) We generally don't control the customer's routers, so any change we make must be coordinated with them, the more complex, the more reasons the customer will say 'oh, let's just table this, we have bigger items on our plate and who knows what this will break and where the addresses are hardcoded'. 3) Unless the customer is ubiquitously running DHCPv6, changing things like their active directory servers and other things is very, very risky for their network stability. To say nothing of things like medical diagnostic equipment and other weird and esoteric devices on customer networks we come across all the time which undoubtedly have hardcoded addresses in them for one reason or another, for reasons good or bad. Most of our customers can barely hack running one set of valid addresses, having ULA and public will be confusing as hell for them. --Paul From brian.e.carpenter at gmail.com Mon Sep 27 01:15:46 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Mon, 27 Sep 2010 12:15:46 +1300 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> Message-ID: <4C9FD422.5090308@gmail.com> On 2010-09-27 07:14, Tony Li wrote: > Hi Gert, > >>> They are obliged to work within the architecture that IETF lays out. >> As long as the IETF creates an architecture that enables the RIRs and >> the members to actually make good use of the technology, I can see good >> coorporation happen. (Obligation? Where is this written down? Signed >> by whom?). > > > RFC 2860. As quoted in our draft: > > The MoU directs IANA to comply with "the criteria and procedures > specified in RFCs, including Proposed, Draft, and full Internet > Standards and Best Current Practice documents" (section 4.1). True, but also: 4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU. That was a specific exemption without which I don't believe ICANN would ever have signed the MoU. Brian (IAB Chair when the MoU was signed) From fred at cisco.com Mon Sep 27 02:36:46 2010 From: fred at cisco.com (Fred Baker) Date: Sun, 26 Sep 2010 17:36:46 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100926202647.GD27830@serpens.de> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926202647.GD27830@serpens.de> Message-ID: On Sep 26, 2010, at 1:26 PM, S.P.Zeidler wrote: > If I could get the wish fairy to attend, I'd get RFC1493 addresses > internally, and a stateless prefix NAT of whatever kind by the > firewalls that lets the firewalls make sure that routing works as > it should. (ILNP sounds fine but has the drawback that it only allows > locator changes when the responder does ILNP too). 1493 is managed objects for bridges. Do you mean ULAs (RFC 4193)? So - you would be in favor of something like http://tools.ietf.org/html/draft-mrw-behave-nat66 That particular model has a down side, in that to make the checksums work end to end we update the prefix or the EID, which makes session switchover less seamless. But it requires no change to the host. From michael at rancid.berkeley.edu Mon Sep 27 03:39:23 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 26 Sep 2010 18:39:23 -0700 Subject: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <8C361336-9F9B-4E5B-9570-D008C2B4502B@bogus.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4DB3.3040704@rancid.berkeley.edu> <4C9E52C2.5070502@gmail.com> <4C9F0E4B.7080204@rancid.berkeley.edu> <8C361336-9F9B-4E5B-9570-D008C2B4502B@bogus.com> Message-ID: <4C9FF5CB.5090805@rancid.berkeley.edu> On 09/26/10 10:29, Joel Jaeggli wrote: > Given that there's no real bound on getting additional ASes I'm not > sure that heading down that road has the implication you think it > does. Someone who qualifies for one as qualifies for more. Agreed. That was part of what I was getting at when I talked about pressure on AS allocation policy. > >> The shift toward PA addressing can be one of several options. > > Networks that need to multi home in v4 are going to need to in v6. So > long as we acknowledge that reality we're fine. Agreed. michael From tony.li at tony.li Mon Sep 27 09:15:06 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 00:15:06 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4C9FD422.5090308@gmail.com> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> Message-ID: <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> > True, but also: > > 4.3. Two particular assigned spaces present policy issues in addition > to the technical considerations specified by the IETF: the assignment > of domain names, and the assignment of IP address blocks. These > policy issues are outside the scope of this MOU. > > That was a specific exemption without which I don't believe ICANN > would ever have signed the MoU. Agreed. Once again, we are trying to agree on an addressing architecture, not policy. Tony From spz at serpens.de Mon Sep 27 10:14:05 2010 From: spz at serpens.de (S.P.Zeidler) Date: Mon, 27 Sep 2010 10:14:05 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926202647.GD27830@serpens.de> Message-ID: <20100927081357.GE27830@serpens.de> Thus wrote Fred Baker (fred at cisco.com): > On Sep 26, 2010, at 1:26 PM, S.P.Zeidler wrote: > > > If I could get the wish fairy to attend, I'd get RFC1493 addresses > > internally, and a stateless prefix NAT of whatever kind by the > > firewalls that lets the firewalls make sure that routing works as > > it should. (ILNP sounds fine but has the drawback that it only allows > > locator changes when the responder does ILNP too). > > 1493 is managed objects for bridges. Do you mean ULAs (RFC 4193)? augh, what a stupid typo. Yes, of course ULA. :) > So - you would be in favor of something like http://tools.ietf.org/html/draft-mrw-behave-nat66 I like ILNP better in principle (also because I can see an immediate use for any laptop with both wireless and wired connectivity :), but I need something 'soonish' that doesn't require more of the hosts than What Everybody Does (tm), and I'm pretty sure having two dozen routes announced to hosts via router advertisements is going to be on the eccentric side. It's just a question in how many variants of equipment you need to know and control bugs in little used code paths. The practical solution (in the absence of NAT) is to go "there are some hosts that have the proper statically assigned addresses and routes to specific destinations because there is a business reason that was sufficiently known in advance to give them that, and there are proxies. Everything else moves inside the local network and the VPNs or is out of luck.", ie significantly less connectivity. The slightly impractical but quite possible solution is to ignore the absence of IETF guidance regarding prefix translation and Just Do It, since the outside world doesn't need to know about and cooperate on it for a lot of cases. > That particular model has a down side, in that to make the checksums work end to end we update the prefix or the EID, which makes session switchover less seamless. But it requires no change to the host. Switchover in case of link failure will be 'traumatic' since the outside prefix changes. That's always annoying but not necessarily a big issue. Switchover from one router/firewall to the other should not change the translation seen if the implementation of the prefix translator is the same, right? I'm likely not getting what you are referring to. regards, spz -- spz at serpens.de (S.P.Zeidler) From fernando at gont.com.ar Mon Sep 27 10:10:27 2010 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 27 Sep 2010 05:10:27 -0300 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <95AFC34C-B796-408D-A5CA-B6E17E678EFE@doubleshotsecurity.com> References: <4C99C331.4040507@gont.com.ar> <95AFC34C-B796-408D-A5CA-B6E17E678EFE@doubleshotsecurity.com> Message-ID: <4CA05173.7050604@gont.com.ar> Hi, Merike, Please find my comments inline... > Here's two pointers that may help: > > http://www.juniper.net/techpubs/en_US/junos9.4/topics/concept/cos-ipv6-protocols-overview-solution.html > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-qos.html > [especially the troubleshooting part] These two pointers are about diffserv (which is *not* what I was looking for). I was asking about processing the IPv6 Traffic Class as in the original IPv4 ToS definition (e.g., strict precedence-ordered queuing, based on the Precedence field of the ToS, etc.) Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gert at space.net Mon Sep 27 11:33:10 2010 From: gert at space.net (Gert Doering) Date: Mon, 27 Sep 2010 11:33:10 +0200 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> Message-ID: <20100927093310.GX32268@Space.Net> Hi, On Mon, Sep 27, 2010 at 12:15:06AM -0700, Tony Li wrote: > > That was a specific exemption without which I don't believe ICANN > > would ever have signed the MoU. > > Agreed. Once again, we are trying to agree on an addressing > architecture, not policy. The statement "*you* get your own globally visible chunk of address space, and *you* don't" sounds very much like what we have in our policy documents. So maybe something could explain to the non-native speakers on this list what the distinction between "addressing architecture" and "address policy" is. curious, Gert Doering -- RIPE Address Policy Wrangler -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100927/e210d27b/attachment.bin From cfriacas at fccn.pt Mon Sep 27 13:02:58 2010 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 27 Sep 2010 12:02:58 +0100 (WEST) Subject: SNOM VoIP Phones, Where are my RAs? In-Reply-To: <20100927093310.GX32268@Space.Net> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> Message-ID: Hi list, Is anybody using SNOM 300 VoIP phones? We're seeing RAs vanish when they were supposed to cross to the wired network bridged port. Already tested some firmware versions. Regards, Carlos From drc at virtualized.org Mon Sep 27 02:34:49 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 26 Sep 2010 20:34:49 -0400 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: Fred, On Sep 26, 2010, at 1:27 AM, Fred Baker wrote: > So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers? This is somewhat beside the point as the die has already been cast, but I believe you are unfairly glossing over some of the difficulties implicit in the choice to bind the locator and identifier into the same object. For example, the fact that transport-layer connections must be terminated when changing network topologic location means that it is impossible to maintain connection over those network change events. This has nothing to do with human stupidity/laziness. > Or is there another complaint? I believe the original complaint was that some folks in the IETF have in the past ignored operators' input and the current draft appears to be repeating that pattern. The fact that renumbering remains challenging is a symptom. Apologies that my terseness in my response was insufficient to get my point across. Lesson learned. > I'm serious. If the IETF has actively gotten in the way, there's something we need to fix. The IETF frequently gets in the way, specifically when vocal participants in IETF working groups believe that some architectural construct is being violated (see NAT, DNS redirection, private addressing, CIDR back in the day, etc), however I suspect this isn't the thread to explore this particular generic issue. In this specific case, several people including myself have argued that in the area of address allocation policy (or architecture, if you prefer), the IETF has in the past published documents that have tried to block PI allocation to end users without providing a reasonable (from the end users' perspective) alternative. I fully understand the underlying rationale for these attempts and I even agree conceptually with the intent, but pragmatically speaking, I don't see the IETF having a whole lot of say in the matter. > If it's something that neither the operators nor the IETF can solve, that's an unfair response. As has been demonstrated many times in the past, the market and network operators will do whatever is necessary to meet a particular business need, regardless of whether there is a violation of architectural purity. If the IETF is unable to come up with a realistic solution, network operators and the market will (perhaps in a way that has negative consequences, see NAT, DNS redirection, private addressing, CIDR, etc). Simple declaring PI evil (even with detailed explanations) isn't going to get anyone anywhere. Regards, -drc From fred at cisco.com Mon Sep 27 15:52:05 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 27 Sep 2010 06:52:05 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100927081357.GE27830@serpens.de> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926202647.GD27830@serpens.de> <20100927081357.GE27830@serpens.de> Message-ID: On Sep 27, 2010, at 1:14 AM, S.P.Zeidler wrote: >> That particular model has a down side, in that to make the checksums work end to end we update the prefix or the EID, which makes session switchover less seamless. But it requires no change to the host. > > Switchover in case of link failure will be 'traumatic' since the outside > prefix changes. That's always annoying but not necessarily a big issue. > Switchover from one router/firewall to the other should not change the > translation seen if the implementation of the prefix translator is the same, > right? Switchover Can result in a loss of the sessions going through the lost ISP. If there are two translators on that ISP, the loss of one doesn't have that effect, but the loss of the last translator forces the *other* guy to send to a new prefix, and he won't have signaling to know it. But yes, the guy being translated to won't see a difference. From fred at cisco.com Mon Sep 27 15:55:22 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 27 Sep 2010 06:55:22 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B-B83C-5C4441845C9C@cisco.com> <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> Message-ID: On Sep 26, 2010, at 5:34 PM, David Conrad wrote: > Fred, > > On Sep 26, 2010, at 1:27 AM, Fred Baker wrote: >> So the complaint is that the IETF has not found a cure for human stupidity/laziness or for the need to configure routers? > > This is somewhat beside the point as the die has already been cast, but I believe you are unfairly glossing over some of the difficulties implicit in the choice to bind the locator and identifier into the same object. For example, the fact that transport-layer connections must be terminated when changing network topologic location means that it is impossible to maintain connection over those network change events. This has nothing to do with human stupidity/laziness. No argument there. I suspect, though, that this is also true of ILNP (which tries to do exactly what you are asking for) as there is no signal that tells the peer which prefix to change do. >> Or is there another complaint? > > I believe the original complaint was that some folks in the IETF have in the past ignored operators' input and the current draft appears to be repeating that pattern. I can't fix everyone in the IETF. I am asking questions in this forum because I was asked by an operator to do so. I hope it's clear that v6ops is listening. >> I'm serious. If the IETF has actively gotten in the way, there's something we need to fix. > > In this specific case, several people including myself have argued that in the area of address allocation policy (or architecture, if you prefer), the IETF has in the past published documents that have tried to block PI allocation to end users without providing a reasonable (from the end users' perspective) alternative. I fully understand the underlying rationale for these attempts and I even agree conceptually with the intent, but pragmatically speaking, I don't see the IETF having a whole lot of say in the matter. Ack. From Fred.L.Templin at boeing.com Mon Sep 27 16:28:10 2010 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 27 Sep 2010 07:28:10 -0700 Subject: [v6ops] I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <0AF337A7-7EA7-4199-9B14-5FD605CD7AE8@cisco.com> References: <20100924194512.4C6EA3A69AE@core3.amsl.com> <84A5A94E-E4BE-400B- B83C-5C4441845C9C@cisco.com><20100925103459.GB27830@serpens.de> <4C9E4F8F.3040807@gmail.com> <0AF337A7-7EA7-4199-9B14-5FD605CD7AE8@cisco.com> Message-ID: > -----Original Message----- > From: v6ops-bounces at ietf.org [mailto:v6ops-bounces at ietf.org] > On Behalf Of Fred Baker > Sent: Saturday, September 25, 2010 1:04 PM > To: Brian E Carpenter > Cc: IPv6 Operations; S.P.Zeidler; IPv6 operators forum > Subject: Re: [v6ops] I-D > Action:draft-azinger-scalable-addressing-00.txt > > >> Overall document: > >> Given that even huge ASes will only originate a small number of > >> prefixes in v6 compared to dozens to hundreds in v4 now, > what problem > >> exactly is this trying to fix? > > > > That depends entirely on user sites and ISPs following good > (CIDR-like) > > practice. So I think encouraging that is the useful goal of > this draft. > > Which is where the draft is trying to go. > > >> As long as getting PI space is bound to getting or having > an AS I don't > >> really see the scaling problem. > > > > Well, unless it encourages a gold rush on AS numbers. > > >> The danger of every corner shop in the world trying to get > PI is not > >> actually there IMHO. > > > > Again, I hope you're correct, but why not document the fact > that it's > > highly undesirable? > > We are in fact seeing quite a growth in AS numbers and in > requests for PI allocation. You might look at > > http://www.potaroo.net/tools/asn16/ > > The growth rate of the AS number space is not spiking up per > se, but it is non-linear, with increases in rate circa 2000 > (with the dot-com bubble bursting, there was an increase in > the assignment rate of AS numbers) and 2009-2010. I would > imagine these are not "to get PI space" but "to multihome > using BGP". If anything, I see that as the argument for > solutions like ILNP or NAT66 (the draft, which does stateless > prefix translation, not the idea of making stateful IPv6/IPv6 > network ADDRESS translators). They enable the transit > operators to view their networks as PA while their customers > view themselves as pseudo-PI. Yes, it has issues similar to > those described in RFC 2993. This is actually the same situation as for IRON. End user networks perceive what they get from their IRON service arrangements as PI, but all that gets presented to the BGP are highly-aggregated prefixes that are indistinguishable from PA. IRON solves the whole package of IPv6 transition and coexistence requirements - not just bits and pieces like some others that seem to be getting lots of popular hype. IMO, it is worth a closer look. Fred fred.l.templin at boeing.com > _______________________________________________ > v6ops mailing list > v6ops at ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From merike at doubleshotsecurity.com Mon Sep 27 17:40:19 2010 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Mon, 27 Sep 2010 08:40:19 -0700 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <4CA05173.7050604@gont.com.ar> References: <4C99C331.4040507@gont.com.ar> <95AFC34C-B796-408D-A5CA-B6E17E678EFE@doubleshotsecurity.com> <4CA05173.7050604@gont.com.ar> Message-ID: Hi.. Sorry for misunderstanding. I haven't seen any replies yet regarding how it is actually implemented in devices. Have you received any offline replies? - merike On Sep 27, 2010, at 1:10 AM, Fernando Gont wrote: > Hi, Merike, > > Please find my comments inline... > >> Here's two pointers that may help: >> >> http://www.juniper.net/techpubs/en_US/junos9.4/topics/concept/cos-ipv6-protocols-overview-solution.html >> >> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-qos.html >> [especially the troubleshooting part] > > These two pointers are about diffserv (which is *not* what I was looking > for). I was asking about processing the IPv6 Traffic Class as in the > original IPv4 ToS definition (e.g., strict precedence-ordered queuing, > based on the Precedence field of the ToS, etc.) > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From tony.li at tony.li Mon Sep 27 18:08:46 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 09:08:46 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <20100927093310.GX32268@Space.Net> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> Message-ID: <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> Hi Gert, >> Agreed. Once again, we are trying to agree on an addressing >> architecture, not policy. > > The statement "*you* get your own globally visible chunk of address space, > and *you* don't" sounds very much like what we have in our policy documents. Well, the significant distinction that we're trying to make is based on topology. We leave the judgement calls to the policy makers, as that WOULD be policy. > So maybe something could explain to the non-native speakers on this > list what the distinction between "addressing architecture" and > "address policy" is. Please see section 2.3 of our draft. Regards, Tony From bmanning at vacation.karoshi.com Mon Sep 27 18:18:18 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 27 Sep 2010 16:18:18 +0000 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> Message-ID: <20100927161818.GC19055@vacation.karoshi.com.> On Mon, Sep 27, 2010 at 09:08:46AM -0700, Tony Li wrote: > > Hi Gert, > > >> Agreed. Once again, we are trying to agree on an addressing > >> architecture, not policy. > > > > The statement "*you* get your own globally visible chunk of address space, > > and *you* don't" sounds very much like what we have in our policy documents. > > > Well, the significant distinction that we're trying to make is based on topology. We leave the judgement calls to the policy makers, as that WOULD be policy. is there an unstated assumption that all networks that use IPv6 addressing WILL interconnect with each other? --bill > > > Regards, > Tony > From tony.li at tony.li Mon Sep 27 18:33:11 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 09:33:11 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <20100927161818.GC19055@vacation.karoshi.com.> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <20100927161818.GC19055@vacation.karoshi.com.> Message-ID: <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> Hi Bill, > is there an unstated assumption that all networks that use IPv6 addressing > WILL interconnect with each other? No, but there is an unstated assumption that the routing and addressing architecture is for the Internet. Certainly if someone is running a v6 network that is not Internet connected, then they are welcome to do whatever they like. ;-) Tony From michael at rancid.berkeley.edu Mon Sep 27 19:01:24 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 27 Sep 2010 10:01:24 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> Message-ID: <4CA0CDE4.3090503@rancid.berkeley.edu> On 09/27/10 09:08, Tony Li wrote: > > Hi Gert, > >>> Agreed. Once again, we are trying to agree on an addressing >>> architecture, not policy. >> >> The statement "*you* get your own globally visible chunk of address >> space, and *you* don't" sounds very much like what we have in our >> policy documents. > > > Well, the significant distinction that we're trying to make is based > on topology. We leave the judgement calls to the policy makers, as > that WOULD be policy. I think I see where I am missing a point of the draft here. Consider the example of a small ISP that provides v4/v6 dial-up services (and maybe even runs a v6 tunnel broker) for rural customers. They are single-homed. From a topological perspective, they look exactly like an end site, despite the fact that they provide services to a lot of independent customers. OTOH, a large corporation that has several campuses and is multi-homed definitely looks like a service provider topologically, even though it is only providing services to itself. For me, who sometimes looks at these things economically, the former is a service provider and the latter is an end site. Topologically, the former is an end site and the latter is a service provider. Would it clarify things to recommend that single-homed entities get PA and multi-homed get PI rather than use the more loaded distinction between service providers and end sites, or is that not the intent of the draft? From tony.li at tony.li Mon Sep 27 19:16:09 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 10:16:09 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA0CDE4.3090503@rancid.berkeley.edu> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> Message-ID: <186AE719-D920-4232-8E85-63816104B29A@tony.li> Hi Michael, > I think I see where I am missing a point of the draft here. Consider the example of a small ISP that provides v4/v6 dial-up services (and maybe even runs a v6 tunnel broker) for rural customers. They are single-homed. From a topological perspective, they look exactly like an end site, despite the fact that they provide services to a lot of independent customers. OTOH, a large corporation that has several campuses and is multi-homed definitely looks like a service provider topologically, even though it is only providing services to itself. > > For me, who sometimes looks at these things economically, the former is a service provider and the latter is an end site. Topologically, the former is an end site and the latter is a service provider. Thank you, that's an excellent way of describing the differences. > Would it clarify things to recommend that single-homed entities get PA and multi-homed get PI rather than use the more loaded distinction between service providers and end sites, or is that not the intent of the draft? This almost works for me. Instead I would say that single-homed entities get PA and mildly multi-homed get PA and grossly multi-homed get PI. The difference is simply one of numbers: if mildly multi-homed entities get PI and there are a plethora of them, then we have not resolved the scalability issue. Tony From fred at cisco.com Mon Sep 27 19:19:24 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 27 Sep 2010 10:19:24 -0700 Subject: [v6ops] I-D Action:draft-ietf-v6ops-3177bis-end-sites-00.txt In-Reply-To: References: <20100926061511.550793A6A0D@core3.amsl.com> <4C9FC90C.2030001@gmail.com> Message-ID: <5C6CC8A1-8C8A-4CBB-A2AE-D0FD3C6F1A37@cisco.com> On Sep 27, 2010, at 10:02 AM, Randy Bush wrote: > artificial serialization seems an unneeded way to put additional delay in an already long process. understood. My problem is that as for example on the incremental CGN draft I often get no comments at all, or no comments (simple security draft) until months after the WGLC closes. Makes it kind of hard to represent the WG's opinions going upstream. I'd rather perhaps put up a wiki and say "on drafts A, B, C, and D, please go to the appropriate wiki page and post your thoughts". My experience suggests that I would have no results on anything. Rock, meet hard place. I can tell when the operators really care about something, though. I asked the question of the IPv6 operators forum this weekend specifically because when Marla/Tony/Jason brought the document to v6ops I expected exactly the discussion we have been having over the weekend, and I wanted it out on the table in black and white. You and other operators make rather a point of castigating the IETF for not listening. I hope you will be just as open about acknowledging when we do. From fred at cisco.com Mon Sep 27 20:05:45 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 27 Sep 2010 11:05:45 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <20100927161818.GC19055@vacation.karoshi.com.> <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> Message-ID: <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> On Sep 27, 2010, at 9:33 AM, Tony Li wrote: > Certainly if someone is running a v6 network that is not Internet connected, then they are welcome to do whatever they like. ;-) I actually disagree. In the Smart Grid world, there have been suggestions that they use IPv4 and simply re-use the IPv4 address space "because the networks will never be connected". You can guess my response to that - "been there, done that, note the road rash". I think that they should operate as though they might eventually become connected, in part to deal with stuxnet-style issues and in part in case they inadvertently or intentionally become connected at some point in the future. From randy at psg.com Mon Sep 27 19:47:04 2010 From: randy at psg.com (Randy Bush) Date: Mon, 27 Sep 2010 10:47:04 -0700 Subject: [v6ops] I-D Action:draft-ietf-v6ops-3177bis-end-sites-00.txt In-Reply-To: <5C6CC8A1-8C8A-4CBB-A2AE-D0FD3C6F1A37@cisco.com> References: <20100926061511.550793A6A0D@core3.amsl.com> <4C9FC90C.2030001@gmail.com> <5C6CC8A1-8C8A-4CBB-A2AE-D0FD3C6F1A37@cisco.com> Message-ID: it is not clear to meu that serialization will increase comment or make why coments you get more timely. perhaps a posting every few days or once a week listing the docs in last call and/or in need of review I am cheered at the operator input we are starting to get. I would credit you folk and the ops cabal. but time will tell. do whack me when I could be more helpful. excuse bad email form. this is an ipad. randy On Sep 27, 2010, at 10:19, Fred Baker wrote: > > On Sep 27, 2010, at 10:02 AM, Randy Bush wrote: > >> artificial serialization seems an unneeded way to put additional delay in an already long process. > > understood. My problem is that as for example on the incremental CGN draft I often get no comments at all, or no comments (simple security draft) until months after the WGLC closes. Makes it kind of hard to represent the WG's opinions going upstream. I'd rather perhaps put up a wiki and say "on drafts A, B, C, and D, please go to the appropriate wiki page and post your thoughts". My experience suggests that I would have no results on anything. > > Rock, meet hard place. > > I can tell when the operators really care about something, though. I asked the question of the IPv6 operators forum this weekend specifically because when Marla/Tony/Jason brought the document to v6ops I expected exactly the discussion we have been having over the weekend, and I wanted it out on the table in black and white. You and other operators make rather a point of castigating the IETF for not listening. I hope you will be just as open about acknowledging when we do. From bmanning at vacation.karoshi.com Mon Sep 27 20:33:00 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 27 Sep 2010 18:33:00 +0000 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> References: <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <20100927161818.GC19055@vacation.karoshi.com.> <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> Message-ID: <20100927183300.GE19055@vacation.karoshi.com.> On Mon, Sep 27, 2010 at 11:05:45AM -0700, Fred Baker wrote: > > On Sep 27, 2010, at 9:33 AM, Tony Li wrote: > > > Certainly if someone is running a v6 network that is not Internet connected, then they are welcome to do whatever they like. ;-) > > I actually disagree. In the Smart Grid world, there have been suggestions that they use IPv4 and simply re-use the IPv4 address space "because the networks will never be connected". You can guess my response to that - "been there, done that, note the road rash". I think that they should operate as though they might eventually become connected, in part to deal with stuxnet-style issues and in part in case they inadvertently or intentionally become connected at some point in the future. this points out that global uniqueness is important to Fred (and me too) but that assured / presumed _full_ connectivity is less so. one could presume that if aggregation a core principle, that we would see far fewer /24 prefixes in the existant routing system. the point here is that a routing slot really doesn't care what the prefix size is. A slot is a slot. --bill From brian.e.carpenter at gmail.com Mon Sep 27 22:10:31 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 28 Sep 2010 09:10:31 +1300 Subject: ToS-like processing of the IPv6 Traffic Class? In-Reply-To: <4CA05173.7050604@gont.com.ar> References: <4C99C331.4040507@gont.com.ar> <95AFC34C-B796-408D-A5CA-B6E17E678EFE@doubleshotsecurity.com> <4CA05173.7050604@gont.com.ar> Message-ID: <4CA0FA37.5020406@gmail.com> On 2010-09-27 21:10, Fernando Gont wrote: > Hi, Merike, > > Please find my comments inline... > >> Here's two pointers that may help: >> >> http://www.juniper.net/techpubs/en_US/junos9.4/topics/concept/cos-ipv6-protocols-overview-solution.html >> >> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-qos.html >> [especially the troubleshooting part] > > These two pointers are about diffserv (which is *not* what I was looking > for). I was asking about processing the IPv6 Traffic Class as in the > original IPv4 ToS definition (e.g., strict precedence-ordered queuing, > based on the Precedence field of the ToS, etc.) The Cisco stuff makes it clear (as I said earlier) that precedence is a subset of diffserv. If someone claims to support diffserv then they are automatically claiming to support IP precedence. The juniper doc cited doesn't appear to mention precedence, but the 3rd table at http://www.juniper.net/techpubs/software/junos/junos80/swconfig80-cos/html/cos-ba-classifiers3.html make it clear that they do support IP precedence as part of diffserv. Which is exactly what RFC 2474 requires. Brian From dougb at dougbarton.us Mon Sep 27 22:15:01 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 13:15:01 -0700 Subject: SNOM VoIP Phones, Where are my RAs? In-Reply-To: References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> Message-ID: <4CA0FB45.8060207@dougbarton.us> It's not a good idea to take a message from the middle of a thread, reply to it, and change the subject line. What happens for those of us who use threaded mail readers is that your message appears as part of the thread, which in this case has dozens of messages, and therefore is not likely to be given the attention it deserves. Better is to save the list address to your address book, and create a new message. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From brian.e.carpenter at gmail.com Mon Sep 27 22:29:09 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 28 Sep 2010 09:29:09 +1300 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <20100927161818.GC19055@vacation.karoshi.com.> <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> Message-ID: <4CA0FE95.30501@gmail.com> On 2010-09-28 07:05, Fred Baker wrote: > On Sep 27, 2010, at 9:33 AM, Tony Li wrote: > >> Certainly if someone is running a v6 network that is not Internet connected, then they are welcome to do whatever they like. ;-) > > I actually disagree. In the Smart Grid world, there have been suggestions that they use IPv4 and simply re-use the IPv4 address space "because the networks will never be connected". You can guess my response to that - "been there, done that, note the road rash". I think that they should operate as though they might eventually become connected, in part to deal with stuxnet-style issues and in part in case they inadvertently or intentionally become connected at some point in the future. Indeed. One of the ironies of the smart grid debate and how it interacts with our debate here is that the electrical power industry itself wrote one of the strongest requirement statements for IPng in RFC 1673. Please pretend you can't see the OSI references: 2. Basic Requirements. - Scaleability The addressing scheme must have essentially an unlimited address space to encompass an arbitrarily large number of information objects. Specifically it must solve the fundamental limitations of 32 bit formats, a format for 20 octets and above is considered suitable. - Routing table economy Network addressing must achieve significant economy in routing database size with very large networks. - Support for the existing Internet The existing internetworking paradigm and existing OSI and IPS applications are to be supported. Brian From dougb at dougbarton.us Mon Sep 27 22:30:45 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 13:30:45 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <186AE719-D920-4232-8E85-63816104B29A@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> Message-ID: <4CA0FEF5.5080808@dougbarton.us> On 9/27/2010 10:16 AM, Tony Li wrote: > > This almost works for me. Instead I would say that single-homed > entities get PA and mildly multi-homed get PA and grossly multi-homed > get PI. How do you define "mildly?" I think the "best" answer is obvious, find a magic solution to the routing table problem, and give everyone PI. Since that's not likely to happen, we need to figure out a way to give as many people PI as possible. BTW, "the issue" with PI is not just multi-homing, it's also portability. In my conversations with folks about this (going all the way back to when I was at ICANN and talking to serious people about how to get IPv6 deployed sooner), enterprises that have PI IPv4 now won't even consider IPv6 without PI. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tony.li at tony.li Mon Sep 27 22:57:18 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 13:57:18 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA0FEF5.5080808@dougbarton.us> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> Message-ID: <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> Hi Doug, > How do you define "mildly?" I would derive it: overall, we need to come up with a routing architecture that grows the table no more than 9%/yr. Looking at the roles within the topology, which roles grow more than 9%/yr? Certainly single-homed end-sites do. Dual-homed end-sites would also seem to do so. Top-level ISPs do not. > I think the "best" answer is obvious, find a magic solution to the routing table problem, and give everyone PI. Since that's not likely to happen, we need to figure out a way to give as many people PI as possible. I'd suggest that a scalable routing architecture is a higher priority than giving people PI. While PI is convenient, not having routing is simply fatal. > BTW, "the issue" with PI is not just multi-homing, it's also portability. In my conversations with folks about this (going all the way back to when I was at ICANN and talking to serious people about how to get IPv6 deployed sooner), enterprises that have PI IPv4 now won't even consider IPv6 without PI. TANSTAAFL. Except for a few early adopters, transitioning to IPv6 is going to be a hassle and not free. Most people will not do so unless they absolutely have to. Tony From dougb at dougbarton.us Mon Sep 27 23:02:44 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 14:02:44 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> Message-ID: <4CA10674.9060508@dougbarton.us> On 9/27/2010 1:57 PM, Tony Li wrote: > >> BTW, "the issue" with PI is not just multi-homing, it's also portability. In my conversations with folks about this (going all the way back to when I was at ICANN and talking to serious people about how to get IPv6 deployed sooner), enterprises that have PI IPv4 now won't even consider IPv6 without PI. > > > TANSTAAFL. > > Except for a few early adopters, transitioning to IPv6 is going to be a hassle and not free. Most people will not do so unless they absolutely have to. And when you (well, maybe not _you_, but others) ask why people haven't bothered to deploy IPv6 yet, and/or the related questions of why operators aren't really interested in what comes out of the IETF nowadays, please refer to this post. I've said it before, but I think it bears repeating in this context. Either the operators get everything they have now in IPv4, or the answer is going to be more v4 NAT, not IPv6. (I.e., go with the devil you know.) Of course, by your criteria that's fine, since it also solves the routing problem. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From spz at serpens.de Mon Sep 27 23:22:25 2010 From: spz at serpens.de (S.P.Zeidler) Date: Mon, 27 Sep 2010 23:22:25 +0200 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <186AE719-D920-4232-8E85-63816104B29A@tony.li> References: <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> Message-ID: <20100927212223.GF27830@serpens.de> Thus wrote Tony Li (tony.li at tony.li): > This almost works for me. Instead I would say that single-homed entities get PA and mildly multi-homed get PA and grossly multi-homed get PI. The why matters here, a lot. If you are put out but not broke when all your TCP connections drop (as long as you can create new ones right away), and aren't in the situation that your customers can't find the service that's the reason for your company to exist until DNS cache time has exceeded when you lose your preferred link, multi-PA multihoming works. If either is not true, you may need PI even if you only have two uplinks. regards, spz -- spz at serpens.de (S.P.Zeidler) From dougb at dougbarton.us Mon Sep 27 23:24:36 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 14:24:36 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4C9FD315.6030301@timmins.net> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> Message-ID: <4CA10B94.5070601@dougbarton.us> On 9/26/2010 4:11 PM, Paul Timmins wrote: > 3) Unless the customer is ubiquitously running DHCPv6, changing things > like their active directory servers and other things is very, very risky > for their network stability. To say nothing of things like medical > diagnostic equipment and other weird and esoteric devices on customer > networks we come across all the time which undoubtedly have hardcoded > addresses in them for one reason or another, for reasons good or bad. > > Most of our customers can barely hack running one set of valid > addresses, having ULA and public will be confusing as hell for them. So this is one more strong argument for IPv6 PI in as many places as humanly possible. Please note that I am not suggesting that this is a "fire and forget" solution, I'm aware that even in IPv6-topia there will still be renumbering due to organizational changes (e.g., mergers and acquisitions) but we really should be focusing on IPv6 PI as the answer, not as the problem. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From spz at serpens.de Mon Sep 27 23:30:49 2010 From: spz at serpens.de (S.P.Zeidler) Date: Mon, 27 Sep 2010 23:30:49 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA10B94.5070601@dougbarton.us> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> Message-ID: <20100927213048.GG27830@serpens.de> Thus wrote Doug Barton (dougb at dougbarton.us): > [...] even in IPv6-topia there will still > be renumbering due to organizational changes (e.g., mergers and > acquisitions) Small nit: you get Real Fun with a company split, not with a merger. regards, spz -- spz at serpens.de (S.P.Zeidler) From dougb at dougbarton.us Mon Sep 27 23:33:11 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 14:33:11 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100927213048.GG27830@serpens.de> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <20100927213048.GG27830@serpens.de> Message-ID: <4CA10D97.1000501@dougbarton.us> On 9/27/2010 2:30 PM, S.P.Zeidler wrote: > Thus wrote Doug Barton (dougb at dougbarton.us): > >> [...] even in IPv6-topia there will still >> be renumbering due to organizational changes (e.g., mergers and >> acquisitions) > > Small nit: you get Real Fun with a company split, not with a merger. Heh, good point. I was part of being acquired twice, and was on the teams that DID the acquiring several times; but never had to do a split. I'll add that to my list, thanks. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tony.li at tony.li Mon Sep 27 23:35:28 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 14:35:28 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA10674.9060508@dougbarton.us> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> Message-ID: Hi Doug, > I've said it before, but I think it bears repeating in this context. Either the operators get everything they have now in IPv4, or the answer is going to be more v4 NAT, not IPv6. (I.e., go with the devil you know.) Of course, by your criteria that's fine, since it also solves the routing problem. Um, no, that's not fine. V4 routing has scalability problems too, it's just substantially better than v6 right now. Selling people on v6 by selling them PI is not a sound strategy. We can't do that with everyone, and doing so up front will simply create an issue with the haves and have-nots down the road. If it helps, my vision for the end state is pretty simple: - We use ILNP (or similar) for v6 to decouple locators from identifiers. - We simplify renumbering to make that tractable. - We aggregate aggressively to keep the table size down. As ILNP is going to take a long time to develop and deploy, we need to aggregate aggressively now to not create the v6 swamp and to buy us time in case ILNP is not a panacea. In this end state, the multi-homed end site can easily renumber and change providers. Their multiple connections provide them resilient connectivity, up to and including session continuity. And this is all doable with multiple PA addresses, so we end up with adequate routing scalability. Regards, Tony From fred at cisco.com Mon Sep 27 23:36:28 2010 From: fred at cisco.com (Fred Baker) Date: Mon, 27 Sep 2010 14:36:28 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA10B94.5070601@dougbarton.us> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> Message-ID: On Sep 27, 2010, at 2:24 PM, Doug Barton wrote: > So this is one more strong argument for IPv6 PI in as many places as humanly possible. > > Please note that I am not suggesting that this is a "fire and forget" solution, I'm aware that even in IPv6-topia there will still be renumbering due to organizational changes (e.g., mergers and acquisitions) but we really should be focusing on IPv6 PI as the answer, not as the problem. So you would very strongly prefer a world in which router memory sizes are required to be effectively infinite. If you're willing to pay the opex and the capex, the cooling, the sticker price, and so on and so forth without murmur or complaint, I'm (well, a random router vendor of my acquaintance is) willing to sell it to you. My problem is that you may be the only person I can sell it to. Everyone else seems to be bothered by such issues. One thing that seems to be lost in this discussion is that while many seem to think that the IETF (and therefore the vendors, as operators tell us they don't like to attend IETF meetings) isn't interested in solving operational business problems. What might in fact be true is that the IETF, due to lack of operational input, doesn't have clear guidance on what the operators consider to be the important problems. But reducing operational opex and capex is one thing that the IETF has had on radar for quite a while, along with making it more possible for new and interesting applications to be written that operate in a model other than client/server. From nick at foobar.org Mon Sep 27 23:56:45 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 27 Sep 2010 23:56:45 +0200 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> Message-ID: <4CA1131D.4000301@foobar.org> On 27/09/2010 23:35, Tony Li wrote: > Selling people on v6 by selling them PI is not a sound strategy. People are not being sold v6 on the basis of PI availability. It is true, though, that before v6 PI was available, the lack of it was one of the hurdles to widespread ipv6 deployment. But it was just one of many. The only thing that will drive people to ipv6 is a situation where ipv4 connectivity sucks so horribly that they have no alternative but to move - imho. > As ILNP is going to take a long time to develop and deploy, we need to > aggregate aggressively now to not create the v6 swamp and to buy us time > in case ILNP is not a panacea. I agree - in theory. However, there are an awful lot of companies out there which have an expectation that moving to ipv6 will not cause severe functionality loss. Multi-homing and provider independence are two really serious issues for certain types companies, and PI happens to solve both rather easily. Nick From dougb at dougbarton.us Mon Sep 27 23:59:11 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 14:59:11 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1131D.4000301@foobar.org> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1131D.4000301@foobar.org> Message-ID: <4CA113AF.1020509@dougbarton.us> On 9/27/2010 2:56 PM, Nick Hilliard wrote: > On 27/09/2010 23:35, Tony Li wrote: >> Selling people on v6 by selling them PI is not a sound strategy. > > People are not being sold v6 on the basis of PI availability. It is > true, though, that before v6 PI was available, the lack of it was one of > the hurdles to widespread ipv6 deployment. But it was just one of many. Right. It's a gating factor, not a sales pitch. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at dougbarton.us Tue Sep 28 00:03:44 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 15:03:44 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> Message-ID: <4CA114C0.2010609@dougbarton.us> On 9/27/2010 2:36 PM, Fred Baker wrote: > > On Sep 27, 2010, at 2:24 PM, Doug Barton wrote: >> So this is one more strong argument for IPv6 PI in as many places >> as humanly possible. >> Please note that I am not suggesting that this is a "fire and >> forget" solution, I'm aware that even in IPv6-topia there will >> still be renumbering due to organizational changes (e.g., mergers >> and acquisitions) but we really should be focusing on IPv6 PI as >> the answer, not as the problem. > > So you would very strongly prefer a world in which router memory > sizes are required to be effectively infinite. Easy there tiger, that's not at all what I said, and it's not even close to what I think. Someone else already pointed out that where they have 2-4 IPv4 blocks advertised now, they could easily get by with just 1 IPv6 announcement. In my book that's making the routing table smaller, not larger. :) What I'm advocating is not blindly bloating the routing table ad infinitum. What I'm suggesting is that we look at the whole chess board. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at dougbarton.us Tue Sep 28 00:07:46 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 27 Sep 2010 15:07:46 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> Message-ID: <4CA115B2.30902@dougbarton.us> On 9/27/2010 2:35 PM, Tony Li wrote: > If it helps, my vision for the end state is pretty simple: > > - We use ILNP (or similar) for v6 to decouple locators from > identifiers. - We simplify renumbering to make that tractable. - We > aggregate aggressively to keep the table size down. > > As ILNP is going to take a long time to develop and deploy, we need > to aggregate aggressively now to not create the v6 swamp and to buy > us time in case ILNP is not a panacea. All interesting stuff, and if you'd done it 10 years ago it might have a chance to be deployed today. But the fact is that we need widespread deployment of IPv6 _yesterday_, and jamming PA down operator's throats with the promise of something better tomorrow is not even in the neighborhood of a valid/useful strategy for a myriad of reasons, not the least of which is that the operators simply won't do it. So I think I've repeated myself enough now for one day. Hopefully someone will come up with something new here sometime soon ... Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From nick at foobar.org Tue Sep 28 00:24:09 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 28 Sep 2010 00:24:09 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> Message-ID: <4CA11989.1010605@foobar.org> On 27/09/2010 23:36, Fred Baker wrote: > So you would very strongly prefer a world in which router memory sizes > are required to be effectively infinite. Fred, let's leave the straw men in the basket. As stated many times before, by many people - PI provides multihoming capability and provider independence at low levels of both cost and complexity. There are no other ways of implementing provider addressing independence, and no feasible ways of implementing end-site multihoming. Let's put this another way: if I were a small hosting company, my requirement to put bread on my table and pay my mortgage would trump your desire to keep the dfz small. This is the reality that many people face. Yes, this is the tragedy of the commons. No, operators don't like it. But for the record, let me repeat once more: there will be no solution to the problem of PI until the multihoming and provider independence problems have been solved. If these things are fixed, then operators will listen to your pleas that PI needs to be ditched, but not before. In the interim, we will continue to do our best to aggregate PA and to discourage people from using PI, where possible. > seem to think that the IETF (and therefore the vendors, as operators > tell us they don't like to attend IETF meetings) In my case - and I suspect many others too - it's not a question of "don't like", but rather "can't justify the budget or time required". Again, this relates to IETF activities not directly putting bread on my table or paying my mortgage. Sorry, but I don't work for a large company which can afford to send me to three meetings a year in far-flung places, and where there is no tangible, short-medium term return on financial investment. This sucks, but I don't have a choice in the matter. Nick From tony.li at tony.li Tue Sep 28 02:27:21 2010 From: tony.li at tony.li (Tony Li) Date: Mon, 27 Sep 2010 17:27:21 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA115B2.30902@dougbarton.us> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA115B2.30902@dougbarton.us> Message-ID: <38EB4C0C-06D8-4353-A8A2-40F1B1BCB7B0@tony.li> > All interesting stuff, and if you'd done it 10 years ago it might have a chance to be deployed today. Well, 10 years ago (and actually a bit more), some folks tried. And they were told "no thank you". Some of us keep trying. > But the fact is that we need widespread deployment of IPv6 _yesterday_, > and jamming PA down operator's throats with the promise of something better tomorrow is not even in the neighborhood of a valid/useful strategy for a myriad of reasons, not the least of which is that the operators simply won't do it. You know, we can sit and fight about this, or we can solve the problem. I'd rather not fight. We need to do something and we will not make progress by simply duking it out. Tony From brian.e.carpenter at gmail.com Tue Sep 28 04:38:44 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 28 Sep 2010 15:38:44 +1300 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA114C0.2010609@dougbarton.us> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> Message-ID: <4CA15534.7000509@gmail.com> On 2010-09-28 11:03, Doug Barton wrote: > On 9/27/2010 2:36 PM, Fred Baker wrote: >> >> On Sep 27, 2010, at 2:24 PM, Doug Barton wrote: >>> So this is one more strong argument for IPv6 PI in as many places >>> as humanly possible. > >>> Please note that I am not suggesting that this is a "fire and >>> forget" solution, I'm aware that even in IPv6-topia there will >>> still be renumbering due to organizational changes (e.g., mergers >>> and acquisitions) but we really should be focusing on IPv6 PI as >>> the answer, not as the problem. >> >> So you would very strongly prefer a world in which router memory >> sizes are required to be effectively infinite. > > Easy there tiger, that's not at all what I said, and it's not even close > to what I think. Someone else already pointed out that where they have > 2-4 IPv4 blocks advertised now, they could easily get by with just 1 > IPv6 announcement. In my book that's making the routing table smaller, > not larger. :) > > What I'm advocating is not blindly bloating the routing table ad > infinitum. What I'm suggesting is that we look at the whole chess board. Right, one BGP4 update on the first square, two BGP4 updates on the second square, four on the third square, and so on... The question is, as Fred was I think getting at, where do you stop? If you arrange guidelines and policies such that you stop at, say, a few hundred thousand PI prefixes announced world-wide, we can hope that the routers won't melt. If you arrange guidelines and policies such that you head towards ten million PI prefixes announced in BGP4, then San Jose, we got a problem. I think this is what the IETF, and v6ops specifically, needs to communicate on a technical basis to the RIR and ops community. People on this list here probably know it, but not everybody. Beyond that, please read draft-irtf-rrg-recommendation, but remember that it's only words. Brian From michael at rancid.berkeley.edu Tue Sep 28 07:55:04 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 27 Sep 2010 22:55:04 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA11989.1010605@foobar.org> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA11989.1010605@foobar.org> Message-ID: <4CA18338.5090004@rancid.berkeley.edu> On 09/27/10 15:24, Nick Hilliard wrote: > In my case - and I suspect many others too - it's not a question of > "don't like", but rather "can't justify the budget or time required". > Again, this relates to IETF activities not directly putting bread on my > table or paying my mortgage. Sorry, but I don't work for a large company > which can afford to send me to three meetings a year in far-flung > places, and where there is no tangible, short-medium term return on > financial investment. This sucks, but I don't have a choice in the matter. Even (or especially) at American research universities, where there was once substantial involvement in the development and implementation of standards for, and operation of, the Internet, it is pretty much a non-starter to attempt to justify attendance at IETF meetings. For those who pay the bills--with increasingly austere budgets--the perceived bang for the buck just isn't there. Perceptions rule, whether they're correct or not. There are several misunderstandings between the ops and standards communities. I have tried to illustrate some of those on the ops side that I think will end up hindering this effort. I think the PA/PI question is a bit of a minefield; who put the mines there or whether they had any justification for doing so is interesting, but not relevant to the person walking through the minefield. The notion that the ops folks don't want to go to IETF meetings is a similar misunderstanding on the IETF side. And yes, I do very much appreciate that Fred has brought this up on this mailing list and that we're having this conversation. michael From elmi at 4ever.de Tue Sep 28 10:46:22 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 28 Sep 2010 10:46:22 +0200 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1131D.4000301@foobar.org> References: <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1131D.4000301@foobar.org> Message-ID: <20100928084621.GD94643@ronin.4ever.de> nick at foobar.org (Nick Hilliard) wrote: > On 27/09/2010 23:35, Tony Li wrote: > >Selling people on v6 by selling them PI is not a sound strategy. > > People are not being sold v6 on the basis of PI availability. It is true, though, > that before v6 PI was available, the lack of it was one of the hurdles to widespread > ipv6 deployment. But it was just one of many. A pretty big hurdle. People/businesses do not want to lose the advantages of their current network structure due to a change in the addressing scheme. In fact, they more or less expect (the tech-savvy expect worse, of course) the network to work like before. That means *including* their provisions for fail-safety and redundancy. So, telling someone to go v6, but without the multihoming they are used to, they depend on, and their SLAs are based upon, is a way to keep them from v6, and to incourage them to spread the word that "v6 will make everything worse and break the Internet". Careful: I'm talking current PI holders here. > The only thing that will drive people to ipv6 is a situation where ipv4 connectivity > sucks so horribly that they have no alternative but to move - imho. Many people probably think of residential (or mobile) end-users here and believe that if those complain enough, the world will change. Reality tells us that... - end-users do not get to chose much in way of their ISP supporting IPv6; their influence is limited due to: - end-users have limited choice regarding ISPs; in many regions you are still locked to the incumbent, or have a very limited choice of mobile operators > I agree - in theory. However, there are an awful lot of companies out there which > have an expectation that moving to ipv6 will not cause severe functionality loss. > Multi-homing and provider independence are two really serious issues for certain > types companies, and PI happens to solve both rather easily. I see no big pain in assigning PI to current PI holders; they clearly want to multihome, know how to do it, and it will be very difficult to get them onto the IPv6 train without it. One important part of this is making reasonably sure (there naturally are exceptions) that they ever need that one assignment, meaning, one entry in the routing tables. Actually, I expect a lot of churn from the final IPv4 assignment period due to everybody running for the last breadcrumbs; this might outweigh the benefits of any IPv6 optimization strategy for a while to come. (One other important thing in the face of aggregation is some way of kicking the deaggregators' butts...one glance at any current v4 table and you know what I mean.) I do agree with Tony in that growth needs to stay limited to some low percentage per year, so we don't break routing due to memory problems. We should not break the Internet in order to achieve that... Apart from this: I have confidence in the hardware vendors to increase TCAM sizes sufficiently in the future - generation by generation, of course, because they want to sell us a new box every other year. Cheers, Elmar. PS: The second part of paragraph 4 ("An organization that changes service provider but does not renumber") seems to be somewhat specific to the use of PA in the ARIN region. This can by current policy not happen in the RIPE (and AFAIK LACNIC or APNIC) region, and ISPs will enforce renumbering easily. -- "Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch ernstgenommen." (Konrad Adenauer) --------------------------------------------------------------[ ELMI-RIPE ]--- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100928/9c012c4c/attachment.bin From michael.dillon at bt.com Tue Sep 28 12:07:33 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 28 Sep 2010 11:07:33 +0100 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <20100927183300.GE19055@vacation.karoshi.com.> References: <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <20100927161818.GC19055@vacation.karoshi.com.> <635A5554-C607-4D1A-BFC5-95EC04F8E5B1@tony.li> <02B68358-AAA7-45EF-8F5A-93EA2A493025@cisco.com> <20100927183300.GE19055@vacation.karoshi.com.> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239373ED217@EMV01-UKBR.domain1.systemhost.net> > this points out that global uniqueness is important to Fred (and > me too) > but that assured / presumed _full_ connectivity is less so. On the Community Of Interest Networks (COIN) that my employer operates for the global financial community (RadianzNet) and other companies operate for aviation (SITA) and the automotive industry (ENX, ANX) global uniqueness is very important, but any sort of external connectivity is often forbidden. COINs sit in a middle ground between the Internet and SCADA networks. A SCADA network has no business being connected to anything other than a very tightly closed and restricted control network. A COIN may choose to have some limited connectivity with the Internet. In the case of RadianzNet which I know best, just about every one of the several hundred networks connected to us, also have connections to the Internet. It's just that we enforce a policy of no direct traffic interchange. For example, an Internet connected site cannot exchange FIX traffic directly with a site on RadianzNet even though there are wires and routers in existence that *could* provide connectivity. Instead they must use a FIX service provider that has connectivity to both the Internet and RadianzNet. I think that the general architecture of COINs is common in the world of business and commerce, and one could liken them to the VANs which were larger than the global Internet until around 1999. Some COINs like RadianzNet, SITA, ENX/ANX are very visible but I think there are lots of smaller ones and many so-called extranets connecting the trading partners of a large company, share the main characteristic of COINs in that they require globally unique addresses but do not require any connectivity guarantees with the public Internet. Globally unique addresses are required because the interconnect mesh of COINs is constantly changing. New businesses connect to the network, mergers happen, and all of these hundreds of networks cannot use a set aside private network addressing block unless it is very large and guarantees no collisions. In the IPv4 world, the RFC 1918 block is so small that many global companies have run out of private network addresses or are on the verge of running out, or have implemented multi-layered NAT to reuse RFC 1918 addressing internally. For IPv6 expectations are higher, and since there is no shortage of globally unique addresses, there is no good reason not to use them. As for routing slots, COINS have minimal impact. Most ASes that participate in a COIN will also have Internet connectivity as well and will use routing policy and firewalls to control traffic. --Michael Dillon From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Sep 28 12:36:38 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 28 Sep 2010 20:06:38 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA11989.1010605@foobar.org> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA11989.1010605@foobar.org> Message-ID: <20100928200638.72c3cc63@opy.nosense.org> On Tue, 28 Sep 2010 00:24:09 +0200 Nick Hilliard wrote: > On 27/09/2010 23:36, Fred Baker wrote: > > So you would very strongly prefer a world in which router memory sizes > > are required to be effectively infinite. > > Fred, let's leave the straw men in the basket. > > As stated many times before, by many people - PI provides multihoming > capability and provider independence at low levels of both cost and > complexity. There are no other ways of implementing provider addressing > independence, and no feasible ways of implementing end-site multihoming. > > Let's put this another way: if I were a small hosting company, my > requirement to put bread on my table and pay my mortgage would trump your > desire to keep the dfz small. This is the reality that many people face. > > Yes, this is the tragedy of the commons. No, operators don't like it. > > But for the record, let me repeat once more: there will be no solution to > the problem of PI until the multihoming and provider independence problems > have been solved. If these things are fixed, then operators will listen to > your pleas that PI needs to be ditched, but not before. In the interim, we > will continue to do our best to aggregate PA and to discourage people from > using PI, where possible. > > > seem to think that the IETF (and therefore the vendors, as operators > > tell us they don't like to attend IETF meetings) > > In my case - and I suspect many others too - it's not a question of "don't > like", but rather "can't justify the budget or time required". Again, this > relates to IETF activities not directly putting bread on my table or paying > my mortgage. Sorry, but I don't work for a large company which can afford > to send me to three meetings a year in far-flung places, and where there is > no tangible, short-medium term return on financial investment. This sucks, > but I don't have a choice in the matter. > I've only been to one IETF(47) meeting, and that was because it was in my home town. Not being able to go the meetings is not much of a limitation, the mailing lists and via Internet Drafts is where most things happen. As for putting bread on your table, self-driven education, by reading RFCs *before* they become RFCs, and contributing to them if you want to, can only benefit you professionally, and possibly put more food on your table than you thought. 99% of the bread on my table this year is because of IPv6, and while I've read a few books on it, most of the more valuable knowledge I've got of it is because of reading IPv6 RFCs and Internet Drafts, and participating in IETF mailing lists. It's taken some personal time, but not an excessive amount. I sometimes think the time some people spend complaining about it (either their own time, or their employer's) would be better spent learning more about it or helping to improve it when there is an opportunity to - if nothing else, reading a draft and commenting on how the text could be made clearer is a small contribution that they'll also gain from. Regards, Mark. From nick at foobar.org Tue Sep 28 14:55:41 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 28 Sep 2010 14:55:41 +0200 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> Message-ID: <4CA1E5CD.9040407@foobar.org> On 27/09/2010 23:35, Tony Li wrote: > - We use ILNP (or similar) for v6 to decouple locators from identifiers. off-topic rambling: on the issue of decoupling locator and identifier, I'm still not really sure that any L/I separation is really going to fix our problems in the long term. In fact, we already use a form of locator / identifier separation: ASN and prefix. We could - with some work - implement L/I separation by creating a new BGP / core router model which made routing decisions on the basis of AS identifier only, and not per-prefix. But I can't help wondering that if we perform our routing decisions based solely on locator (e.g. ASN or other) and not identifier, then we commit ourselves to trashing our current traffic engineering flexibilities. If we decide we want traffic engineering capabilities again, we need to introduce a routing protocol which also discriminates on the basis of the identifier. And that's hardly an improvement on what we have right now. Nick /me goes off to read up on the latest coolness for L/I separation which hopefully deal with all these problems From david.freedman at uk.clara.net Tue Sep 28 15:42:58 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 28 Sep 2010 14:42:58 +0100 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1E5CD.9040407@foobar.org> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1E5CD.9040407@foobar.org> Message-ID: <4CA1F0E2.1050908@uk.clara.net> Nick Hilliard wrote: > On 27/09/2010 23:35, Tony Li wrote: >> - We use ILNP (or similar) for v6 to decouple locators from identifiers. > > off-topic rambling: > > on the issue of decoupling locator and identifier, I'm still not really > sure that any L/I separation is really going to fix our problems in the > long term. In fact, we already use a form of locator / identifier > separation: ASN and prefix. We could - with some work - implement L/I > separation by creating a new BGP / core router model which made routing > decisions on the basis of AS identifier only, and not per-prefix. Excuse my ignorance on the subject, but I thought the purpose of L/I was to only route locators on the "internet" and to route "identifiers" (i.e belonging to services/people) via an overlay (but perhaps I've had my head in the LISP cloud for a while) You get a locator and it multihomes, locator aggregation is possible but not key to the system, the main objective to control the growth in terms of addressing requirement and punt the services and people to the overlay. > > But I can't help wondering that if we perform our routing decisions > based solely on locator (e.g. ASN or other) and not identifier, then we > commit ourselves to trashing our current traffic engineering > flexibilities. If we decide we want traffic engineering capabilities > again, we need to introduce a routing protocol which also discriminates > on the basis of the identifier. And that's hardly an improvement on > what we have right now. Nothing wrong with mapping identifier services to locator T/E, this easily achievable in an inspected (but possibly out of band) data plane model Dave. > > Nick > /me goes off to read up on the latest coolness for L/I separation which > hopefully deal with all these problems > -- David Freedman Group Network Engineering Claranet Group From david.freedman at uk.clara.net Tue Sep 28 15:42:58 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 28 Sep 2010 14:42:58 +0100 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1E5CD.9040407@foobar.org> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1E5CD.9040407@foobar.org> Message-ID: <4CA1F0E2.1050908@uk.clara.net> Nick Hilliard wrote: > On 27/09/2010 23:35, Tony Li wrote: >> - We use ILNP (or similar) for v6 to decouple locators from identifiers. > > off-topic rambling: > > on the issue of decoupling locator and identifier, I'm still not really > sure that any L/I separation is really going to fix our problems in the > long term. In fact, we already use a form of locator / identifier > separation: ASN and prefix. We could - with some work - implement L/I > separation by creating a new BGP / core router model which made routing > decisions on the basis of AS identifier only, and not per-prefix. Excuse my ignorance on the subject, but I thought the purpose of L/I was to only route locators on the "internet" and to route "identifiers" (i.e belonging to services/people) via an overlay (but perhaps I've had my head in the LISP cloud for a while) You get a locator and it multihomes, locator aggregation is possible but not key to the system, the main objective to control the growth in terms of addressing requirement and punt the services and people to the overlay. > > But I can't help wondering that if we perform our routing decisions > based solely on locator (e.g. ASN or other) and not identifier, then we > commit ourselves to trashing our current traffic engineering > flexibilities. If we decide we want traffic engineering capabilities > again, we need to introduce a routing protocol which also discriminates > on the basis of the identifier. And that's hardly an improvement on > what we have right now. Nothing wrong with mapping identifier services to locator T/E, this easily achievable in an inspected (but possibly out of band) data plane model Dave. > > Nick > /me goes off to read up on the latest coolness for L/I separation which > hopefully deal with all these problems > -- David Freedman Group Network Engineering Claranet Group From fred at cisco.com Tue Sep 28 16:03:12 2010 From: fred at cisco.com (Fred Baker) Date: Tue, 28 Sep 2010 07:03:12 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1F0E2.1050908@uk.clara.net> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1E5CD.9040407@foobar.org> <4CA1F0E2.1050908@uk.clara.net> Message-ID: <0A658EEA-9939-4A1D-B302-2F89B956C1DC@cisco.com> On Sep 28, 2010, at 6:42 AM, David Freedman wrote: > Excuse my ignorance on the subject, but I thought the purpose of L/I was > to only route locators on the "internet" and to route "identifiers" (i.e > belonging to services/people) via an overlay (but perhaps I've had my > head in the LISP cloud for a while) That is certainly the LISP view of it. The statement of the concept originates from the NIMROD architecture proposed by Noel Chiappa in the early 1990's. The premise was that the network was composed of a number of networks, which were described using "maps", which is to say "bags of addresses with attributes and inter-map interconnectivity"; that is recursive, so one map might summarize a number of other maps. The description of an address built on the experience in XNS and related protocols (as opposed to DECNET IV, which used a machine identifier and routed to it, and as opposed to IPv4, which identifies an interface and embeds location and identity into the address) with explicit representation of identity and location separately. You might read RFC 1992 for a deeper discussion of that. GSE, which ILNP and NAT66 are based on, instead of creating a tunnel overlay as LISP does, treats the IPv6 prefix as location and the EID as identity. Like IPv4, IPv6 routes to an interface; unlike IPv4, it strongly distinguishes between location and identity in that sense. The thing I wish was there, and really isn't in a coherent manner although HIP takes a stab in this direction, was an identity for a set of processes, what today nearly 20 years later we instantiate on a virtual machine. From mksmith at adhost.com Tue Sep 28 16:58:43 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 28 Sep 2010 07:58:43 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA15534.7000509@gmail.com> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net><4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> > -----Original Message----- > From: ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de > [mailto:ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de] On > Behalf Of Brian E Carpenter > Sent: Monday, September 27, 2010 7:39 PM > To: Doug Barton > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: I-D Action:draft-azinger-scalable-addressing-00.txt > > On 2010-09-28 11:03, Doug Barton wrote: > > On 9/27/2010 2:36 PM, Fred Baker wrote: > >> > >> On Sep 27, 2010, at 2:24 PM, Doug Barton wrote: > >>> So this is one more strong argument for IPv6 PI in as many places > >>> as humanly possible. > > > >>> Please note that I am not suggesting that this is a "fire and > >>> forget" solution, I'm aware that even in IPv6-topia there will > >>> still be renumbering due to organizational changes (e.g., mergers > >>> and acquisitions) but we really should be focusing on IPv6 PI as > >>> the answer, not as the problem. > >> > >> So you would very strongly prefer a world in which router memory > >> sizes are required to be effectively infinite. > > > > Easy there tiger, that's not at all what I said, and it's not even close > > to what I think. Someone else already pointed out that where they have > > 2-4 IPv4 blocks advertised now, they could easily get by with just 1 > > IPv6 announcement. In my book that's making the routing table smaller, > > not larger. :) > > > > What I'm advocating is not blindly bloating the routing table ad > > infinitum. What I'm suggesting is that we look at the whole chess board. > > Right, one BGP4 update on the first square, two BGP4 updates on the second > square, four on the third square, and so on... > > The question is, as Fred was I think getting at, where do you stop? > > If you arrange guidelines and policies such that you stop at, say, > a few hundred thousand PI prefixes announced world-wide, we can hope > that > the routers won't melt. > > If you arrange guidelines and policies such that you head towards ten > million PI prefixes announced in BGP4, then San Jose, we got a problem. > > I think this is what the IETF, and v6ops specifically, needs to > communicate on a technical basis to the RIR and ops community. > People on this list here probably know it, but not everybody. > > Beyond that, please read draft-irtf-rrg-recommendation, but > remember that it's only words. > > Brian I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic. - I have a /32 that I announce through my various upstreams - no more specifics, just one /32. - I get a /48 from my upstream out of their /32. I announce my /48 through my various providers - I pressure my provider into announcing my /48 as well for traffic engineering - Now we have a /32 and a /48 in the table. - Rinse, repeat How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable? Regards, Mike From tony.li at tony.li Tue Sep 28 18:12:39 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 28 Sep 2010 09:12:39 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net><4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> Message-ID: Michael, > I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic. > > - I have a /32 that I announce through my various upstreams - no more specifics, just one /32. > - I get a /48 from my upstream out of their /32. I announce my /48 through my various providers > - I pressure my provider into announcing my /48 as well for traffic engineering Here's your problem. No routing architecture can scale if everyone injects every arbitrary prefix into the DFZ. > - Now we have a /32 and a /48 in the table. > - Rinse, repeat > > How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable? No, but if you had PA with ILNP, you'd have N different prefixes, one from each of your upstreams. Your hosts would seamlessly switch between each of these prefixes. None of them would need to be globally visible and would be part of our upstreams aggregates. Tony From tony.li at tony.li Tue Sep 28 18:22:56 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 28 Sep 2010 09:22:56 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <4CA1E5CD.9040407@foobar.org> References: <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <61F34A90-2CF9-4B82-838A-500C5C428B54@tony.li> <4C9FD422.5090308@gmail.com> <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1E5CD.9040407@foobar.org> Message-ID: <0662DE5C-795B-41ED-A01A-F8FADE377050@tony.li> > on the issue of decoupling locator and identifier, I'm still not really sure that any L/I separation is really going to fix our problems in the long term. In fact, we already use a form of locator / identifier separation: ASN and prefix. We could - with some work - implement L/I separation by creating a new BGP / core router model which made routing decisions on the basis of AS identifier only, and not per-prefix. L/I separation gives us multi-homing without global prefix injection. We could translate the current model into the AS number space, but then the routing architecture won't scale to route 4 billion ASes. This just pushes the scalability problem into a different number space. The only way to resolve the scalability problem is to avoid global scope. > But I can't help wondering that if we perform our routing decisions based solely on locator (e.g. ASN or other) and not identifier, then we commit ourselves to trashing our current traffic engineering flexibilities. If we decide we want traffic engineering capabilities again, we need to introduce a routing protocol which also discriminates on the basis of the identifier. And that's hardly an improvement on what we have right now. Current traffic engineering is only done based on global distribution of more-specific prefixes. We can either remove the 'global' aspect, choose something else to engineer on, or give up our current 'traffic engineering' capabilities. So far, proposals (scoping of prefixes) to fix this have had a 'no thank you'. Tony From mksmith at adhost.com Tue Sep 28 18:26:41 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 28 Sep 2010 09:26:41 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net><4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F044E5@ad-exh01.adhost.lan> > -----Original Message----- > From: Tony Li [mailto:tony.li at tony.li] > Sent: Tuesday, September 28, 2010 9:13 AM > To: Michael K. Smith - Adhost > Cc: Brian E Carpenter; ipv6-ops at lists.cluenet.de > Subject: Re: I-D Action:draft-azinger-scalable-addressing-00.txt > > > Michael, > > > I'm trying to wrap my brain around how PA space is going to be "better" > than PI space. Follow my potentially flawed logic. > > > > - I have a /32 that I announce through my various upstreams - no more > specifics, just one /32. > > - I get a /48 from my upstream out of their /32. I announce my /48 through > my various providers > > - I pressure my provider into announcing my /48 as well for traffic > engineering > > > Here's your problem. No routing architecture can scale if everyone injects > every arbitrary prefix into the DFZ. > Understood. > > > - Now we have a /32 and a /48 in the table. > > - Rinse, repeat > > > > How is this better? Is it really anyone's assumption that I should be forced > into a one-upstream solution and that I would find that acceptable? > > > No, but if you had PA with ILNP, you'd have N different prefixes, one from > each of your upstreams. Your hosts would seamlessly switch between each > of these prefixes. None of them would need to be globally visible and would > be part of our upstreams aggregates. > > Tony Okay, so now I'm a content provider that *still* has to associate IP addresses to domain names for SSL-based services. I have four transit providers and about 80 direct peers. I now have to attach "an" IP (/64 likely) for each host from each provider to ensure reachability. And what of my peers? What will I announce to them? Regards, Mike From tony.li at tony.li Tue Sep 28 18:29:30 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 28 Sep 2010 09:29:30 -0700 Subject: Quoting RFC2860 [Re: I-D Action:draft-azinger-scalable-addressing-00.txt] In-Reply-To: <20100928084621.GD94643@ronin.4ever.de> References: <2CE3C2BE-66FF-4A16-A1FA-FCEF6E847A78@tony.li> <20100927093310.GX32268@Space.Net> <4E7F4221-1D7C-4AE9-AFCE-C5D0928D6D72@tony.li> <4CA0CDE4.3090503@rancid.berkeley.edu> <186AE719-D920-4232-8E85-63816104B29A@tony.li> <4CA0FEF5.5080808@dougbarton.us> <1874EE2D-4A04-41C0-B54E-9E857DA70362@tony.li> <4CA10674.9060508@dougbarton.us> <4CA1131D.4000301@foobar.org> <20100928084621.GD94643@ronin.4ever.de> Message-ID: <3119F0B7-710D-4A29-8FE7-E4EEBF96CB77@tony.li> > Apart from this: I have confidence in the hardware vendors to increase > TCAM sizes sufficiently in the future - generation by generation, of > course, because they want to sell us a new box every other year. Just a thought: are you prepared to pay the power bill for this? The power consumption of a TCAM is proportional to its size. Your power bill now scales with the size of the DFZ table. And Moore's law doesn't apply to power. ;-) Tony From cb.list6 at gmail.com Tue Sep 28 18:35:40 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 28 Sep 2010 09:35:40 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> Message-ID: > > How is this better? ?Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable? > It's not, and i believe that has been established time and time again. There are a basket full of nascent solutions in the pipe (ILNP ...) that will address some of this, maybe... time will tell. Today's addressing architecture, TE, multi-homing, peering and ultimately ISP BGP policy are all function of economics in this space. Right? Internet architecture is not very prescriptive, it has evolved based on various economic (which includes technology ...) stimuli with a handful of architectural guidelines. Right now, the various policy bodies are trying to roll out IPv6 because it is good policy. Making IPv6 easy is the right thing to do right now, and that includes PI .... /32s or /48s, it does not matter. Having been reject for IPv4 space in 2005, having rolled out BOGONs to customer in 2008, .... i know that IPv4 is hurt and is not a good place for growing services to be (mobile). The problem statement is that lots PI is not great in the long run because it is expensive in the DFZ. Instead of having the DFZ providers absorb the cost of ever growing RIB, the RIR should make PI uncomfortable for people that don't really need it that bad. Perhaps have a fee schedule that ramps up over time? Cheap now, and increasingly expensive over time? Make it simple, but increasingly painful, and predictable. Nobody likes surprises. If not, the DFZ will grow, and the DFZ providers will pass the cost on to the end sites yet again. Nobody rides for free, and no the internet will not break. I believe the consensus is that providing negative incentives to PI early is good, but we need to be gentle now as deployment of IPv6 ramps up. Lets keep in mind it is all about business, the stakeholders that control the money (probably not on this list) are not motivated to do the right thing for the DFZ. That said, make the DFZ issue a small business issue for the end sites before it is a large business issue for the DFZ providers.. Today, i believe the RIRs are in a good place to do that. Moreover, it is best for the RIR to decide how to do that. Cameron ====== http://groups.google.com/group/tmoipv6beta ====== From tony.li at tony.li Tue Sep 28 18:40:25 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 28 Sep 2010 09:40:25 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F044E5@ad-exh01.adhost.lan> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net><4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031608F044E5@ad-exh01.adhost.lan> Message-ID: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> > Okay, so now I'm a content provider that *still* has to associate IP > addresses to domain names for SSL-based services. I have four transit > providers and about 80 direct peers. I now have to attach "an" IP (/64 > likely) for each host from each provider to ensure reachability. And > what of my peers? What will I announce to them? Well, this is frankly a pretty clear case of a grossly multi-homed domain that topologically makes sense to be PI. However, if you wanted to do this with PA, you'd get 84 prefixes, one from each of your upstreams. You'd advertise 84 locators for your domain via DNS. And nothing in BGP would be in the DFZ. Tony From gert at space.net Tue Sep 28 21:57:22 2010 From: gert at space.net (Gert Doering) Date: Tue, 28 Sep 2010 21:57:22 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> Message-ID: <20100928195722.GL32268@Space.Net> Hi, On Tue, Sep 28, 2010 at 09:35:40AM -0700, Cameron Byrne wrote: > The problem statement is that lots PI is not great in the long run > because it is expensive in the DFZ. Instead of having the DFZ > providers absorb the cost of ever growing RIB, the RIR should make PI > uncomfortable for people that don't really need it that bad. That's actually what we try in RIPE land - tack a heap of paperwork to a PI network, and a yearly fee. Not high enough to seriously impact larger enterprises, but annoying enough to drive away "barbershop sized businesses". Which I think is a reasonable compromise - the DFZ can (quite likely) handle "one prefix per large enterprise" (there's only so many of them), but it won't be able to handle one prefix for each garage shop. (So yes, we need other solutions for garage shops that want highly reliable Internet connectivity) [..] > Today, i > believe the RIRs are in a good place to do that. Moreover, it is best > for the RIR to decide how to do that. Seconded. But then, I'm obviously biased :-) Gert Doering -- RIPE Address Policy WG Chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From surfer at mauigateway.com Tue Sep 28 22:12:44 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 28 Sep 2010 13:12:44 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt Message-ID: <20100928131244.1E6A074D@resin11.mta.everyone.net> --- gert at space.net wrote: From: Gert Doering That's actually what we try in RIPE land - tack a heap of paperwork to a PI network, and a yearly fee. Not high enough to seriously impact larger enterprises, but annoying enough to drive away "barbershop sized businesses". (So yes, we need other solutions for garage shops that want highly reliable Internet connectivity) ------------------------------------------------ Yes. Many of those 'garage shop' folks have innovated in ways not expected by the establishment. They need to be encouraged at every opportunity and not have stumbling blocks put in the way... scott From lists at c4inet.net Tue Sep 28 22:27:44 2010 From: lists at c4inet.net (Sascha Luck) Date: Tue, 28 Sep 2010 20:27:44 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928195722.GL32268@Space.Net> References: <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> Message-ID: <20100928202744.GA20788@cilantro.c4inet.net> On Tue, Sep 28, 2010 at 09:57:22PM +0200, Gert Doering wrote: >That's actually what we try in RIPE land - tack a heap of paperwork >to a PI network, and a yearly fee. Not high enough to seriously impact >larger enterprises, but annoying enough to drive away "barbershop sized >businesses". And this is what will ultimately turn around and bite you in the arse since it is blatantly anticompetitive and thus illegal. I hope I'll see that day soon. rgds, s. From brian.e.carpenter at gmail.com Tue Sep 28 22:48:17 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 29 Sep 2010 09:48:17 +1300 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net><4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> Message-ID: <4CA25491.1040803@gmail.com> On 2010-09-29 03:58, Michael K. Smith - Adhost wrote: ... > > I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic. > > - I have a /32 that I announce through my various upstreams - no more specifics, just one /32. > - I get a /48 from my upstream out of their /32. I announce my /48 through my various providers > - I pressure my provider into announcing my /48 as well for traffic engineering > - Now we have a /32 and a /48 in the table. > - Rinse, repeat > > How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable? Tony replied correctly, and indeed I teach graduate students that it isn't better, so it must be true :-). To be clear, the classical model for scalable PA-based multihoming in IPv6 is and always was that a multihomed site would simultaneously operate a different PA prefix from each of its ISPs and each host would simultaneously have N addresses, one for each of those ISPs. Whether you like it or not, this works perfectly and allows complete aggregation. Shim6 was designed to provide for session survival in that situation. This works too. The problem is, site IT managers don't seem to like this model and its implication of renumbering when you add or drop an ISP. (Whether ISPs like it or not is somewhat irrelevant, because they have no say in whether a site chooses to operate this way. Even the fact that it messes with current methods of BGP-based traffic engineering is not an objection that ISPs can force onto site IT managers.) Hence, the RRG work, LISP, ILNP, etc. Been there, discussed that, and here we are with PI as the only deployed alternative. Grumble. Brian From gert at space.net Tue Sep 28 22:49:29 2010 From: gert at space.net (Gert Doering) Date: Tue, 28 Sep 2010 22:49:29 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928202744.GA20788@cilantro.c4inet.net> References: <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> Message-ID: <20100928204929.GM32268@Space.Net> Hi, On Tue, Sep 28, 2010 at 08:27:44PM +0000, Sascha Luck wrote: > On Tue, Sep 28, 2010 at 09:57:22PM +0200, Gert Doering wrote: > >That's actually what we try in RIPE land - tack a heap of paperwork > >to a PI network, and a yearly fee. Not high enough to seriously impact > >larger enterprises, but annoying enough to drive away "barbershop sized > >businesses". > > And this is what will ultimately turn around and bite you in the arse > since it is blatantly anticompetitive and thus illegal. I hope I'll see > that day soon. So what's your approach? Close down the Internet? Abandon PI? Give every ISP out there the money to sustain 4 billion routes? (It's no more anticompetitive, btw, than charging for gasoline - those who find it too expensive to use their car can use a bicycle. Having a policy that says "if you have less than 500 employees, you MUST NOT have a routing table slot" - now *that* would be anticompetitive) Gert Doering -- RIPE AP WG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Tue Sep 28 22:57:48 2010 From: gert at space.net (Gert Doering) Date: Tue, 28 Sep 2010 22:57:48 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA25491.1040803@gmail.com> References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> Message-ID: <20100928205748.GN32268@Space.Net> Hi, On Wed, Sep 29, 2010 at 09:48:17AM +1300, Brian E Carpenter wrote: > To be clear, the classical model for scalable PA-based multihoming in IPv6 > is and always was that a multihomed site would simultaneously operate a > different PA prefix from each of its ISPs and each host would simultaneously > have N addresses, one for each of those ISPs. Whether you like it or not, > this works perfectly and allows complete aggregation. I have serious doubt about the "works perfectly" part. The idea is very nice, in theory (and I do like the shim6 approach). Have the practical problems "how do I find the combination of source + destination IP out of a set of N possible sources and M destination addresses that works 'best' for me" (with locally varying metrics for what is 'better' - latency, throughput, price, firewall policies, upstream RPF) been solved by now? (This is partly rhetorical question, and partly real curiosity: that always seemed to me the hard part, and I really wonder whether I missed some new developments here that would make this applicable for companies like Petra's, with 5 uplinks, strong requirements for certain destinations to be reached via a specific uplink, firewalls all over the place, etc.) gert -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tony.li at tony.li Tue Sep 28 23:12:28 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 28 Sep 2010 14:12:28 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928205748.GN32268@Space.Net> References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> Message-ID: > Have the practical problems "how do I find the combination of source + > destination IP out of a set of N possible sources and M destination > addresses that works 'best' for me" (with locally varying metrics for > what is 'better' - latency, throughput, price, firewall policies, > upstream RPF) been solved by now? This is an orthogonal problem. PI doesn't solve it either. Note that the best answer is likely to be MPTCP. Tony From brian.e.carpenter at gmail.com Tue Sep 28 23:13:56 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 29 Sep 2010 10:13:56 +1300 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928205748.GN32268@Space.Net> References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> Message-ID: <4CA25A94.7070601@gmail.com> Hi Gert, On 2010-09-29 09:57, Gert Doering wrote: > Hi, > > On Wed, Sep 29, 2010 at 09:48:17AM +1300, Brian E Carpenter wrote: >> To be clear, the classical model for scalable PA-based multihoming in IPv6 >> is and always was that a multihomed site would simultaneously operate a >> different PA prefix from each of its ISPs and each host would simultaneously >> have N addresses, one for each of those ISPs. Whether you like it or not, >> this works perfectly and allows complete aggregation. > > I have serious doubt about the "works perfectly" part. > > The idea is very nice, in theory (and I do like the shim6 approach). > > Have the practical problems "how do I find the combination of source + > destination IP out of a set of N possible sources and M destination > addresses that works 'best' for me" (with locally varying metrics for > what is 'better' - latency, throughput, price, firewall policies, > upstream RPF) been solved by now? > > (This is partly rhetorical question, and partly real curiosity: that always > seemed to me the hard part, and I really wonder whether I missed some > new developments here that would make this applicable for companies like > Petra's, with 5 uplinks, strong requirements for certain destinations to > be reached via a specific uplink, firewalls all over the place, etc.) Shim6 does it by probing with REAP if the initial path fails. Choosing the "best" path initially is indeed a hard problem. Brian From lists at c4inet.net Wed Sep 29 00:26:32 2010 From: lists at c4inet.net (Sascha Luck) Date: Tue, 28 Sep 2010 22:26:32 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928204929.GM32268@Space.Net> References: <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> Message-ID: <20100928222632.GA21453@cilantro.c4inet.net> On Tue, Sep 28, 2010 at 10:49:29PM +0200, Gert Doering wrote: >On Tue, Sep 28, 2010 at 08:27:44PM +0000, Sascha Luck wrote: >> On Tue, Sep 28, 2010 at 09:57:22PM +0200, Gert Doering wrote: >> >That's actually what we try in RIPE land - tack a heap of paperwork >> >to a PI network, and a yearly fee. Not high enough to seriously impact >> >larger enterprises, but annoying enough to drive away "barbershop sized >> >businesses". >> >> And this is what will ultimately turn around and bite you in the arse >> since it is blatantly anticompetitive and thus illegal. I hope I'll see >> that day soon. > >So what's your approach? Close down the Internet? Abandon PI? Give >every ISP out there the money to sustain 4 billion routes? If there is a problem at all, it is a technical one. (I'm not convinced there is, 329k routes today and the internet is still not dead.) Spend a fraction of the resources used trying to protect Big Telco's investments on R&D for a new DFZ routing protocol and this could be solved long before any hard limits are reached. >(It's no more anticompetitive, btw, than charging for gasoline - those >who find it too expensive to use their car can use a bicycle. If petrol price was artifically inflated to an extent that only $large_enterprise could afford it, those responsible would be burned alive - and rightly so. Besides, you don't have to spend weeks convincing the attendant that you are using your tankful for legitimate purposes. This "policy" is *explicitly* designed to favour Big Telco who has a legal/compliance department to deal with that BS. > Having >a policy that says "if you have less than 500 employees, you MUST NOT > have a routing table slot" - now *that* would be anticompetitive) Effectively, 2007-01 does precisely that. You admitted as much yourself: "Not high enough to seriously impact larger enterprises, but annoying enough to drive away "barbershop sized businesses"" rgds, s. From ik5pvx at gmail.com Wed Sep 29 06:21:23 2010 From: ik5pvx at gmail.com (Pierfrancesco Caci) Date: Wed, 29 Sep 2010 06:21:23 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928222632.GA21453@cilantro.c4inet.net> References: <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> Message-ID: On Wed, Sep 29, 2010 at 00:26, Sascha Luck wrote: > Besides, you don't have to spend weeks convincing the attendant that you are > using your tankful for legitimate purposes. This "policy" is *explicitly* > designed to favour Big Telco who has a legal/compliance department to deal > with that BS. >> >> Having >a policy that says "if you have less than 500 employees, you MUST >> NOT >> have a routing table slot" - now *that* would be anticompetitive) > > Effectively, 2007-01 does precisely that. You admitted as much yourself: > "Not high enough to seriously impact larger enterprises, but annoying enough > to drive away "barbershop sized businesses"" > Hello. Big telco here. Believe me, 2007-01 is a pain in the rear for a big company with mammoth sized bureaucracy and we could happlily do without. But we are diverging the point of the initial discussion. Pf -- ?Pierfrancesco Caci From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 29 07:37:39 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 29 Sep 2010 15:07:39 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA25491.1040803@gmail.com> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> Message-ID: <20100929150739.249e8a1a@opy.nosense.org> On Wed, 29 Sep 2010 09:48:17 +1300 Brian E Carpenter wrote: > On 2010-09-29 03:58, Michael K. Smith - Adhost wrote: > ... > > > > I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic. > > > > - I have a /32 that I announce through my various upstreams - no more specifics, just one /32. > > - I get a /48 from my upstream out of their /32. I announce my /48 through my various providers > > - I pressure my provider into announcing my /48 as well for traffic engineering > > - Now we have a /32 and a /48 in the table. > > - Rinse, repeat > > > > How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable? > > Tony replied correctly, and indeed I teach graduate students that it isn't > better, so it must be true :-). > > To be clear, the classical model for scalable PA-based multihoming in IPv6 > is and always was that a multihomed site would simultaneously operate a > different PA prefix from each of its ISPs and each host would simultaneously > have N addresses, one for each of those ISPs. Whether you like it or not, > this works perfectly and allows complete aggregation. Shim6 was designed to > provide for session survival in that situation. This works too. > > The problem is, site IT managers don't seem to like this model and its > implication of renumbering when you add or drop an ISP. I think one of the key things they may not realise, probably because they are just treating IPv6 as nothing more than IPv4 with bigger addresses, is that there is a transition period where the old addresses are phased out, potentially over a number of weeks or months. They probably assume it is an instant event that doesn't give them any preparation time to manage the process of e.g. updating ACLs, router interface configurations etc. It'd be interesting to specifically ask these IT managers, when they express this opinion, if they're aware of the IPv6 address valid and preferred lifetime mechanisms, and how they were planned to be used to cope with a renumbering event. It'd also be interesting to ask them if they're aware of ULA addresses, and how they are designed to facilitate stable internal communications regardless of whether global address renumbering is happening or not. I sometimes wonder if a lack of awareness or understanding of IPv6's capabilities is the actual cause of some of the objections to it. > (Whether ISPs > like it or not is somewhat irrelevant, because they have no say in whether > a site chooses to operate this way. Even the fact that it messes with > current methods of BGP-based traffic engineering is not an objection > that ISPs can force onto site IT managers.) > > Hence, the RRG work, LISP, ILNP, etc. Been there, discussed that, and > here we are with PI as the only deployed alternative. Grumble. > > Brian Regards, Mark. From dougb at dougbarton.us Wed Sep 29 08:33:05 2010 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 28 Sep 2010 23:33:05 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929150739.249e8a1a@opy.nosense.org> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929150739.249e8a1a@opy.nosense.org> Message-ID: <4CA2DDA1.5010006@dougbarton.us> On 9/28/2010 10:37 PM, Mark Smith wrote: > I think one of the key things they may not realise, probably > because they are just treating IPv6 as nothing more than IPv4 with > bigger addresses, is that there is a transition period where the old > addresses are phased out, potentially over a number of weeks or months. > They probably assume it is an instant event that doesn't give them any > preparation time to manage the process of e.g. updating ACLs, router > interface configurations etc. A) Add "years" to your list of time periods. Just because an enterprise gets v6 doesn't mean their v4 magically goes away, and B) Do you have *any* evidence for this perspective at all? Because I'm not seeing it (the perspective you describe that is). Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From ben at bjencks.net Wed Sep 29 08:45:53 2010 From: ben at bjencks.net (Ben Jencks) Date: Wed, 29 Sep 2010 02:45:53 -0400 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA2DDA1.5010006@dougbarton.us> References: <4C9E4D6E.2040605@berkeley.edu> <20100926124557.12500631@opy.nosense.org> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929150739.249e8a1a@opy.nosense.org> <4CA2DDA1.5010006@dougbarton.us> Message-ID: On Wed, Sep 29, 2010 at 02:33, Doug Barton wrote: > On 9/28/2010 10:37 PM, Mark Smith wrote: >> >> I think one of the key things they may not realise, probably >> because they are just treating IPv6 as nothing more than IPv4 with >> bigger addresses, is that there is a transition period where the old >> addresses are phased out, potentially over a number of weeks or months. >> They probably assume it is an instant event that doesn't give them any >> preparation time to manage the process of e.g. updating ACLs, router >> interface configurations etc. > > A) Add "years" to your list of time periods. Just because an enterprise gets > v6 doesn't mean their v4 magically goes away, and > > B) Do you have *any* evidence for this perspective at all? Because I'm not > seeing it (the perspective you describe that is). Doug, I think Mark is talking about renumbering from one v6 prefix to another, not about v4 to v6 migration. Specifically, the idea that you can add the new v6 prefix to your network, run both prefixes on all your hosts as you bring the new one up to full functionality, and only then remove the old one as a renumbering strategy. I'd like to add that while this may have been designed in from the beginning, v6 stacks these days still are not completely functional when multihomed on a single interface. There are a few internet drafts out there that provide most of a solution, but they're not RFCs yet, and they're certainly very far from implementation. Specifically, source address selection is fairly broken in most cases, and the proposed solution is to give the hosts better information (which source prefix to use for which destinations) through DHCP. -Ben From slz at baycix.de Wed Sep 29 09:38:07 2010 From: slz at baycix.de (Sascha Lenz) Date: Wed, 29 Sep 2010 09:38:07 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928222632.GA21453@cilantro.c4inet.net> References: <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> Message-ID: <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> Hi, Am 29.09.2010 um 00:26 schrieb Sascha Luck: [...] > > If petrol price was artifically inflated to an extent that only $large_enterprise could afford it, those responsible would be burned alive - and rightly so. > Besides, you don't have to spend weeks convincing the attendant that you are > using your tankful for legitimate purposes. This "policy" is *explicitly* designed to favour Big Telco who has a legal/compliance department to deal with that BS. seriously? Your "barbershop" is incapable of a) signing a contract from a LIR b) finding a copy of your company registration papers and c) pay the what - 100?200? bucks a year the LIR might charge for this? Wow, how on earth does this "barbershop" do their real barber business if they are unable to sign contracts and don't have some cent a day to pay their suppliers? I wasn't aware that you need a legal department for signing contracts with your suppliers and they give you their goods for free. Must have missed that. Or on-topic: The current policy (in RIPE-land, possibly other RIR's too) is the right way to go, not this draft: Limit the use of PI by making it more complicated to obtain and maintain than PA, but don't forbid it, if someone needs PI, they need to be able to get it. There is no other real multihoming solution yet and becoming a LIR is not always an option/too expensive. The former solution about "PI doesn't cost anything - ever, requires almost no paperwork and has multiple advantages over PA" is quite stupid in the light of what also was discussed in this thread here. We really don't need the DFZ polluted more than absolutely necessary. This really might get problematic one day with IPv6. But not allowing PI at all is even more stupid since it doesn't reflect the real world requirements. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Consultant BayCIX GmbH - http://www.baycix.de/ Schillerstra?e 2 D-84034 Landshut Tel. +49-1520-2773550 Fax. +49-871-9253629 Gesch?ftsf?hrer Thomas Zajac Registergericht Landshut HR B 4878 Ust-Ident: DE200684164 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100929/1696535b/attachment.html From spz at serpens.de Wed Sep 29 09:41:27 2010 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 29 Sep 2010 09:41:27 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA25491.1040803@gmail.com> References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> Message-ID: <20100929074125.GI27830@serpens.de> Thus wrote Brian E Carpenter (brian.e.carpenter at gmail.com): > The problem is, site IT managers don't seem to like this model and its > implication of renumbering when you add or drop an ISP. I'm currently a network admin 2 days a month, accumulated, the rest of the time I'm a sysadmin. The thing -I- seriously don't like about this model is that it puts the decision about routing on the communication endpoints, all of them, in their precious multitude and variability. The model expects that every last desktop OS has a perfect and sophisticated network stack, and that it will remain bugless forever and anon even in rarely used variants. This is quite unrealistic. As a result, you'd turn network admin into a job that scales with the number of hosts, not with the number of routers. Balance the cost of this manpower against the cost of running BGP. With enough hosts, BGP will be cheaper -> all sites above a certain size that require resilient networking will want their own presence in the DFZ. I'd guesstimate the flip point at about ~100 hosts that actually need to have connectivity (as opposed to, need to be able to talk to a web proxy and mail server). regards, spz -- spz at serpens.de (S.P.Zeidler) From he at nordu.net Wed Sep 29 10:18:10 2010 From: he at nordu.net (Havard Eidnes) Date: Wed, 29 Sep 2010 10:18:10 +0200 (CEST) Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> References: <17838240D9A5544AAA5FF95F8D52031608F044E5@ad-exh01.adhost.lan> <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> Message-ID: <20100929.101810.84839995.he@uninett.no> >> Okay, so now I'm a content provider that *still* has to >> associate IP addresses to domain names for SSL-based services. >> I have four transit providers and about 80 direct peers. I >> now have to attach "an" IP (/64 likely) for each host from >> each provider to ensure reachability. And what of my peers? >> What will I announce to them? > > Well, this is frankly a pretty clear case of a grossly > multi-homed domain that topologically makes sense to be PI. > > However, if you wanted to do this with PA, you'd get 84 > prefixes, one from each of your upstreams. You'd advertise 84 > locators for your domain via DNS. And nothing in BGP would be > in the DFZ. 84?!? You've got to be kiddng! A peer isn't an upstream. Who's to say that a peer has any addresses to assign to you? The peer could just as well be a PA client of his upstream(s). In my book that would instead mean 4 PA prefixes (one per upstream provider, who actually provide you with bit transport for payment), where these more specific routes (typically 4x /48 prefixes) are announced to your peers. Regards, - H?vard From gert at space.net Wed Sep 29 10:24:26 2010 From: gert at space.net (Gert Doering) Date: Wed, 29 Sep 2010 10:24:26 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> Message-ID: <20100929082426.GP32268@Space.Net> Hi, On Tue, Sep 28, 2010 at 02:12:28PM -0700, Tony Li wrote: > > Have the practical problems "how do I find the combination of source + > > destination IP out of a set of N possible sources and M destination > > addresses that works 'best' for me" (with locally varying metrics for > > what is 'better' - latency, throughput, price, firewall policies, > > upstream RPF) been solved by now? > > This is an orthogonal problem. PI doesn't solve it either. With PI (on both ends), there is only one combination of source and destination IP address. Which makes this quite easy - try this combination, and if it works, it's the best possible option. Sounds "solved" to me. (And in networks with special policy requirements, the policy can be implemented on the network gear where it can be easily verified - and one doesn't have to test this on all different OS stacks in use to be sure it works everywhere). Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100929/ca7cdfe4/attachment.bin From tony.li at tony.li Wed Sep 29 10:25:25 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 01:25:25 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929.101810.84839995.he@uninett.no> References: <17838240D9A5544AAA5FF95F8D52031608F044E5@ad-exh01.adhost.lan> <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> Message-ID: On Sep 29, 2010, at 1:18 AM, Havard Eidnes wrote: > In my book that would instead mean 4 PA prefixes (one per > upstream provider, who actually provide you with bit transport > for payment), where these more specific routes (typically 4x /48 > prefixes) are announced to your peers. Resulting in 4 routes in the DFZ. Sorry, but PI is a better solution than that. ;-) Tony From gert at space.net Wed Sep 29 10:35:02 2010 From: gert at space.net (Gert Doering) Date: Wed, 29 Sep 2010 10:35:02 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928222632.GA21453@cilantro.c4inet.net> References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> Message-ID: <20100929083502.GQ32268@Space.Net> Hi, On Tue, Sep 28, 2010 at 10:26:32PM +0000, Sascha Luck wrote: > Besides, you don't have to spend weeks convincing the attendant that you are > using your tankful for legitimate purposes. This "policy" is *explicitly* > designed to favour Big Telco who has a legal/compliance department to deal > with that BS. Just to clean up some of the FUD. "Big Telcos" don't use PI (in IPv6), they use PA. Maybe you should get your facts straight before attacking people in public that try to find working compromises? What we have now is by no means the perfect solution, but it's a good compromise: it's balancing the extreme positions ("no PI at all" and "PI for everybody, I don't care for the routing table") into something that makes both sides unhappy, but both sides can (obviously) live with it, otherwise the policy would not have reached consensus. (And it took us 3 years to reach consensus, because the "we cannot have IPv6 PI at all!" camp was quite adamant about not opening the floodgates) > > Having >a policy that says "if you have less than 500 employees, you MUST NOT > > have a routing table slot" - now *that* would be anticompetitive) > > Effectively, 2007-01 does precisely that. You admitted as much yourself: > "Not high enough to seriously impact larger enterprises, but annoying > enough to drive away "barbershop sized businesses"" Signing the contract and paying 50 EUR a year is hardly something a garage shop cannot *afford*. But it makes them think on whether they really *need* this. PI is not a status symbol. It's one option in a tool box, and having some (trivial) hurdles in the way is there to make people think twice whether it's the right tool for them. Gert Doering -- RIPE APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From swmike at swm.pp.se Wed Sep 29 10:47:10 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 29 Sep 2010 10:47:10 +0200 (CEST) Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929083502.GQ32268@Space.Net> References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <20100929083502.GQ32268@Space.Net> Message-ID: On Wed, 29 Sep 2010, Gert Doering wrote: > What we have now is by no means the perfect solution, but it's a good > compromise: it's balancing the extreme positions ("no PI at all" and "PI > for everybody, I don't care for the routing table") into something that > makes both sides unhappy, but both sides can (obviously) live with it, > otherwise the policy would not have reached consensus. I would like a DFZ slot to cost at least USD1000 per year. I don't care who get's the money, I just want the money to be paid so people don't do it without good reason. Unfortunately there is no payment model that makes any sense apart from the ones currently paid to the RIR/LIR for holding the "resource" and I think that's also a fair compromise. -- Mikael Abrahamsson email: swmike at swm.pp.se From he at nordu.net Wed Sep 29 10:51:24 2010 From: he at nordu.net (Havard Eidnes) Date: Wed, 29 Sep 2010 10:51:24 +0200 (CEST) Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> Message-ID: <20100929.105124.33650253.he@uninett.no> >> In my book that would instead mean 4 PA prefixes (one per >> upstream provider, who actually provide you with bit transport >> for payment), where these more specific routes (typically 4x /48 >> prefixes) are announced to your peers. > > Resulting in 4 routes in the DFZ. Not necessarily. The extent ot the distribution of your routes would be into your peers networks. First off: who's to say those are part of the DFZ? With PA-client peers, that would probably not be the case. Also, do those routes need to be carried by every router which makes up the DFZ? I'd say "obviously not", that is, unless we're talking about peering between what we still call "tier-1" networks (which we're obviously not, since we're debating whether a given network can reasonably be given PA prefixes from his upstreams, and a "tier-1" network doesn't have any upstreams, only peers and customers). > Sorry, but PI is a better solution than that. ;-) With PI your route *must* be injected into the DFZ, and it *must* be carried to every remote corner of the planet which makes up the DFZ for it retain reasonable usefulness. Doing PI is like giving up from the start. I would claim that there's an engineering trade-off here where carrying one PI prefix in every router which makes up the DFZ costs more than having a smallish part of the DFZ carry 4 additional PA prefixes. Besides: then the decision of whether to peer and carry those additional prefixes can be a local one, whereas with a PI prefix, the decision for who needs to carry the prefix is already made a priori by someone else (the RIR), at the time of address assignment. Regards, - H?vard From spz at serpens.de Wed Sep 29 10:51:22 2010 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 29 Sep 2010 10:51:22 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA11989.1010605@foobar.org> References: <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA11989.1010605@foobar.org> Message-ID: <20100929085121.GJ27830@serpens.de> Thus wrote Nick Hilliard (nick at foobar.org): > On 27/09/2010 23:36, Fred Baker wrote: > >seem to think that the IETF (and therefore the vendors, as operators > >tell us they don't like to attend IETF meetings) > > In my case - and I suspect many others too - it's not a question of > "don't like", but rather "can't justify the budget or time > required". What Nick said. Would love to attend, would have to pay it myself, look at the price tag and pass. As to mailing lists: if you are a full-time employee and can't read IETF mailing lists on company time, it gets difficult. I'm currently trying to follow CGA-EXT and failing dismally :-} And that does have a direct impact on the (future of) my job. regards, spz -- spz at serpens.de (S.P.Zeidler) From gert at space.net Wed Sep 29 10:55:15 2010 From: gert at space.net (Gert Doering) Date: Wed, 29 Sep 2010 10:55:15 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <20100929083502.GQ32268@Space.Net> Message-ID: <20100929085515.GR32268@Space.Net> Hi, On Wed, Sep 29, 2010 at 10:47:10AM +0200, Mikael Abrahamsson wrote: > On Wed, 29 Sep 2010, Gert Doering wrote: > > > What we have now is by no means the perfect solution, but it's a good > > compromise: it's balancing the extreme positions ("no PI at all" and "PI > > for everybody, I don't care for the routing table") into something that > > makes both sides unhappy, but both sides can (obviously) live with it, > > otherwise the policy would not have reached consensus. > > I would like a DFZ slot to cost at least USD1000 per year. I don't care > who get's the money, I just want the money to be paid so people don't do > it without good reason. Yes, this is an idea I've also toyed with - and it would nicely self- regulate those that think they need to deaggregate their /16 into /24s today, etc. OTOH, I can already hear Sascha Luck screaming "evil cartel!!!"... > Unfortunately there is no payment model that makes any sense apart from > the ones currently paid to the RIR/LIR for holding the "resource" and I > think that's also a fair compromise. And indeed, payment & policing is going to make this fail - we already have arguments surrounding routing certificates due to people not wanting to give "anybody" control over their routing... Gert Doering -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100929/8f9743bf/attachment.bin From nick at foobar.org Wed Sep 29 11:18:10 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 Sep 2010 10:18:10 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <20100929083502.GQ32268@Space.Net> Message-ID: <4CA30452.8080306@foobar.org> On 29/09/2010 09:47, Mikael Abrahamsson wrote: > I would like a DFZ slot to cost at least USD1000 per year. I don't care who > get's the money, I just want the money to be paid so people don't do it > without good reason. It would be very, very difficult to charge this levy in such a way that it wouldn't be considered by a court of law to be a tax. Nick From nick at foobar.org Wed Sep 29 11:19:32 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 Sep 2010 10:19:32 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928222632.GA21453@cilantro.c4inet.net> References: <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> Message-ID: <4CA304A4.90308@foobar.org> On 28/09/2010 23:26, Sascha Luck wrote: > Effectively, 2007-01 does precisely that. Sascha, don't be ridiculous. ?50 per annum per assignment is peanuts compared to the charges for cross-connects, routers, expertise, hosting space, metro ethernet links, etc that you require for effective use of a PI block. "Anti-competitive" means that you discriminate against one or more specific groups of users. ?50 per annum does not discriminate against anyone. Nick From chbm at chbm.net Wed Sep 29 12:05:15 2010 From: chbm at chbm.net (Carlos Morgado) Date: Wed, 29 Sep 2010 11:05:15 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929.105124.33650253.he@uninett.no> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> <20100929.105124.33650253.he@uninett.no> Message-ID: Hi, I'm a bit late to the thread but I'd like to add an ISP point of view. A decent ISP will have maybe 3 or 4 upstreams. On the all-PA scenario this means 3 or 4 prefixes to manage through the network. I haven't seen any discussion about what this means to end users, do they get 4 prefixes on their home gateways ? This, as far as I know, isn't being covered in CPE development. In fact, the mass deployable equipments I know barely work with autoconfiguration of a single prefix let alone multiple prefixes. On the data center side this would mean provisioning 4 prefixes on each server and publishing them on DNS. Upstream providers don't change often so this wouldn't be a large operational effort. However this is leaking network topology into the DNS plane which means when a network problem occurs and an upstream is flaky or down the sysops need to update DNS to kill that mapping. Otherwise we get outages similar to what happens now when a site goes down on a dns balanced service. This is equally valid for end customer addressing, except it's suicide to try to reprovision a customer base in response to an outage with something like a 1 day fix estimate. The average day to day outage an ISP deals with today turns into a massive blackhole. On the application side I'm fairly confused as to happens when 2 multihomed machines talk to each other. Even with shims and all that we might get into a ridiculous situation where 2 hosts that share an upstream are talking to each other going halfway across the globe cause that's the addresses they resolved. If you move "route optimization" to the shim you end up with routing policy inside hosts. You might as well have everything running routing protocols. Digging my old wholesale provider hat out of the closet I'm fairly concerned all my wholesale customers are announced in my block and AS. If they mess up and their link goes down I have no way to tell the rest of the DFZ that route is not valid. I'll be peppered with their traffic and my boxes will be hard at work with icmp unreachables. In a nutshell, all-PA for multihomed breaks our expectations about what we learn on BGP. What I see happening is an all-PA policy driving everybody back to NAT to the great joy of network vendors. ISPs will only use fec0:: and CGN customers to their various PA spaces. Compounding to that, I fully expect some sites to elect one PA prefix to be "theirs" and then asking the other upstreams to route it (that shouldn't happen and so on, money talks ...). I've lived through this in v4 and it's pretty ugly on the administrative side. On the network side it's basically worse than handing out site specific prefixes. -- Carlos Morgado From lists at c4inet.net Wed Sep 29 17:52:22 2010 From: lists at c4inet.net (Sascha Luck) Date: Wed, 29 Sep 2010 15:52:22 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929085515.GR32268@Space.Net> References: <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <20100929083502.GQ32268@Space.Net> <20100929085515.GR32268@Space.Net> Message-ID: <20100929155222.GA25627@cilantro.c4inet.net> On Wed, Sep 29, 2010 at 10:55:15AM +0200, Gert Doering wrote: >Yes, this is an idea I've also toyed with - and it would nicely self- >regulate those that think they need to deaggregate their /16 into /24s >today, etc. > >OTOH, I can already hear Sascha Luck screaming "evil cartel!!!"... I don't de-aggregate my announcements, actually. If it should become neccessary to do so though, it will probably have to be done on the spot and *without* having to go through 2 weeks of RIPE bureaucracy, tyvm. >And indeed, payment & policing is going to make this fail - we already >have arguments surrounding routing certificates due to people not wanting >to give "anybody" control over their routing... At least on that I don't seem to be alone :) cheers, s. From lists at c4inet.net Wed Sep 29 18:00:05 2010 From: lists at c4inet.net (Sascha Luck) Date: Wed, 29 Sep 2010 16:00:05 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> Message-ID: <20100929160005.GB25627@cilantro.c4inet.net> On Wed, Sep 29, 2010 at 09:38:07AM +0200, Sascha Lenz wrote: > The current policy (in RIPE-land, possibly other RIR's too) > is the right way to go, not this draft: Limit the use of PI > by making it more complicated to obtain and maintain than PA, > but don't forbid it, if someone needs PI, they need to be able > to get it. There is no other real multihoming solution yet and > becoming a LIR is not always an option/too expensive. Better yet, abandon the PA/PI distinction entirely as it doesn't really have any value in IPv6 land. Let everyone who needs routable space get routable space and, by all means, become a RIR member. This should reasonably fulfil the 2007-01 objectives *and* might just lower membership fees for everyone. cheers, s. From lists at c4inet.net Wed Sep 29 18:15:18 2010 From: lists at c4inet.net (Mailing List Account) Date: Wed, 29 Sep 2010 16:15:18 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA304A4.90308@foobar.org> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <4CA304A4.90308@foobar.org> Message-ID: <20100929161518.GC25627@cilantro.c4inet.net> On Wed, Sep 29, 2010 at 10:19:32AM +0100, Nick Hilliard wrote: >don't be ridiculous. ?50 per annum per assignment is peanuts compared to >the charges for cross-connects, routers, expertise, hosting space, metro >ethernet links, etc that you require for effective use of a PI block. The 50 quid aren't the issue, really, nor is the contract signing. The problem is the bureaucracy and general intrusiveness (please give us a complete business plan for this space) as implemented. (Which is, to be fair, not the fault of the policy. Also I've not had a PIv6 request yet, so I don't know if that problem exists there to that extent.) It also, on further thought, doesn't impact the end-user as much as the small LIR that has to spend days to handle these requests. >"Anti-competitive" means that you discriminate against one or more specific >groups of users. ?50 per annum does not discriminate against anyone. Well, one can argue that the existence of "PI/PA space" separates address space users into two classes, "ISP" (the "landlord") and "end user" (the "serf" that preferrably is bound to the "land"). A distinction that I had hoped - to desperately try to stay on-topic - would go away with IPv6. cheers, s. From eugen at leitl.org Wed Sep 29 18:27:43 2010 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 29 Sep 2010 18:27:43 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100928222632.GA21453@cilantro.c4inet.net> References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> Message-ID: <20100929162743.GN3951@leitl.org> On Tue, Sep 28, 2010 at 10:26:32PM +0000, Sascha Luck wrote: > If there is a problem at all, it is a technical one. (I'm not convinced > there is, 329k routes today and the internet is still not dead.) Assume cut-through photonic routing, and suddenly memory, gates and time (vacuum or glass is your FIFO) become very precious. Local-knowledge geographic routing will be the only thing that will scale. > Spend a fraction of the resources used trying to protect Big Telco's > investments on R&D for a new DFZ routing protocol and this could be > solved long before any hard limits are reached. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From drc at virtualized.org Wed Sep 29 18:19:08 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 29 Sep 2010 12:19:08 -0400 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929160005.GB25627@cilantro.c4inet.net> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> <20100929160005.GB25627@cilantro.c4inet.net> Message-ID: Sascha, On Sep 29, 2010, at 12:00 PM, Sascha Luck wrote: > Better yet, abandon the PA/PI distinction entirely as it doesn't > really have any value in IPv6 land. "96 more bits. No magic." Given IPv6 uses the exact same routing technology as IPv4, if the PA/PI distinction was necessary with IPv4, it is necessary with IPv6. > Let everyone who needs routable space get routable space and, by all means, become a RIR member. No one is suggesting someone who needs routable space should be denied. What the draft is arguing is that in order for the routing system to scale, non-topologically significant sites should obtain (routable) address space from their provider. To be very clear, if we do not follow this approach (and there is no change in routing technology), we will repeat history: ISPs, in order to protect their infrastructure, _will_ start filtering out long prefixes and dampen route flaps. If you have a long PI prefix, you'll be free to contact the ISPs that are filtering your route (assuming you can find someone to announce it) and negotiate a fee for them to accept your prefix. It wasn't a lot of fun in the mid-90s. I doubt it'll be fun the second time around. Regards, -drc From nick at foobar.org Wed Sep 29 18:37:02 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 Sep 2010 17:37:02 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929161518.GC25627@cilantro.c4inet.net> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <4CA304A4.90308@foobar.org> <20100929161518.GC25627@cilantro.c4inet.net> Message-ID: <4CA36B2E.4070208@foobar.org> On 29/09/2010 17:15, Mailing List Account wrote: > The 50 quid aren't the issue, really, nor is the contract signing. The > problem is the bureaucracy and general intrusiveness (please give us a > complete business > plan for this space) as implemented. This is getting waaaay off topic, but my understanding is that the reason for the general levels of bureaucracy is because the overwhelming majority people tell the most ridiculous porkie pies to get IPv4 /24 blocks. FWIW, I'm trying to fix this problem too (and yes, am aware of shutting doors after the horses have bolted). Nick From lists at c4inet.net Wed Sep 29 18:58:46 2010 From: lists at c4inet.net (Mailing List Account) Date: Wed, 29 Sep 2010 16:58:46 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA36B2E.4070208@foobar.org> References: <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <4CA304A4.90308@foobar.org> <20100929161518.GC25627@cilantro.c4inet.net> <4CA36B2E.4070208@foobar.org> Message-ID: <20100929165846.GD25627@cilantro.c4inet.net> On Wed, Sep 29, 2010 at 05:37:02PM +0100, Nick Hilliard wrote: >This is getting waaaay off topic, but my understanding is that the reason >for the general levels of bureaucracy is because the overwhelming majority >people tell the most ridiculous porkie pies to get IPv4 /24 blocks. On-topic insofar as that, thankfully, should not need to be an issue with IPv6. Lower boundary for assignment size ftw. cheers, s. From lists at c4inet.net Wed Sep 29 19:07:49 2010 From: lists at c4inet.net (Sascha Luck) Date: Wed, 29 Sep 2010 17:07:49 +0000 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> <20100929160005.GB25627@cilantro.c4inet.net> Message-ID: <20100929170749.GE25627@cilantro.c4inet.net> On Wed, Sep 29, 2010 at 12:19:08PM -0400, David Conrad wrote: >To be very clear, if we do not follow this approach (and there is no change in >routing technology), we will repeat history: ISPs, in order to protect their >infrastructure, _will_ start filtering out long prefixes and dampen route Valid point, albeit probably not that much of a problem with current v6 address policy. Given a lower limit on v6 assignment size and the fact that you can probably fit both Facebook *and* Google into a /48 they would have to make a bit more of an effort. cheers, s. From sthaug at nethelp.no Wed Sep 29 20:08:47 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 29 Sep 2010 20:08:47 +0200 (CEST) Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> <20100929160005.GB25627@cilantro.c4inet.net> Message-ID: <20100929.200847.74683647.sthaug@nethelp.no> > To be very clear, if we do not follow this approach (and there is no > change in routing technology), we will repeat history: ISPs, in > order to protect their infrastructure, _will_ start filtering out > long prefixes and dampen route flaps. We're already blocking prefixes longer than /48. No dampening, though. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From aaronh at bind.com Wed Sep 29 20:21:53 2010 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 29 Sep 2010 11:21:53 -0700 Subject: [ipv6-ops] Re: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929.200847.74683647.sthaug@nethelp.no> References: <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> <20100929160005.GB25627@cilantro.c4inet.net> <20100929.200847.74683647.sthaug@nethelp.no> Message-ID: <20100929182150.GA68108@trace.bind.com> On Wed, Sep 29, 2010 at 08:08:47PM +0200, sthaug at nethelp.no wrote: > > To be very clear, if we do not follow this approach (and there is no > > change in routing technology), we will repeat history: ISPs, in > > order to protect their infrastructure, _will_ start filtering out > > long prefixes and dampen route flaps. > > We're already blocking prefixes longer than /48. No dampening, though. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no +1 Cheers, Aaron -- Aaron Hughes aaronh at bind.com +1-831-824-4161 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From tony.li at tony.li Wed Sep 29 20:26:27 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 11:26:27 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929082426.GP32268@Space.Net> References: <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> Message-ID: >>> Have the practical problems "how do I find the combination of source + >>> destination IP out of a set of N possible sources and M destination >>> addresses that works 'best' for me" (with locally varying metrics for >>> what is 'better' - latency, throughput, price, firewall policies, >>> upstream RPF) been solved by now? >> >> This is an orthogonal problem. PI doesn't solve it either. > > With PI (on both ends), there is only one combination of source and > destination IP address. Which makes this quite easy - try this > combination, and if it works, it's the best possible option. Sounds > "solved" to me. No, you only tried one path. There's no way to say that this is 'best'. Tony From dougb at dougbarton.us Wed Sep 29 20:34:06 2010 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 29 Sep 2010 11:34:06 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4C9E4D6E.2040605@berkeley.edu> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929150739.249e8a1a@opy.nosense.org> <4CA2DDA1.5010006@dougbarton.us> Message-ID: <4CA3869E.6000402@dougbarton.us> On 9/28/2010 11:45 PM, Ben Jencks wrote: > Doug, > > I think Mark is talking about renumbering from one v6 prefix to > another, not about v4 to v6 migration. Specifically, the idea that you > can add the new v6 prefix to your network, run both prefixes on all > your hosts as you bring the new one up to full functionality, and only > then remove the old one as a renumbering strategy. If that's the case, feel free to ignore my post then, sorry. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From tony.li at tony.li Wed Sep 29 20:38:17 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 11:38:17 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> <20100929.105124.33650253.he@uninett.no> Message-ID: On Sep 29, 2010, at 3:05 AM, Carlos Morgado wrote: > A decent ISP will have maybe 3 or 4 upstreams. On the all-PA scenario this means 3 or 4 prefixes to manage through the network. What we proposed was that ISPs get PI. > I haven't seen any discussion about what this means to end users, do they get 4 prefixes on their home gateways ? This, as far as I know, isn't being covered in CPE development. In fact, the mass deployable equipments I know barely work with autoconfiguration of a single prefix let alone multiple prefixes. If the end site is multi-homed, yes, exactly, there would be 4 prefixes. This is the architectural change that we need to make if we want to have scalable multi-homing. > However this is leaking network topology into the DNS plane which means when a network problem occurs and an upstream is flaky or down the sysops need to update DNS to kill that mapping. Otherwise we get outages similar to what happens now when a site goes down on a dns balanced service. This is something that could be reasonably automated. > This is equally valid for end customer addressing, except it's suicide to try to reprovision a customer base in response to an outage with something like a 1 day fix estimate. The average day to day outage an ISP deals with today turns into a massive blackhole. Well, if ILNP is in use, then it's possible to use any of the locators. So it's not a blackhole. > On the application side I'm fairly confused as to happens when 2 multihomed machines talk to each other. Even with shims and all that we might get into a ridiculous situation where 2 hosts that share an upstream are talking to each other going halfway across the globe cause that's the addresses they resolved. If you move "route optimization" to the shim you end up with routing policy inside hosts. You might as well have everything running routing protocols. This is already what can happen. ;-) If you want optimization, the best known path is to go to MPTCP, which will actually try a variety of paths. > What I see happening is an all-PA policy driving everybody back to NAT to the great joy of network vendors. That would cause no joy. No one _wants_ to build NAT. Tony From tony.li at tony.li Wed Sep 29 20:39:46 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 11:39:46 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929.105124.33650253.he@uninett.no> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> <20100929.105124.33650253.he@uninett.no> Message-ID: >> Resulting in 4 routes in the DFZ. > > Not necessarily. The extent ot the distribution of your routes > would be into your peers networks. First off: who's to say those > are part of the DFZ? With PA-client peers, that would probably > not be the case. Also, do those routes need to be carried by > every router which makes up the DFZ? I'd say "obviously not", > that is, unless we're talking about peering between what we still > call "tier-1" networks (which we're obviously not, since we're > debating whether a given network can reasonably be given PA > prefixes from his upstreams, and a "tier-1" network doesn't have > any upstreams, only peers and customers). Except that in the practical world, what happens is that everything goes to the DFZ today. Tony From mksmith at adhost.com Wed Sep 29 21:01:28 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 29 Sep 2010 12:01:28 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li><20100929.101810.84839995.he@uninett.no><20100929.105124.33650253.he@uninett.no> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F0465E@ad-exh01.adhost.lan> > > > However this is leaking network topology into the DNS plane which means > when a network problem occurs and an upstream is flaky or down the sysops > need to update DNS to kill that mapping. Otherwise we get outages similar to > what happens now when a site goes down on a dns balanced service. > > > This is something that could be reasonably automated. My Google Fu is failing me. Can someone point me to the RFC(s) that reference the DNS plane for routing updates? Thanks in advance, Mike From tony.li at tony.li Wed Sep 29 21:17:45 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 12:17:45 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F0465E@ad-exh01.adhost.lan> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li><20100929.101810.84839995.he@uninett.no><20100929.105124.33650253.he@uninett.no> <17838240D9A5544AAA5FF95F8D52031608F0465E@ad-exh01.adhost.lan> Message-ID: <5BAE73F1-0BBE-4C3F-B53F-0866AAB73F9E@tony.li> >>> However this is leaking network topology into the DNS plane which > means >> when a network problem occurs and an upstream is flaky or down the > sysops >> need to update DNS to kill that mapping. Otherwise we get outages > similar to >> what happens now when a site goes down on a dns balanced service. >> >> >> This is something that could be reasonably automated. > > > > My Google Fu is failing me. Can someone point me to the RFC(s) that > reference the DNS plane for routing updates? Try looking for dynamic DNSSEC. Tony From mksmith at adhost.com Wed Sep 29 21:28:41 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 29 Sep 2010 12:28:41 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <5BAE73F1-0BBE-4C3F-B53F-0866AAB73F9E@tony.li> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li><20100929.101810.84839995.he@uninett.no><20100929.105124.33650253.he@uninett.no> <17838240D9A5544AAA5FF95F8D52031608F0465E@ad-exh01.adhost.lan> <5BAE73F1-0BBE-4C3F-B53F-0866AAB73F9E@tony.li> Message-ID: <17838240D9A5544AAA5FF95F8D52031608F0466D@ad-exh01.adhost.lan> > -----Original Message----- > From: Tony Li [mailto:tony.li at tony.li] > Sent: Wednesday, September 29, 2010 12:18 PM > To: Michael K. Smith - Adhost > Cc: ipv6-ops at lists.cluenet.de > Subject: Re: I-D Action:draft-azinger-scalable-addressing-00.txt > > > >>> However this is leaking network topology into the DNS plane which > > means > >> when a network problem occurs and an upstream is flaky or down the > > sysops > >> need to update DNS to kill that mapping. Otherwise we get outages > > similar to > >> what happens now when a site goes down on a dns balanced service. > >> > >> > >> This is something that could be reasonably automated. > > > > > > > > My Google Fu is failing me. Can someone point me to the RFC(s) that > > reference the DNS plane for routing updates? > > > Try looking for dynamic DNSSEC. > > Tony Thanks. I'm assuming that all of these fast-flux routing updates are going to be handled by everyones existing DNS infrastructure. Has anyone addressed the issue with providers, some quite large, that don't honor TTL's? I'm imagining waiting 72 hours for a routing update. Regards, Mike From tony.li at tony.li Wed Sep 29 21:56:52 2010 From: tony.li at tony.li (Tony Li) Date: Wed, 29 Sep 2010 12:56:52 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <17838240D9A5544AAA5FF95F8D52031608F0466D@ad-exh01.adhost.lan> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li><20100929.101810.84839995.he@uninett.no><20100929.105124.33650253.he@uninett.no> <17838240D9A5544AAA5FF95F8D52031608F0465E@ad-exh01.adhost.lan> <5BAE73F1-0BBE-4C3F-B53F-0866AAB73F9E@tony.li> <17838240D9A5544AAA5FF95F8D52031608F0466D@ad-exh01.adhost.lan> Message-ID: <5AF7418B-2F4B-4956-99D0-E07D86FFC30F@tony.li> > Thanks. I'm assuming that all of these fast-flux routing updates are > going to be handled by everyones existing DNS infrastructure. Has > anyone addressed the issue with providers, some quite large, that don't > honor TTL's? I'm imagining waiting 72 hours for a routing update. a) It's not fast flux. It's at the rate of link failures as seen by the multi-homed end site. b) It's one RR that needs to change. c) Without the change, there can be a timeout in setting up the connection, OR you use MPTCP. Tony From brian.e.carpenter at gmail.com Wed Sep 29 22:24:00 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 30 Sep 2010 09:24:00 +1300 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929074125.GI27830@serpens.de> References: <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929074125.GI27830@serpens.de> Message-ID: <4CA3A060.3080906@gmail.com> I think the message below captures the problem with the multi-PA model perfectly. When we started out in this direction almost 15 years ago, exit router selection didn't seem like a big deal, but now it does. Solutions such as ILNP and LISP do offer a way out of this, but for short term deployment decisions, they're irrelevant. Regards Brian Carpenter On 2010-09-29 20:41, S.P.Zeidler wrote: > Thus wrote Brian E Carpenter (brian.e.carpenter at gmail.com): > >> The problem is, site IT managers don't seem to like this model and its >> implication of renumbering when you add or drop an ISP. > > I'm currently a network admin 2 days a month, accumulated, the rest of the > time I'm a sysadmin. The thing -I- seriously don't like about this model > is that it puts the decision about routing on the communication endpoints, > all of them, in their precious multitude and variability. > > The model expects that every last desktop OS has a perfect and > sophisticated network stack, and that it will remain bugless forever > and anon even in rarely used variants. This is quite unrealistic. > As a result, you'd turn network admin into a job that scales with the > number of hosts, not with the number of routers. > > Balance the cost of this manpower against the cost of running BGP. > With enough hosts, BGP will be cheaper -> all sites above a certain size > that require resilient networking will want their own presence in the DFZ. > I'd guesstimate the flip point at about ~100 hosts that actually need to > have connectivity (as opposed to, need to be able to talk to a web proxy > and mail server). > > regards, > spz From chbm at chbm.net Wed Sep 29 22:38:07 2010 From: chbm at chbm.net (Carlos Morgado) Date: Wed, 29 Sep 2010 21:38:07 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> <20100929.105124.33650253.he@uninett.no> Message-ID: <99470A67-C878-43B7-A879-C971FAF08FD8@chbm.net> On Sep 29, 2010, at 7:38 PM, Tony Li wrote: > > On Sep 29, 2010, at 3:05 AM, Carlos Morgado wrote: > >> A decent ISP will have maybe 3 or 4 upstreams. On the all-PA scenario this means 3 or 4 prefixes to manage through the network. > > > What we proposed was that ISPs get PI. > > >> I haven't seen any discussion about what this means to end users, do they get 4 prefixes on their home gateways ? This, as far as I know, isn't being covered in CPE development. In fact, the mass deployable equipments I know barely work with autoconfiguration of a single prefix let alone multiple prefixes. > > > If the end site is multi-homed, yes, exactly, there would be 4 prefixes. > > This is the architectural change that we need to make if we want to have scalable multi-homing. > I meant end users of the ISP which you said above would get PI so problem solved there. On the end site scenario I'm pretty sure they just a) go with NAT b) push one of the prefixes upstream everywhere c) most likely both. -- Carlos Morgado From brian.e.carpenter at gmail.com Wed Sep 29 23:03:27 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Thu, 30 Sep 2010 10:03:27 +1300 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <99470A67-C878-43B7-A879-C971FAF08FD8@chbm.net> References: <06B23E63-8F48-415A-B80D-B18092191CCD@tony.li> <20100929.101810.84839995.he@uninett.no> <20100929.105124.33650253.he@uninett.no> <99470A67-C878-43B7-A879-C971FAF08FD8@chbm.net> Message-ID: <4CA3A99F.1080400@gmail.com> Carlos, On 2010-09-30 09:38, Carlos Morgado wrote: > On Sep 29, 2010, at 7:38 PM, Tony Li wrote: > >> On Sep 29, 2010, at 3:05 AM, Carlos Morgado wrote: >> >>> A decent ISP will have maybe 3 or 4 upstreams. On the all-PA scenario this means 3 or 4 prefixes to manage through the network. >> >> What we proposed was that ISPs get PI. >> >> >>> I haven't seen any discussion about what this means to end users, do they get 4 prefixes on their home gateways ? This, as far as I know, isn't being covered in CPE development. In fact, the mass deployable equipments I know barely work with autoconfiguration of a single prefix let alone multiple prefixes. >> >> If the end site is multi-homed, yes, exactly, there would be 4 prefixes. >> >> This is the architectural change that we need to make if we want to have scalable multi-homing. >> > > I meant end users of the ISP which you said above would get PI so problem solved there. > On the end site scenario I'm pretty sure they just a) go with NAT b) push one of the prefixes upstream everywhere c) most likely both. It all depends on the site. Roughly, I see three categories (ignoring mobile customers for the moment). 1. Domestic or small office. They will do whatever their off-the-shelf CPE does. But I expect the vast majority will, as today, have a single ISP and will use whatever prefix the ISP gives them each time they reconnect the CPE. PA for them, but they won't even know it. Running as pure clients, or p2p nodes, they don't face any particular problem with PA. Here we are talking about hundreds of millions to a couple of billion customers world-wide. PI is unthinkable, but not needed. 2. Medium size businesses. They may be motivated to multihome, and they probably run their own servers as well as pure clients. These are the tricky ones, because the problems you and spz have described arise, and there are a few million such businesses in the world. If they all generate their own BGP4 announcement we are in serious trouble. Any RIR policy that drives in this direction spells doom. 3. Large to very large businesses. There isn't much doubt they will have problems with any solution except PI, but as long as there are only a limited number of them (100,000 world-wide?) we can presumably carry their prefixes. Mobile customers will end up looking very like wired domestic customers, under their carrier's PA prefix, although the reasons are different. Here we are also talking about hundreds of millions to several billion customers, so no PI please. There is a problem if a domestic style customer has both a fixed and mobile connection simultaneously. They are just going to have to use two prefixes, but if they are pure clients this shouldn't be too big a problem. Brian From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Sep 29 23:55:47 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 30 Sep 2010 07:25:47 +0930 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA3869E.6000402@dougbarton.us> References: <4C9E4D6E.2040605@berkeley.edu> <20100926133058.26d52ab4@opy.nosense.org> <53BCF201-9D10-496A-8087-1FE098D1D974@virtualized.org> <962A9076-F2DD-4D60-99D2-5A9D99912EE2@tony.li> <62283C9E-AA7B-42F0-9A43-7763E971CB81@virtualized.org> <20100926091846.GU32268@Space.Net> <4C9FAB04.3050308@timmins.net> <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929150739.249e8a1a@opy.nosense.org> <4CA2DDA1.5010006@dougbarton.us> <4CA3869E.6000402@dougbarton.us> Message-ID: <20100930072547.30572cbc@opy.nosense.org> On Wed, 29 Sep 2010 11:34:06 -0700 Doug Barton wrote: > On 9/28/2010 11:45 PM, Ben Jencks wrote: > > Doug, > > > > I think Mark is talking about renumbering from one v6 prefix to > > another, not about v4 to v6 migration. Specifically, the idea that you > > can add the new v6 prefix to your network, run both prefixes on all > > your hosts as you bring the new one up to full functionality, and only > > then remove the old one as a renumbering strategy. > Yes, that was correct. > If that's the case, feel free to ignore my post then, sorry. :) > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > From gert at space.net Thu Sep 30 15:45:14 2010 From: gert at space.net (Gert Doering) Date: Thu, 30 Sep 2010 15:45:14 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100929160005.GB25627@cilantro.c4inet.net> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <20100928195722.GL32268@Space.Net> <20100928202744.GA20788@cilantro.c4inet.net> <20100928204929.GM32268@Space.Net> <20100928222632.GA21453@cilantro.c4inet.net> <97E18845-010F-4D88-A9F2-C161B8C66E15@baycix.de> <20100929160005.GB25627@cilantro.c4inet.net> Message-ID: <20100930134514.GB32268@Space.Net> Hi, On Wed, Sep 29, 2010 at 04:00:05PM +0000, Sascha Luck wrote: > Better yet, abandon the PA/PI distinction entirely as it doesn't > really have any value in IPv6 land. Let everyone who needs routable > space get routable space and, by all means, become a RIR member. > This should reasonably fulfil the 2007-01 objectives *and* might just > lower membership fees for everyone. You're welcome to make a policy proposal to that extent. I'm not sure that those who pay 50 EUR now and would have to pay 500+ EUR then would look favourably on it, though... Gert Doering -- RIPE APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Thu Sep 30 15:50:02 2010 From: gert at space.net (Gert Doering) Date: Thu, 30 Sep 2010 15:50:02 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> Message-ID: <20100930135002.GC32268@Space.Net> Hi, On Wed, Sep 29, 2010 at 11:26:27AM -0700, Tony Li wrote: > >>> Have the practical problems "how do I find the combination of source + > >>> destination IP out of a set of N possible sources and M destination > >>> addresses that works 'best' for me" (with locally varying metrics for > >>> what is 'better' - latency, throughput, price, firewall policies, > >>> upstream RPF) been solved by now? > >> > >> This is an orthogonal problem. PI doesn't solve it either. > > > > With PI (on both ends), there is only one combination of source and > > destination IP address. Which makes this quite easy - try this > > combination, and if it works, it's the best possible option. Sounds > > "solved" to me. > > No, you only tried one path. There's no way to say that this is 'best'. If there is a single path, it's by definition the "best". (It's also the worst, for sure, but we're not looking for that). Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100930/ba41f298/attachment.bin From gert at space.net Thu Sep 30 15:52:22 2010 From: gert at space.net (Gert Doering) Date: Thu, 30 Sep 2010 15:52:22 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA3A060.3080906@gmail.com> References: <20100927083013.428c58be@opy.nosense.org> <4C9FD315.6030301@timmins.net> <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100929074125.GI27830@serpens.de> <4CA3A060.3080906@gmail.com> Message-ID: <20100930135222.GD32268@Space.Net> Hi, On Thu, Sep 30, 2010 at 09:24:00AM +1300, Brian E Carpenter wrote: > I think the message below captures the problem with the multi-PA > model perfectly. When we started out in this direction almost > 15 years ago, exit router selection didn't seem like a big deal, > but now it does. It's "exit router selection", "source address selection" and "finding the optimum combination of source and destination address" which gives just too many possible "broken" combinations - so yes, it's a big deal now... :-( Gert Doering -- IPv6 evangelist -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tony.li at tony.li Thu Sep 30 17:45:33 2010 From: tony.li at tony.li (Tony Li) Date: Thu, 30 Sep 2010 08:45:33 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100930135002.GC32268@Space.Net> References: <4CA10B94.5070601@dougbarton.us> <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> Message-ID: <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> >>>>> Have the practical problems "how do I find the combination of source + >>>>> destination IP out of a set of N possible sources and M destination >>>>> addresses that works 'best' for me" (with locally varying metrics for >>>>> what is 'better' - latency, throughput, price, firewall policies, >>>>> upstream RPF) been solved by now? >>>> >>>> This is an orthogonal problem. PI doesn't solve it either. >>> >>> With PI (on both ends), there is only one combination of source and >>> destination IP address. Which makes this quite easy - try this >>> combination, and if it works, it's the best possible option. Sounds >>> "solved" to me. >> >> No, you only tried one path. There's no way to say that this is 'best'. > > If there is a single path, it's by definition the "best". (It's also > the worst, for sure, but we're not looking for that). If that's an acceptable solution, then pick any arbitrary path from the N*M possible address pairs and use that. Same result. Tony From gert at space.net Thu Sep 30 18:02:04 2010 From: gert at space.net (Gert Doering) Date: Thu, 30 Sep 2010 18:02:04 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> Message-ID: <20100930160204.GF32268@Space.Net> Hi, On Thu, Sep 30, 2010 at 08:45:33AM -0700, Tony Li wrote: > If that's an acceptable solution, then pick any arbitrary path from the N*M possible address pairs and use that. Same result. No, it isn't. In the "single source, single destination" address, I have network elements and network admins that feel compelled to make sure that this single combination is the one that works. In the N*M problem, the problem is shifted to the end systems, and it's to be expected that there is a difference in quality between the possible combinations. So I have a "find the best combination out of N*M" problem here, while in the first case I only have a single combination, and there is no need to select anything in the end host. For me, this looks like quite a different thing. Gert -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100930/1d925ab6/attachment.bin From tony.li at tony.li Thu Sep 30 18:37:23 2010 From: tony.li at tony.li (Tony Li) Date: Thu, 30 Sep 2010 09:37:23 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100930160204.GF32268@Space.Net> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> Message-ID: >> If that's an acceptable solution, then pick any arbitrary path from the N*M possible address pairs and use that. Same result. > > No, it isn't. In the "single source, single destination" address, I have > network elements and network admins that feel compelled to make sure that > this single combination is the one that works. > > In the N*M problem, the problem is shifted to the end systems, and it's > to be expected that there is a difference in quality between the possible > combinations. So I have a "find the best combination out of N*M" problem > here, while in the first case I only have a single combination, and there > is no need to select anything in the end host. > > For me, this looks like quite a different thing. So if you have N entries then your network admins won't bother to make them work? Seems to me like you need new network admins. Tony From chbm at chbm.net Thu Sep 30 19:24:42 2010 From: chbm at chbm.net (Carlos Morgado) Date: Thu, 30 Sep 2010 18:24:42 +0100 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100930160204.GF32268@Space.Net> References: <4CA114C0.2010609@dougbarton.us> <4CA15534.7000509@gmail.com> <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> Message-ID: On 2010/09/30, at 17:02, Gert Doering wrote: > Hi, > > On Thu, Sep 30, 2010 at 08:45:33AM -0700, Tony Li wrote: >> If that's an acceptable solution, then pick any arbitrary path from the N*M possible address pairs and use that. Same result. > > No, it isn't. In the "single source, single destination" address, I have > network elements and network admins that feel compelled to make sure that > this single combination is the one that works. > > In the N*M problem, the problem is shifted to the end systems, and it's > to be expected that there is a difference in quality between the possible > combinations. So I have a "find the best combination out of N*M" problem > here, while in the first case I only have a single combination, and there > is no need to select anything in the end host. > > For me, this looks like quite a different thing. > Exactly the point I was trying to get across. Shifting routing decisions to hosts is utterly bad. Might as well make ospf/isis a requirement for v6 hosts. > Gert > -- > did you enable IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Thu Sep 30 22:51:20 2010 From: gert at space.net (Gert Doering) Date: Thu, 30 Sep 2010 22:51:20 +0200 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: References: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> Message-ID: <20100930205120.GI32268@Space.Net> Hi, On Thu, Sep 30, 2010 at 09:37:23AM -0700, Tony Li wrote: > So if you have N entries then your network admins won't bother to make them work? > > Seems to me like you need new network admins. What exactly can the network admin do here? Let me try to illustrate this with a specific example. No complex policies for now, just focusing on "shortest path to destination". There's a source prefix S1 that is routed via ISP 1, and a source prefix S2 that is routed via ISP 2 (both prefixes coming from the respective ISP's PA space, so BCP 38 filters will require that source address selection automatically selects egress ISP). Destination prefix D1 is connected to peer of ISP 1, while destination prefix D2 is connected to something 20 hops behind ISP 2 (assuming that "20 hops" means "more latency, less bandwidth", for the simplicity of the model). +--- S1 === ISP 1 === ISP X ======== D1 ---+ source (*) destination +--- S2 === ISP 2 --- ISP A, B, C -- D2 ---+ How exactly is the end host supposed to know that "S1->D1" is good, while "S2->D2" is bad and "S1->D2" is very bad? (Assume that "use the longest sequence of common bits in the addresses" won't help, which is the normal case when crossing RIR regions). If I have a single S and D prefix, the end host does not *need* to know, and the network *will know* that the path via ISP 1 to its peer to D is shorter than via ISP 2. I hope I have succeeded this time in explaining where "we the operators" see a gap in the N*M model - and that has nothing whatsoever to do with "network admins not being up to the job". Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100930/66dd5dd5/attachment.bin From tony.li at tony.li Thu Sep 30 23:13:21 2010 From: tony.li at tony.li (Tony Li) Date: Thu, 30 Sep 2010 14:13:21 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <20100930205120.GI32268@Space.Net> References: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> <20100930205120.GI32268@Space.Net> Message-ID: <2E816F01-0D09-4643-B5E1-E576ACF9119F@tony.li> Hi Gert, > Let me try to illustrate this with a specific example. No complex policies > for now, just focusing on "shortest path to destination". Nope, sorry, you don't get to change the game in the middle. You asked for a path equivalent or better than what a single prefix would give you. Specifically, routing today does NOT give you the shortest path to the destination. > There's a source prefix S1 that is routed via ISP 1, and a source prefix > S2 that is routed via ISP 2 (both prefixes coming from the respective > ISP's PA space, so BCP 38 filters will require that source address > selection automatically selects egress ISP). No, BCP 38 requires that the source address MATCH the egress. If the egress prefix is applied at the ASBR, that also suffices. > Destination prefix D1 is connected to peer of ISP 1, while destination > prefix D2 is connected to something 20 hops behind ISP 2 (assuming that > "20 hops" means "more latency, less bandwidth", for the simplicity of > the model). > > +--- S1 === ISP 1 === ISP X ======== D1 ---+ > source (*) destination > +--- S2 === ISP 2 --- ISP A, B, C -- D2 ---+ > > How exactly is the end host supposed to know that "S1->D1" is good, while > "S2->D2" is bad and "S1->D2" is very bad? (Assume that "use the longest > sequence of common bits in the addresses" won't help, which is the normal > case when crossing RIR regions). It doesn't know and shouldn't care. > If I have a single S and D prefix, the end host does not *need* to know, > and the network *will know* that the path via ISP 1 to its peer to D is > shorter than via ISP 2. No, it will not. It will simply use the path selected by BGP. That could easily be S1 to D2. > I hope I have succeeded this time in explaining where "we the operators" > see a gap in the N*M model - and that has nothing whatsoever to do with > "network admins not being up to the job". No, sorry. What you've shown is that the N*M model doesn't give you a panacea. It will not read your mind and give you ultimate optimality. What the N*M model _can_ do, specifically with ILNP, is to present all prefixes to the end host, in the preference order that the destination selects. Assuming that the destination is only advertising working prefixes, then this gives you equivalent semantics to what you have today. Further, if the hosts also support MPTCP, you can make use of all N*M paths in parallel. This is very nice as it not only discovers the path with the optimal throughput, but it also allows you to use ALL of the paths in parallel. Can't do that with the PI model. Bottom line: optimal path selection is neither a host nor routing function. It's a transport function. Regards, Tony From sethm at rollernet.us Thu Sep 30 23:34:07 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 30 Sep 2010 14:34:07 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <2E816F01-0D09-4643-B5E1-E576ACF9119F@tony.li> References: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> <20100930205120.GI32268@Space.Net> <2E816F01-0D09-4643-B5E1-E576ACF9119F@tony.li> Message-ID: <4CA5024F.8020903@rollernet.us> On 9/30/2010 14:13, Tony Li wrote: > > It doesn't know and shouldn't care. > If the host doesn't know or care, then the host has no business making routing decisions. ~Seth From tony.li at tony.li Thu Sep 30 23:39:34 2010 From: tony.li at tony.li (Tony Li) Date: Thu, 30 Sep 2010 14:39:34 -0700 Subject: I-D Action:draft-azinger-scalable-addressing-00.txt In-Reply-To: <4CA5024F.8020903@rollernet.us> References: <17838240D9A5544AAA5FF95F8D52031608F044BD@ad-exh01.adhost.lan> <4CA25491.1040803@gmail.com> <20100928205748.GN32268@Space.Net> <20100929082426.GP32268@Space.Net> <20100930135002.GC32268@Space.Net> <6A0AD460-F09C-41D2-BD81-742C362638CE@tony.li> <20100930160204.GF32268@Space.Net> <20100930205120.GI32268@Space.Net> <2E816F01-0D09-4643-B5E1-E576ACF9119F@tony.li> <4CA5024F.8020903@rollernet.us> Message-ID: >> It doesn't know and shouldn't care. >> > > If the host doesn't know or care, then the host has no business making > routing decisions. Which is exactly why it doesn't. Tony