Fw: new message
Hey! New message, please read <http://shoppingsignal.com/again.php?0fc3> Iljitsch van Beijnum
Fw: new message
Hey! New message, please read <http://shoroqpress.com/running.php?b2> Iljitsch van Beijnum
Re: valley free routing?
On 6 mrt. 2014, at 02:18, Joel Maslak jmas...@antelope.net wrote: I have never heard the term valley free. Where does it come from? This paper, which is a must-read for anyone interested in BGP: Stable internet routing without global coordination By Lixin Gao and Jennifer Rexford http://dl.acm.org/citation.cfm?id=504612
32-bit ASes at routeviews
Looking for 32-bit AS numbers, I get some strange results from routeviews: route-viewssh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.1130 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.1130 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. Maybe a bug in the IOS they're running? route-viewssh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) Or is something else going on?
Re: Shim6, was: Re: filtering /48 is going to be necessary
On 12 Mar 2012, at 16:21 , Leigh Porter wrote: Grass-roots, bottom-up policy process + Need for multihoming + Got tired of waiting = IPv6 PI A perfect summation. Except that it didn't happen in that order. When ARIN approved PI the shim6 effort was well underway, but it was too early to be able to know to what degree it would solve the multihoming problem. Earlier, when multi6 was stuck or later, when shim6, at least as a specification, but preferably as multiple implementations, could have been evaluated would both have been reasonable times to decide to go for PI instead. Of course as has been the case over and over the argument if you give us feature X we'll implement IPv6 has never borne out. Also given that people understand what PI space is and how it works and indeed it does pretty much just work for the end users of the space. The trouble is that it doesn't scale. Which is fine right now at the current IPv6 routing table size, but who knows what the next decades bring. We've been living with IPv4 for 30 years now, and IPv6 doesn't have a built-in 32-bit expiry date so it's almost certainly going to be around for much longer.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On 12 Mar 2012, at 21:15 , William Herrin wrote: Not at all. You just build a second tier to the routing system. It's so strange how people think a locator/identifier split will solve the scalability problem. We already have two tiers: DNS names and IP addresses. So that didn't solve anything. I don't see any reason a second second tier would.
Re: filtering /48 is going to be necessary
On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: The way we are headed right now, it is likely that the IPv6 address space being issued today will look like the swamp in a few short years, and we will regret repeating this obvious mistake. We had this discussion on the list exactly a year ago. At that time, the average IPv6 origin ASN was announcing 1.43 routes. That figure today is 1.57 routes per origin ASN. The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table. But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this: 1. Attackers could flood BGP with bogus prefixes to make tables overflow 2. Legitimate prefixes may be deaggregated so tables overflow It won't be quick or easy, but the RPKI stuff should solve 1. So that leaves the issue of deaggregating legitimate prefixes. There are around 100k prefixes given out by the RIRs and nearly 400k in the routing tables. A quick look at the IPv4 BGP table shows that unless I missed the day in school when they covered reasons to advertise 64 /22s instead of a /16 a good percentage of those deaggregates happen without any legitimate reason. Although the RIRs don't make this as easy as they could, it IS possible to determine the maximum prefix length for any given block of RIR space, and then simply filter on that prefix length. That takes care of the /48s and /32 deaggregating, but unfortunately not the /44s out of space used for /48s or the /20s out of space used for /32s. So the RIRs should up their game here, then we can really hold LIR's feet to the fire and stop them from deaggregating. That does of course leave people who do have a good reason to deaggreagate in the cold. But that's also easy to solve: if you run two separate networks, you need two prefixes and two AS numbers. So the RIRs should develop policies that allow for this if it's reasonable. If that means that an organization can't have both a bunch of independently announced prefixes AND have all those prefixes be part of one aggregate for easy firewall configuration, that's too bad. The RIRs should pick up on this, because there WILL be a moment an ISP deaggregates a /32 into 65000 /48s with the result that half the IPv6 internet goes down.
Shim6, was: Re: filtering /48 is going to be necessary
On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion basement multihomers with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 29 Dec 2011, at 0:16 , Doug Barton wrote: On 12/28/2011 03:13, Iljitsch van Beijnum wrote: However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is a different issue. And although this is / has been common for RAs/stateless autoconfig beceause some idiot at Microsoft made this happen more or less automatically in some configurations, there really is no difference between DHCPv6 and stateless autoconfig here. What I'm talking about is the issue where a legitimate DHCP server gives out an incorrect default gateway addresses because of a configuration mistake. Because a DHCP server that isn't also that same router has no way of knowing that address this can't be automatically done right so mistakes happen. Especially at this point with IPv6 where most people don't notice it when it doesn't work most of the time. I'm aware that SEND is trying to solve this problem, but it's not yet deployed. SEND is similar to IPsec in this regard, it's not going to be deployed widely because it's too complex to do so. I think that people already know of and have solutions for the security issues that exist for DHCP today. Yes, for IPv4. But this is a filtering issue. If you can filter rogue DHCPv6 servers you can also filter rogue RAs. 10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. I agree with you that DHCPv6 doesn't deserve any prizes, not for design, implementation nor time to market. But I disagree that importing all IPv4 cruft into IPv6 for the sake of speeding up deployment that wasn't going to happen anyway would have been a good idea then, let alone now. The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included everything relevant that DHCPv4 can do in that update, we'd be in a pretty good condition in a year or so. You are living in a fantasy world if you think that.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 29 Dec 2011, at 13:46 , Masataka Ohta wrote: we must assume MTU of 1280B. But, as IPv6 extension headers can be as lengthy as 1000B or 2000B, no applications are guaranteed to work over IPv6. As IP is an unreliable datagram service, there are no guarantees, period. The presence of firewalls also removes any guarantees left in place after the previous point.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Just to clear up a few misconceptions: begin explanation current situation Router advertisements are exactly what the name suggests, routers advertising their presence. The first function of router advertisements is to tell hosts where the routers are, so the hosts can install a default route. No RA means hosts won't send the router their packets. Of course routers that only talk to other routers don't need to send out RAs although nothing bad happens if they do so vendors may opt to send them out by default. All other functionality provided by RAs is optional. The first of those additional options the prefix option. This allows hosts to know which addresses are reachable on the local subnet so packets to those addresses don't have to go through a router but can be sent directly. Multiple prefix options may be present in an RA. Then there is the autonomous autoconfiguration (A) flag, which tells hosts that they should configure an address for themselves using the prefix in a prefix option. So only when at least one prefix option with the A flag set is present in an RA and the prefix length for that prefix is 64, stateless address autoconfiguration will be performed. Additional RA options can provide information such as a reduced MTU to be used on a subnet or a list of DNS server addresses. Unlike everything else mentioned so far, the latter is not very widely implemented. For DHCPv6, there are three variants: one that provides prefixes to routers, one that provides individual addresses (presumably) to hosts, and one that provides additional information such as DNS addresses. The first two require a stateful version of the DHCPv6 exchange to be performed, while the additional information can also be acquired using a lighter weight stateless exchange. Unless I'm very much mistaken, the DHCPv6 server can only perform the function the client has asked for. DHCPv6 is different from IPv4 DHCP in many ways, for instance the stateful/stateless distinction and the use of DUIDs rather than client identifiers. More importantly, DHCPv6 doesn't provide a prefix length or default gateway. This means that RAs are always necessary to provide this information (although some implementations may function without having explicitly learned the prefix length they should use). The trouble with having two mechanisms to do the same thing (stateless autoconfig and DHCPv6 address assignment) is how to decide which one to use. For this we have the M and O bits in RA. If M is set stateful DHCPv6 should be initiated for requesting an address and other information. If only the O bit is set stateless DHCPv6 should be initiated by hosts to request only other information. If both M and O are zero then no DHCPv6 should be initiated. Windows Vista and up and MacOS 10.7 support DHCPv6 address assignment. This means that as of six months ago, it became possible to assume DHCPv6 support in current versions of mainstream OSes. Before that, some of them lacked this capability so effectively, turning off stateless autoconfig and solely using DHCPv6 was impossible. issues and way forward Stateless autoconfig is a very nice system in un- or lightly managed environments, where it provides stable addresses to hosts without the need to have a central server keep track of those addresses using non-volatile storage. Unfortunately the DNS info isn't widely supported so at this point, at least stateless DHCPv6 is also needed to provide this information. In more tightly managed environments, stateless autoconfig has the downside that the hosts choose their addresses autonomously, so the information about which host has which address at which point in time isn't easily available to be logged. We have now reached the point were it's possible to turn off stateless autoconfig and use DHCPv6 address assignment instead to accommodate such logging. Of course none of this is bullet proof. Like with IPv4, there is some assumption that people on a shared subnet play nice. This may be an incorrect assumption. In that case, significant filtering and additional logging of L2 parameters may be necessary. Such features are not as widely available for IPv6 as for IPv4. There are some situations where it can be useful to give different hosts different information using DHCPv6, including information that is now provided using RAs, which are of course the same from the viewpoint of every host on a given subnet. In addition to that, some people just don't like RAs and want to run their network without them. These two groups want default gateway information to be added to DHCPv6 to accommodate those needs/wants. However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the
Re: subnet prefix length 64 breaks IPv6?
On 24 Dec 2011, at 6:32 , Glen Kent wrote: I am trying to understand why standards say that using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. [reference RFC 5375] For stateless autoconfig the issue is that it uses 64-bit interface identifiers (~ MAC addresses) that are supposed to be globally unique. You can't shave off bits and remain globally unique. With SEND a cryptographic hash that can be used to determine address ownership is stored in the interface identifier. Here shaving off addresses reduces security. Also somehow the rule that all normal address space must use 64-bit interface identifiers found its way into the specs for no reason that I have ever been able to uncover. On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on /64 is somewhat less efficient.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On 28 Dec 2011, at 13:26 , Ray Soucy wrote: Granted that the notion of default router of IPv4 is no better than that of IPv6. Please present a reasonable alternative. Obviously reducing down the entire DFZ to a single default route is a bad case of premature optimization, which we all know is how so many engineering efforts get into trouble. The right way to handle this would be for hosts to engage in both inter and intra domain routing with local routers, and then do their own aggregation if and when desired. Iljitsch PS. :-)
Re: mtu question. more should be better, right?
On 7 Nov 2011, at 17:45 , Deric Kwok wrote: When I setup the server mtu as 9100. why I have to configure the switch mtu 9300 to make it working? What this extra 200 bytes is for what purpose? ls it standard? To avoid problems you really want to set the MTU of all your IP devices on the same subnet to the same value. On the switches the MTU needs to be big enough to accommodate the MTU that the hosts and the routers use, but there's no harm in it being larger. (Although you may be using up memory for nothing.) One complication is that not everyone has the same understanding of packet sizes. For IP the MTU is the size of the largest IP packet that can be carried, but layer 2 people sometimes add 14 or 18 bytes to that and layer 1 people maybe even 38. (14 = ethernet header, 18 = ethernet header + frame check sequence, 38 = header, FCS, preamble, start of frame delimiter and interframe gap.) What is disadvantage of setting our all internal networks (host / equipment) mtu more than 1500? Mostly that you'll be hitting path MTU discovery more often. However, this will not cause many issues unlike the case where you use an MTU _smaller_ than 1500. Don't set a larger MTU on slow networks (certainly not on 10 Mbps) because long packets sit in queues for a long time at low speeds, getting in the way of interactive traffic such as VoIP. Above 11k the ethernet frame check sequence catches fewer errors.
Re: The stupidity of trying to fix DHCPv6
On 15 jun 2011, at 16:52, Tony Finch wrote: Ethernet is not designed for huge LANs. If you want that you need to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ Hm: Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support. Ethernet: Distributed Packet Switching for Local Computer Networks Robert M. Metcalfe and David R. Boggs Communications of the ACM Volume 19 Issue 7, July 1976
Re: The stupidity of trying to fix DHCPv6
On 15 jun 2011, at 18:39, Leo Bicknell wrote: Maybe I'm missing something, but the last update on this was RFC 5006 I think, which is marked as experimental, and I thought the IETF still had a working group discussing it. You missed the upgrade to proposed standard: http://tools.ietf.org/html/rfc6106 That is, I didn't think it was a finalized standard yet. The IETF rarely gets around to bringing something from proposed standard to standard. For instance, HTTP and BGP aren't standards either.
Re: The stupidity of trying to fix DHCPv6
On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote: On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP. That is really pathetic. I thought that any Ethernet chip built the previous decade could filter 64 or so multicast addresses in hardware. Only when you're subscribed to more multicast groups than what your Ethernet chip can filter in hardware does the software for an IPv4-only system have to encounter IPv6 multicasts, or an IPv6 system random neighbor solicitations, which are load balanced over a wide range of multicast addresses just for this reason. Also strange that there would be this much neighbor discovery traffic, probably the same reason AMS-IX used to have 15 kbps of ARP traffic: stale BGP peerings to addresses that no longer exist.
Re: The stupidity of trying to fix DHCPv6
On 15 jun 2011, at 0:05, Owen DeLong wrote: Yes, the right solution would be to at least separate the VLANs and clean up this mess. However, due to software packages that need to talk to each other over common local broadcast across that boundary, this isn't possible in this particular organization (don't get me started on the bad software, but, that's what there is.) Strange that you don't apply the logic of the existing software is what there is to the code deep inside hundreds of millions of hosts, but rather to obscure stuff that presumably hardly anyone uses. If changing this software is so hard, what these people need is some filtering switches so the application multicasts get forwarded but the IP provisioning multicasts don't. No standards action required. BTW, does this broken software run over IPv6, anyway?
Re: The stupidity of trying to fix DHCPv6
On 15 jun 2011, at 7:33, Owen DeLong wrote: Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes because experience has shown that they are more willing to do so than vertical software vendors. As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world problems. BTW, as long as you're making harmless changes: not putting a hard line end just _after_ 80 characters would make your messages easier to read. As established before, all of this is not harmless and OS vendors (not sure what you're talking about with BIOS) aren't all that willing to make changes, at least not on short timescales. It seems to me that the easiest solution to work around broken IPv4-only software isn't messing with the IPv6 protocol stack, but to create an IPv4 overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite going through IPv6 routers. Actually this would also be quite useful in hosting environments where it would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are entangled.
Re: bgp feed to customer
On 13 jun 2011, at 19:25, Richard Zheng wrote: The issue is redistribution from EBGP to OSPF works half way. OSPF database has the external routes, but forwarding address is set to Router A. So the routing loop occurs between A and B. If the link to the customer is of a type that detects up/down quickly, the easiest way to get around this is to simply point a default to the customer interface at router B. Another option is running a separate OSPF instance between B and the customer. Or just ignore the issue that if/when the link to the customer goes down, router B doesn't notice and keeps forwarding packets into the void. You would want to make sure that the customer's prefix isn't propagated in OSPF, though, so the issue is limited to this one router, not the whole AS.
Re: The stupidity of trying to fix DHCPv6
On 11 jun 2011, at 16:39, David Conrad wrote: There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. As should be apparent by now, the vast majority of people don't want to move to IPv6. They simply want access to the Internet. ISPs are looking for the easiest/cheapest way to do this, which generally means the way they've done it in the past. Forcing them to change simply slows things down. Ok, removed my snarky comments on trying to be fast this late in the game. The problem is changing DHCPv6 so people want to deploy it more means waiting a couple of years for the changes to start appearing and then many more years for the non-changed systems to disappear. How doing this makes anything faster is a mystery to me. People just have to get over the fact that IPv6 is different from IPv4 in some regards and it's too late now to change that, because we're already way behind deploying IPv6 before the IPv4 addresses run out.
Re: The stupidity of trying to fix DHCPv6
On 11 jun 2011, at 17:05, Owen DeLong wrote: Your doctor doesn't just give you the medicine you ask for either. You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment. It's true that the patient also knows some stuff here. There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table. Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet. You know what they say: a doctor who treats himself has a fool for a patient. Yes, I'm well familiar with your level of arrogance. Yes, I know I stick out like a sore thumb in these humble parts. BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE? Judge for yourself: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt Let me wrap up this discussion with the following: IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up. One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible.
Re: The stupidity of trying to fix DHCPv6
On 12 jun 2011, at 12:35, Daniel Roesen wrote: Could you point to any RFC which implies or explicitly states that DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0? Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. And networks without RAs are very common. We call those networks IPv4-only networks. And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets.
Re: The stupidity of trying to fix DHCPv6
On 12 jun 2011, at 15:45, Leo Bicknell wrote: Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP. The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing.
Re: ip 6 questions
On 12 jun 2011, at 20:46, Deric Kwok wrote: 1/ Can we use it in our current AS which is using ipv4? Yes. 2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6? They're going to do that anyway once they run out, but it's not like you have v6 so you don't need more v4. 3/ Any advices to do ipv6 in hosting business Read a good book. :-) There's also tons of informatin out there on the web and in meetings. For hosting you really want to think about how to set up your VLANs. Each customer in their own VLAN is ideal but not always possible, mostly depending on how IPv4 is set up.
Re: The stupidity of trying to fix DHCPv6
On 11 jun 2011, at 4:03, Owen DeLong wrote: You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. Those networks have working configurations in DHCPv4 and no ability to move to IPv6 until this is solved. Yeah, and they needed provider independent space to be able to move to IPv6, too. Didn't happen to a measurable degree either. There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. Just because someone wants it doesn't make something a good idea. Especially because time and time again people take some underlying need, translate that in some technical need that is an extremely bad way to address that underlying need. So just giving people what they ask for invariably leads to sub-par results. Your doctor doesn't just give you the medicine you ask for either. Yes, I know this carries an implicit accusation of stupidity. I can live with that, and I'm not impressed if people are offended. (You get used to that surprisingly quickly.) I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior. Risks are in the eye of the beholder. I'm sure the financial sector didn't see any problems coming their way in 2007 either. I'm sure I sometimes see problems that never materialize. Still better safe than sorry. Especially because this is all nonsense in the margin that we can all very easily live without. What are we talking about here? One RA message every 200 seconds? Is that so bad? People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. There were a lot of people who tried to show up at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work. So what has changed now? Is it helpful to take that advice for 10 years and THEN revisit the issue? BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of administrators. Assuming facts not in evidence. There is a small group of people that is never happy. Give them more, they remain unhappy. The adagium don't feed the trolls applies to them. It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. How does this make your life worse? If it's not your network, why do you care? Because it allows one more configuration that works for some stuff and not other stuff. I get around enough that I'll encounter such a configuration at some point. As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that people can use. No, it add functionality that allows administrators to remove functionality but that only works if there are no systems that don't have the first functionality and hence can do without the second functionality. It'll take years for operating systems to catch up, and all of that just to fix something that isn't broken in the first place. (Remember, not talking about rogue RAs!) Because in some cases, the HOST administrator is not the NETWORK administrator and cannot necessarily control how the administrator of a given router does things. In some cases, this means that the HOST administrator wants his hosts to act in a manner that is not consistent with what the administrator of certain network devices wants to tell other hosts on the same link to do. Again, why NOW? We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead. And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere quickly. A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack
The stupidity of trying to fix DHCPv6
On 9 jun 2011, at 19:37, Nick Hilliard wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? along with prefix delegation Also works fine. - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003. So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6?
IPv6 routing protocols
On 9 jun 2011, at 19:41, Nick Hilliard wrote: Iljitsch noted: IPv6 routing protocols also pretty much only use link locals. This is not true in the general case. So which routing protocols communicate using global addresses then? As far as I know only BGP but BGP runs over TCP so it's different from all other routing protocols. And it still carries link local next hop addresses.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 12:10, sth...@nethelp.no wrote: So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition.
Re: IPv6 routing protocols
On 10 jun 2011, at 12:20, Nick Hilliard wrote: [nothing to support his earlier claim] And it still carries link local next hop addresses. it's a bit more subtle than that - it depends on how the underlying router operating system handles next-hop resolution and how you configure your BGP. It doesn't depend. RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute.
Re: IPv6 routing protocols
On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote: RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute. Sorry, this is stupid. I should have read beyond LOCAL. So it depends a little, but I still don't see any implementation leeway in RFC 2545: 3. Constructing the Next Hop field A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16).
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 12:40, Tim Chown wrote: But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. There's deployment of code and deployment of configuration. The former is in good shape now, so better not tinker with it unnecessarily. It's also not very useful to count the 80% of the internet that consists of home users behind the cheapest home gateway running with the default settings the same way as we count the other 20% who actually have an opinion on the matter. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. Well, but if you turn off RAs while there are still systems that can't understand a new DHCPv6 router address option, then those systems have no idea where the routers are so they don't work. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. The trouble is that having the correct router NOT send RAs buys you very little: in theory you can now skip coordination between different departments if the DHCPv6 and router configs are handled by different people. In practice, you need to coordinate regardless because the routers need to know where to send the packets so they need to have the prefixes that the DHCPv6 servers assign from configured on their interfaces. What you really want is for the hosts to ignore RAs sent by incorrect routers. This means turning off autoconfig on the hosts, which seems, at the very least, an uphill struggle unless we're talking about places with hosts bolted to the floor so the configuration can be tied to a specific network. And in that case you can do tons of other stuff, such as SEND or simply statically configuring everything. Lest anyone accuse me of raining on their parade: I think very workable compromise would be to have a router preference option in DHCPv6. This way, routers still advertise themselves, but if there are multiple routers, the DHCPv6 info is the tie breaker so rogue RAs are avoided when this option is understood. But doing this doesn't impose difficulties on hosts that don't implement the new option.
Re: IPv6 routing protocols
On 10 jun 2011, at 14:26, Nick Hilliard wrote: [...] Of course none of this supports your original claim: IPv6 routing protocols also pretty much only use link locals. This is not true in the general case.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 15:47, Leo Bicknell wrote: I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Are there perhaps easier and more timely ways to solve it? (And it's insane that Windows still exhibits this completely broken behavior.)
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:12, Tim Chown wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:28, Leo Bicknell wrote: Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. I don't have to, as you restate pretty much all of it here... So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:47, Leo Bicknell wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. Don't you realize that this doesn't solve anything? The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses 2. Old and new hosts may use different gateways on the same network So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of legacy IPv6 hosts that need RAs to function and won't go away anytime soon.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 17:26, Leo Bicknell wrote: 1. No longer the fait sharing that comes from RA-learned gateway addresses I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose. It's not about redundancy, it's about misconfiguration. You can't misconfigure an RA to provide the wrong gateway address because the gateway address is the source address of the packet. My guess is that most networks that use DHCPv6 will disable RA's completely on the routers. Haven't you been paying attention? One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot. I'm going to assume operators aren't going to do such stupid things. Not sure what universe you live in. In mine, if you give people a way to misconfigure, a good number of them will do so. And a small but vocal group will defend their misconfiguration and claim that this is really the best way to run their network, all the while complaining to their vendors and the IETF about the problems that this creates and that those need to be solved.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 18:06, Leo Bicknell wrote: However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected. If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better. If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. On 10 jun 2011, at 19:32, Owen DeLong wrote: Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. It's good to want things. Doesn't mean you'll get it. One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The happy eyeballs stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs. And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds! There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. It can also be done using my suggested DHCP validates RA gateway address mechanism. Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. Well, someone certainly intermingled the discussions, and it wasn't me. The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time. In some situations, this fate (it's fate, not fait, btw) Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right. sharing is not desired. Why not? documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored. A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. And like I said before, we have more pressing things to do than tinker some more with DHCPv6.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 23:30, Rhys Rhaven wrote: And here I thought with IPv6, we would have learned from our mistakes, fixed those problems. We've had 15 years to think about it. I was looking forward to a future where ICMPv6 might even be used. What are you talking about?? ICMPv6 does what IPv4 ICMP does as well as ARP and then some.
Re: World IPv6 Only Day.
On 9 jun 2011, at 6:36, Karl Auer wrote: Well, a modern switch should work fine, even if not directly IPv6 aware, but it won't understand multicast and will generally flood multicast frames to all interfaces. So definitely stipulate IPv6 capability, even for switches Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
Re: Cogent IPv6
On 9 jun 2011, at 10:32, Owen DeLong wrote: You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. The trouble is that DHCPv6 can't tell you the prefix length for your address, so either set up the routers to advertise this prefix (but without the autonomous autoconfiguration flag set) or prepare for surprising results. I say: life is too short to fiddle with this kind of stuff, just use /64, at least for everything that isn't a point-to-point link or loopback address.
Re: Cogent IPv6
On 9 jun 2011, at 14:19, sth...@nethelp.no wrote: It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine.
Re: World IPv6 Only Day.
On 9 jun 2011, at 19:34, Ray Soucy wrote: But you're correct that without MLD snooping IPv6 ND traffic is on par with IPv4 broadcast traffic and not a major problem. It does mean, however, that a large IPv6 multicast stream, like video or system imaging, would be about as bad as doing so on IPv4 without IGMP snooping. Of course the ethernet hardware in the host will filter multicast packets the host isn't listening for, so it just wastes some bandwidth on ports where the traffic isn't needed. This is unlike ARP, each ARP packet wakes up the CPU.
Re: Microsoft's participation in World IPv6 day
On 8 jun 2011, at 7:42, Christopher Palmer wrote: I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification. You have to remember that the content guys need few addresses and once they have them they rarely need more, and IPv6 or not is pretty much a binary thing: yes for everyone, no for everyone. It's the opposite for consumer ISPs: they need tons of addresses on an ongoing basis but they can (for instance) give IPv6 to new users while not changing anything for existing users. So once some hurdles such as the limited availability of IPv6-capable CPEs and a plan on how to provision IPv6 are taken the ISPs have a lot of incentive to roll out IPv6 while the content guys can conceivably stay on IPv4 for a long time. The fact that IPv6 client to IPv4 server is an easy problem but the other way around a very hard one also points in this direction. BTW, how are you guys dealing with path MTU discovery for IPv6? I've seen a few sites that have problems with this, such as www.nist.gov, but you guys seem ok.
Re: www.nist.gov over v6 trouble Was: Microsoft's participation in World IPv6 day
On 8 jun 2011, at 8:15, Andrew Koch wrote: Speaking of www.nist.gov, I am getting the front page to load, but all links are returning a 404 Not Found when browsing via v6 Right. They seem to have solved their PMTUD issues, though.
IPv6 day fun is beginning!
www.juniper.net is on IPv6 www.facebook.com has but doesn't load for me over IPv6, it does for others though www.level3.com works fine over v4 but shows a 404 over IPv6 www.simobil.si is temporarily unavailable over IPv6 but works fine over IPv4
Re: IPv6 day fun is beginning!
On 8 jun 2011, at 2:02, Pete Carah wrote: www.facebook.com (but not facebook.com) just turned on here too (after google). another hex-speak spelling... I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to work, but it redirects to m.facebook.com which doesn't have IPv6. This seems to be a trend, yahoo and cnn do the same thing. Annoying.
Re: IPv6 day fun is beginning!
On 8 jun 2011, at 2:31, TJ wrote: ... and Gmail, too ... imap.gmail.com only has IPv4, though.
Re: IPv6 Conventions
On 19 mei 2011, at 5:21, Owen DeLong wrote: 2) Are we tending to use different IPs for each service on a device? No, the same Internet Protocol. I believe he meant different IP addresses No, that can't be, he would have said IP addresses. and I highly recommend doing so. If you do so, then you can move services around and name things independent of the actual host that they happen to be on at the moment without having to renumber or rename. The DNS is already a layer of indirection so in most cases this makes things harder first (having to remember which address is on which host) so they may be easier later (not touching the DNS when services go to a new box). In my opinion, this isn't a good tradeoff most of the time. Only if you want/need addresses to be a particular way (like short for DNS servers) that's helpful. I was reluctant to do stateless autoconfig for servers at first but it's really rock solid, as long as you're reasonably sure no rogue router advertisements will show up on the subnet in question there's no reason to avoid it.
Re: IPv6 Conventions
On 18 mei 2011, at 16:44, Todd Snyder wrote: 1) Is there a general convention about addresses for DNS servers? NTP servers? dhcp servers? There are people who do stuff like blah::53 for DNS, or blah:193:77:81:20 for a machine that has IPv4 address 193.177.81.20. For the DNS, I always recommend using a separate /64 for each one, as that way you can move them to another location without having to renumber, and make the addresses short, so a ::1 address or something, because those are the IPv6 addresses that you end up typing a lot. For all the other stuff, just use stateless autoconfig or start from ::1 when configuring things manually although there is also a little value in putting some of the IPv4 address in there. Note that 2001:db8::10.0.0.1 is a valid IPv6 address. Unfortunately when you see it copied back to you it shows up as 2001:db8::a00:1 which is less helpful. 2) Are we tending to use different IPs for each service on a device? No, the same Internet Protocol. Finally, what tools do people find themselves using to manage IPv6 and addressing? Stateless autoconfig for hosts, EUI-64 addressing for routers, VLAN ID in the subnet bits. That makes life simple. Simple be good.
Re: Yahoo and IPv6
On 17 mei 2011, at 17:55, Matthew Kaufman wrote: firewall traversal Smells like job security: first install a firewall, then traverse it anyway.
Re: Yahoo and IPv6
On 16 mei 2011, at 9:31, Owen DeLong wrote: I believe that the BitTorrent clients are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just use the native IPv6 nodes. I don't see this as a problem and Im not sure why you do. Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.) It would be much better if you could go from IPv6 to IPv4 through a NAT64.
Re: Yahoo and IPv6
On 15 mei 2011, at 6:29, Matthew Kaufman wrote: And that would be the fault of NAT64, which for all of the applications I mentioned (and more) made the seriously wrong assumption that every IPv4 address is looked up in a DNS server. This brings to mind the story of the physicist (but it could easily have be an IETF protocol engineer) who was scrambling around under a lamp post at night. A passer by asked what he was doing: looking for my keys. Are you sure you lost them here? No, but under the light is the only place I have a chance at finding them. It's not that the people involved with NAT64 (full disclosure, I'm one of them) thought that every IPv4 address would have a working DNS name, but rather that using the DNS made it possible to have a transition mechanism that lets unmodified IPv6 hosts talk to unmodified IPv4 hosts. However, all is not lost: you can easily set up sessions through a NAT64 if the application (or the system, but that will take longer to materialize) learns the other 96 bits and stuffs them in front of the IPv4 bits. If the NAT64 uses the well known prefix the 96 bits are easy to learn, if it does not you'll need another mechanism, which are now being discussed. But an application could easily roll its own by looking up a known IPv6-only A record and then taking the 96 bits from the resulting record.
Re: Yahoo and IPv6
On 15 mei 2011, at 20:03, Jima wrote: BitTorrent tends to be an evolving protocol, with lots of clients competing for mindshare; I'm not certain that limitation will remain. Two years ago the Pirate Bay got on IPv6 in a way that was incompatible with existing clients that were IP version agnostic for lengthy reasons. (They decided you should have an IPv4 connection to the tracker (central server) to learn IPv4 peer addresses and an IPv6 connection to learn IPv6 peer addresses.) Then their legal troubles got serious and I'm guessing they find it hard enough to move their IPv4 address(es?) around so they're IPv4- only again. They also want to move away from having trackers at all, and instead use a peer-to-peer based system (DHT) to find peers. Until about a year ago I regulary saw 6to4 addresses showing up through the DHT but that has stopped. And rarely, if ever, would it be possible to connect to those addresses, anyway. Not sure what changed, maybe my software is too old, I'm on the wrong DHT or whatever. Interestingly, BitTorrent can easily be modified to use the IETF NAT traversal techniques (STUN/TURN/ICE) and these are also largely compatible with NAT64. (Because unlike exiting NAT, NAT64 came about through the IETF process rather than organically, it probably has the tightest specifications of any type of NAT.) So you could run BitTorrent behind a NAT64 and not even exhaust the NAT64's port numbers. But for that, the BitTorrent application developers need to do some work, which they probably won't be able to do successfully until they can test against a fully RFC-conforming NAT64 translator.
Re: Yahoo and IPv6
On 14 mei 2011, at 18:47, Paul Vixie wrote: folks who want to run V6 only and still be on the internet will need proxies for a long while. folks who want to run V6 only *today* and not have any proxies *today* are sort of on their own -- the industry will not cater to market non-forces. And clearly that situation can be kept that way for a long time by simply not serving them anything over IPv6. But is that wat we want? Currently IPv4 is pretty good but that's not going to last once 1.5 NATs on average between any two points grows to 3.8 of them, with 1.7 starved for address/port combinations*. At that point you can technically still be 100% connected using just IPv4, but it won't be much fun anymore. * numbers pulled out of the air by yours truly, but based on two consumers with home NAT today and with additional carrier NAT in the future. I've been on IPv6 for a long time. When I started with IPv6, the only applications (to use the term loosely) that understood v6 were ping6 and traceroute6. These days, I think the only thing I wouldn't be able to do over IPv6 is print. It used to be that IPv6 pingtimes were 2 - 3 times worse than IPv4 pingtimes. They're pretty much the same 80% of the time now. I used to have 8 IPv4 addresses, enough for most of my computers. I have one now, with mandatory NAT. When I move later this year I may very well only have a partial IPv4 address. The times are a-changing.
Re: IPv6 foot-dragging
On 13 mei 2011, at 2:39, Jimmy Hess wrote: if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48. Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place. The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless. And that all in case a /48 isn't big enough (which is ridiculously rare in and of itself) to save ONE entry in the global routing table. So by trying to conserve the table we make it impossible to protect our routing tables. It is a heck of a lot better for network stability that any multi-homed user get a /32 PI, No, that's completely ridiculous. It's like saying all flights should be flown with 747s just in case 10 football teams show up unexpectedly. That is, if a 747 could carry a million people (64k more than a small 16-seat plane). Yes, the IPv6 address space is big but by giving people who need more than 65000 subnets a /32 so they can have 40 subnets is unbelievably wasteful for no other reason than laziness.
Re: Interested in input on tunnels as an IPv6 transition technology
On 13 mei 2011, at 7:52, Karl Auer wrote: I'm working on a talk, and would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. Without tunnels we'd have no IPv6 today. Even today many people, especially home users, depend on them. But it would have been impossible to get IPv6 started by running it native-only. Tunnels can work very well and if they're direct they can be almost as good as native connectivity. However, in the past we saw Europeans get tunneled IPv6 connectivity from Japan. That kind of thing is very bad because it inflates RTTs and thus slows everything down. Enabling automatic tunneling by default is also a mistake because then you think you have IPv6 even if the automatic tunnel doesn't work because relays are unreachable or stuff is firewalled. A downside of tunneling is the reduced MTU, but hopefully the fact that tunnels are common makes people fix PMTUD problems rather than blindly send 1500-byte packets and let the chips fall where they may that way too many people do with IPv4. So... tunnels can be good or can be bad, but native is still better than a good tunnel.
Re: IPv6 foot-dragging
On 13 mei 2011, at 18:42, Matthew Petach wrote: The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless. If they announce a million /48s, they're actively hijacking space from 64,000 other people, and should be dealt with in an appropriate manner as a hijacker. :/ It would be mostly unused space. But that doesn't matter much, the point is that your prefix length filters can't stop this. If, on the other hand, the RIRs only give out /48s from one limited set of address space swaths and /44s from another, /32s from yet another and so on, then if there are 64k /48s that comes from say two /32s and three /33s for a total deaggregation risk of 224k prefixes. This is something your router may be able to handle. The *only* thing that will prevent that, in real-time are techniques like PGBGP or so-BGP. Not RIR policies. See above. All this BGP security stuff is still vaporware as of today. Hopefully that will change in the future but I'm not holding my breath for the benefits to kick in. (as a side note--in order to have your million /48s table explosion happen through *legitimate* holders of space deaggregating, it would require 64K individual choices to deaggregate in order to have that happen; we don't even have that many ASNs out there yet. I'm not losing sleep over that at this point.) If you boil it slowly enough the frog will sleep just fine. I participated in the IETF multi6/shim6 and IRTF RRG efforts for years but I have since come to the conclusion that routing table growth is not a real problem, because if it were people would be more willing to accept the downsides that come with the proposed solutions.
Re: IPv6 foot-dragging
On 12 mei 2011, at 12:06, Owen DeLong wrote: IPv6 peering is somewhat different from IPv4. How is it different?
Re: Yahoo and IPv6
On 11 mei 2011, at 2:39, Karl Auer wrote: On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote: For the record Apple's current iChat (the OS (10.6.7) is completely up to date) fails such a test. It will try IPv6 and not fallback to IPv4. End users shouldn't be seeing these sorts of errors. Hm, I've had a very hard time finding any IPv6-capable servers to let my iChat talk to... Is that possibly a failure of the underlying resolver library? Do other applications on the same platform behave correctly? Apple's Mail application used to do this, but after many years they fixed this, it will now fall back to IPv4 without trouble. This isn't a resolver issue, as the resolver can't know whether IPv6 connectivity does or doesn't work. The resolver simply gives applications that don't explicitly ask for a particular address type all of the addresses of all types for which the system currently has connectivity, I think as determined by the presence of a default route, maybe the presence of an address also matters. What applications need to do when they connect to a remote server is to try the next address when the first one fails and cycle through all addresses before giving up. Of course with IPv4 having multiple addresses is extremely rare so IPv4 applications typically don't bother with this, so it has to be addressed when IPv6ifying applications.
Re: IPv6 foot-dragging
On 11 mei 2011, at 16:39, William Astle wrote: I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about vote with your money doesn't work when you have limited choices. Apparently the need for IPv6 isn't yet high enough to consider adding a transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.
Re: IPv6 foot-dragging
On 11 mei 2011, at 19:01, George Bonser wrote: A couple of things you can do to check. First of all look for requests to your DNS servers for records and note where those are coming from. Firefox has for a long time done both A and lookups even if the system doesn't have IPv6. I believe MacOS does this too, now. Don't know about other apps/OSes, but for sure you'll see tons of lookups from people who have no IPv6 connectivity. Then note who is arriving over v6 asking for records. Those are the best candidates for enabling v6 services. Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers. In my opinion, looking at this kind of stuff in order to draw conclusions about what you should do is a waste of time. It just means more work for everyone and it doesn't fix any of the broken stuff that's out there. If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry-wide but this time we don't turn it off again.
Re: IPv6 foot-dragging
On 11 mei 2011, at 19:32, George Bonser wrote: If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry- wide but this time we don't turn it off again. 0.1% of users is a HUGE number if you have 1,000,000 subscribers. Are you prepared to field 1,000 helpdesk calls or lose 1,000 customers? Apparently we are, at least for the former, otherwise there wouldn't be an IPv6 day. It isn't something you just throw out there on a whim and tell people to like it or lump it if there are potentially a lot of people involved. So what's the alternative? Never change anything? Remember, this is al extremely trivial stuff: most things won't even completely stop working. And a few mouseclicks (yes, you have to know which ones so the helpdesks better start figuring that out) and you're back to normal. Compare this to turning off analog TV transmitters that have been running for decades where people have to buy converter boxes and sometimes even install antennas on their roof to keep using the service.
Re: IPv6 foot-dragging
On 11 mei 2011, at 20:39, George Bonser wrote: So what's the alternative? Never change anything? Of course not. But the best course forward is going to be different for different folks. What might work best for me might not (probably WILL not) work best for everyone else. One has to look at their situation and plan the best path for their business with their architecture and the resources they have available to them. I suggested one option but that might not work for others. I find it strange that you approach this issue as one of the great questions of our time. If you don't want to enable IPv6 for your service at this time, then don't enable IPv6 for your service at this time. But you'll have to do it at some point, so doing it together with your competitors and/or big players seems like a good choice. Going through huge lengths to optimize for a problem that will only exist for a couple of years or so doesn't make sense to me. Also, all this special case logic has a nasty tendency to create all kinds of unexpected problems down the road. I'm sure that the people at Microsoft thought it was a swell idea to enable 6to4 by default. If they hadn't done that, they'd saved us all a lot of wasted time.
Re: Yahoo and IPv6
On 9 mei 2011, at 21:40, Tony Hain wrote: Publicly held corporations are responsible to their shareholders to get eyeballs on their content. *That* is their job, not promoting cool new network tech. When you have millions of users hitting your site every day losing 1/2000 is a large chunk of revenue. Nonsense. 0.05% is well below the noise margin for anything that involves humans. The fact that the big players are doing world IPv6 day at all should be celebrated, promoted, and we should all be ready to take to heart the lessons learned from it. I applaud the first step, but I'm bothered by the fact that no second step is planned. The content providers are not to be blamed for the giant mess that IPv6 deployment has become. If 6to4 and Teredo had never happened, in all likelihood we wouldn't be in this situation today. The entire point of those technologies you are complaining about was to break the stalemate between content and network, because both sides will always wait and blame the other. You're both somewhat right: there's nothing wrong with having 6to4 and Teredo available as an option for people who want/need easy IPv6, which is too hard to get otherwise for most people. The big mistake was to enable it by default. That ALWAYS ends badly. (See for instance HTTP pipelining, good idea but it got tainted by buggy implementations on the client side that made it impossible to enable on the server side.) The fact that the content side chose to wait until the last possible minute to start is where the approach falls down. Expecting magic to cover for lack of proactive effort 5-10 years ago is asking a bit much, even for the content mafia. The content people don't feel the address crunch and they have no incremental deployment: either you or you don't . The opposite is true for the eyeball people, so they are the ones that will have to get this ball rolling. In any case, the content side can mitigate all of the latency related issues they complain about in 6to4 by putting in a local 6to4 router and publishing the corresponding 2002:: prefix based address in DNS for their content. That wouldn't help people behind firewalls that block protocol 41 (which is way too common) and it's harmful to those with non-6to4 connectivity but no (good) RFC 3484 support so they connect to those 2002:: addresses. (I'm looking at you, MacOS. Try for yourself here: http://6to4test3.runningipv6.net/ ) We are about the witness the most expensive, complex, blame-fest of a transition that one could have imagined 10 years ago. This is simply due to the lack of up-front effort that both sides have demonstrated in getting to this point. Now that time has expired, all that is left to do is sit back and watch the fireworks. I love fireworks. I don't think it'll be all that bad, though. Pretty much all the pieces are in place now, it's mostly a question of simply enabling IPv6. Yes, people will whine but how else would we know the NANOG list is still working between operational issues?
Re: L3 ECMP over links with different RTT
On 10 mei 2011, at 16:28, Dikkema, Michael (Business Technology) wrote: Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one of the links having a 50% longer RTT? No problem at all as long as you don't do per-packet load balancing but something that makes sure a single flow only goes over a single link. There are many ways to skin that particular cat, best practice is based on the 5-tuple (source and dest addresses and ports and the protocol number) which will give you the best chance of having a similar load on both links as long as you have at least some 1000 flows at any given time. With less granular load balancing there's a much bigger risk that one link will be full and the other more or less idle unless you have very, very many flows. You may want to use VLANs so you can load balance some stuff as per the above and manually balance some other stuff to go over the faster link.
Re: Yahoo and IPv6
On 10 mei 2011, at 22:31, Warren Kumari wrote: :: I applaud the first step, but I'm bothered by the fact that no second step is planned. Igor is right on both counts here -- 0.05% is definitely noticeable at these sorts of scale, Ok, removed my infamatory reply. But tell me how 0.05% is visible in the up/down motions of traffic as it starts raining, there is something especially good/bad on TV, people have to reboot because of a Windows update or whatever. Earlier today I tracerouted the top 1000 websites as per Alexa. I couldn't resolve the DNS for 6 of them. The internet is never 100% up. I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it? I asked the ISOC press people about this after they sent me their press release but they never replied (they may have replied to my message but not with an answer to the question). There is nothing on the ISOC site that mentions anything happening after june 8. Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.
Re: How is IPv6 deployment going in the APNIC region?
On 15 apr 2011, at 12:21, Geoff Huston wrote: The addresses were in flight to the recipient and got caught up in a set of scripted processes that inappropriately assigned them into the debogon project for a couple of days while some related administrative processes were underway. Our apologies for the temporary confusion -- and we promise do better next time! :-) Thanks for the clarification. But I hope you're not planning on running out of IPv6 anytime soon... Or maybe you're getting at 16-bit AS numbers? And yes, APNIC is indeed down to the last /8 Hm, I still see 2.27 million legacy addresses as free, mostly 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 million non-legacy. Why don't these count and/or what will happen to them? Iljitsch
Re: How is IPv6 deployment going in the APNIC region?
On 14 apr 2011, at 8:33, Tore Anderson wrote: Actually, they're already empty. Chinanet Fujian Province Network allocated 498432 addresses today, spread out over 1102(!) individual prefixes in the range /21-/24. Where do you see this? On ftp.apnic.net I see delegated-apnic-20110414 which only contains info upto the 13th and has a timestamp of Apr 13 15:15. Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete what's left. I also don't get what they did two days ago: inetnum:39.192.0.0 - 39.255.255.255 netname:Debogon-prefix descr: APNIC Debogon Project This is address space that's now marked as delegated and removed from the pile of unused address space for no obvious reason.
Re: How is IPv6 deployment going in the APNIC region?
On 14 apr 2011, at 13:50, Tore Anderson wrote: This is address space that's now marked as delegated and removed from the pile of unused address space for no obvious reason. I believe they are using those prefixes for research. and the delegated-extended file, it appears that these prefixes do count as assigned space like any other assignment. I would assume that when the research project is over, they will be returned to the free pool and assigned under the last /8 policy That is extremely curious. How can they justify taking 4 million addresses for research two days before running out of regularly allocatable address space? They could have taken that /10 out of the final /8 rather than taking it from the last scraps of regular space if they really need a /10 for research, which is already dubious in and of itself. Of course they didn't bother to respond to my request for information about all of this.
Re: How is IPv6 deployment going in the APNIC region?
On 14 apr 2011, at 13:02, Iljitsch van Beijnum wrote: Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete what's left. I just got the 15 apr file which has the info for 14 apr (sigh...) and indeed 1100 blocks adding up to 0.52 million addresses were given out today. And that still leaves 2.27 million legacy addresses available, including all of 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 million non-legacy, non-103/8 addresses. 103/8 is apparently going to be the special final /8. It's still wide open except a /16, a /22 and a /24 that are registered to the debogon project (as of a week and a half ago).
Re: How is IPv6 deployment going in the APNIC region?
On 15 apr 2011, at 0:04, Skeeve Stevens wrote: All… as of early this morning, APNIC is empty. Why do you say that? Do you have information that contradicts my numbers?
Re: admin-c/tech-c deny responsibility/ownership of netblock
On 22 feb 2011, at 20:44, goe...@anime.net wrote: The admin-c, tech-c deny any responsibility for this netblock. Have you talked to RIPE?
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 17 feb 2011, at 17:35, George Bonser wrote: Considering v4 is likely to be around for another decade or two, getting Class E into general use seems easy enough to do. You really think people will be communicating over the public internet using IPv4 in 2031? It will take a long time before the first people are going to turn off IPv4, but once that starts there will be no stopping it and IPv4 will be gone very, very quickly. (Of course there will be legacy stuff, just like some people are still running IPX or AppleTalk today. I'm talking about the public internet here.) Today people are complaining how annoying it is to have to learn new things to be able to run IPv6, but that doesn't compare to how annoying it is to have to learn OLD things to keep running a protocol that is way past its sell by date. I still need to teach class A/B/C despite the fact that CIDR is old enough to drink in most countries because without knowing that you can't configure a Cisco router. That's annoying now. Think about how insane that will be in the 2020s when the notion of requesting IPv4 addresses from an RIR is ancient history and young people don't know any better than having a /64 on every LAN that is big enough to connect all ethernet NICs ever made. Speaking of class E: this address space could be usable for NAT64 translators. That way, only servers and routers need to be upgraded to work with class E, not CPEs or client OSes.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 17 feb 2011, at 18:57, John Curran wrote: Actually, as I have noted before, the US DoD has contractually agreed to return to ARIN unneeded IPv4 address space if/when such becomes available, so that it may be used by the Internet community. How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On 18 feb 2011, at 9:24, Zed Usser wrote: Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You forget: - no IPv6 tunnels Deploying NAT444 without IPv6 is a very bad thing.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote: How can they return stuff to ARIN that they got from IANA in the first place? ARIN seems to be getting the very long end of the legacy stick. But last time I checked, the United States is in the ARIN region. And ARIN did not exist when the US DoD got its space. (In fact, I do believe the reason IP space exists is because the DoD paid someone to come up with the idea? :) True, but how is all of that relevant? If the US DoD wants more space, it has to ask ARIN, right? Are you suggesting it should deal with a different organization depending on which direction the IP addresses flow? Supposed it was space ARIN assigned the DoD? Policies like giving each RIR one of the final five /8s were carefully created to give each RIR equal access to address space. Automatically giving legacy space to the RIR for the region that the holder of the legacy space is in is incompatible with that, and means that ARIN will get virtually all of it. To me, it seems both natural and fair that legacy space (especially /8s) is returned to IANA and then redistributed over the RIRs. By the way, IANA only deals in /8s. However, a lot of people got legacy /16s or other non-/8 sizes, so some /8s that are marked legacy actually contain a lot of unused space. Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. And if not, what is supposed to happen with this space. It's a significant amount, about half the size of the class E space: RIR Administerd byDelegated Free afrinic 33.55 M 8.71 M24.85 M apnic 100.66 M 77.95 M22.72 M arin 671.09 M 592.04 M79.05 M ripencc 67.11 M 63.01 M 4.10 M
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:36, Tore Anderson wrote: Each of those /8 is administered by a RIR, but it's unclear (to me at least) whether that means that RIR gets to give out that space in its region or not. The unused space in the ERX blocks were divided evenly between the RIRs a couple of years ago, see: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf Please find attached a summary spreadsheet (Excel format) providing the agreed distribution of administrative responsibility This still leaves the question of which RIR gets to give out which parts of the unused legacy space unanswered.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 12:59, Tore Anderson wrote: Hit your Page Down button a couple of times, it's included right there in the PDF. I don't see anything that clears this up.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 18 feb 2011, at 14:10, Arturo Servin wrote: When you talk about unused legacy space are you talking about the various space or to the legacy space that is currently assigned but the holders just require part of it? Legacy space (A) = all the /8s marked as legacy by IANA. Used legacy space (B): addresses allocated/assigned according to one of the RIRs which falls within A. Unused legacy space (C): A - B. Examples: lots of class B networks, either they were never given out or they were returned. And 45/8 minus 45.0.0.0/15.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 11 feb 2011, at 17:51, William Herrin wrote: We can't backport ULA into IPv4 private addressing; there aren't enough addresses for the math to work. So we either make such folks jump through all kinds of hoops to get their networks to function, or we assign addresses that could otherwise be used on the big-I Internet. Not that it matters because it's too late now and it would only give us a few more months, but: Does the US government really need more than 150 million addresses, of which about half are not publically routed? Non-publically routed addresses can be reused by others as long as the stuff both users connect to doesn't overlap.
Re: quietly....
On 14 feb 2011, at 6:46, Frank Bulk wrote: Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? But I lost this argument in the IETF years ago, so I guess I'm relatively alone here.
Re: Too bigs are sacred, was: Re: IPv6 addressing for core network
On 10 feb 2011, at 0:26, David Freedman wrote: Unless every packet you emit is ≤ the minimum MTU (1280), then, you need to be able to receive TOOBIG messages. Can you think of a packet type I will emit from my publically numbered backbone interface which may solicit a TOOBIG that I'll have to care about? What if you're trying to connect to your routers with 1500-byte+ POS, ATM, ethernet jumbo or what have you interfaces from some system with a big fat jumboframe MTU but some 100 Mbps ethernet firewall or office network in the middle? If you're willing to accept TCP or UDP from somewhere, it's a bad idea to filter ICMP coming in from that same place.
Re: Looking for an IPv6 naysayer...
On 10 feb 2011, at 1:52, Jeff McAdams wrote: I've always worked in small to middle sized shops, and I have always found that I've been able to yell and scream about IPv6 (and other features) loud enough, and long enough that I get heard by someone in a decision making position for product features (usually along the lines of a product manager or so). And every time I've made the effort to do that (admittedly, not a small effort), that product or line of product has had IPv6 available for it within about a year or so (if not sooner). About 10 years ago I was involved in a project where we were looking for one or two dozen or so gigabit ethernet switches. That order would have barely broken into six figure territory. One sales engineer came around with their product and I remarked no jumboframe support? your competitors all do 9000 bytes! A week later, he was back with a newer version of the same box... with 64000-byte jumboframe support. :-)
Re: BCP38 considerations in IPv6
On 10 feb 2011, at 22:34, Ryan Rawdon wrote: What considerations should be made with respect to implementing egress filtering based on source IPv6 addresses? Things like allowing traffic sourced from fe80::/10 in said filters for on-link communication (for the interface that the filter is applied to). Is there anything else that should be taken into account while implementing BCP38 egress filtering in IPv6? There's a lot of language in the RFCs about this type of addresses not being forwarded by routers, so filtering shouldn't be necessary. I know that Cisco lets neighbor discovery through before the implicit deny is applied, so specifically allowing link locals for neighbor discovery isn't necessary either. (I would assume other vendors do the same, but it's of course a good idea to check.) The only time you have to be careful is when you do a deny all, because you need neighbor discovery unless you use static neighbor cache entries. ND also uses multicast, so you need to let that through as appropriate, too.
Re: IPv6 addressing for core network
On 9 feb 2011, at 5:24, Vikas Sharma wrote: I am looking for the recommendation for core interfaces IP addressing schema for Ipv6. Some different views are (PE- P - PE, point to point link) as below - Is there a NANOG FAQ we can add this to? 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. I recommend /112 because that way the part of the address after the last colon is the subnet. 3- Use Unique local ipv6 address Not recommended, because now traceroute replies and, if applicable, much worse, PMTUD responses come from bogon space so some people will filter them. So absolutely do not do this if you have any non-1500-byte MTUs in your network. 4- Use Public Ipv6 with /64 /64 has the advantage that you can use EUI-64 addressing so you don't have to remember which exact address each router has, just let that be filled in from the MAC address. The IPv6 addressing architecture RFCs also say you must use /64 but no reason for this is given so I don't feel bound by that. But having a global scope address on your router-to-router interfaces is such IPv4 thinking. You don't need that with IPv6 unless you want to be able to ping individual interfaces. Routing protocols only use the link local addresses and when ICMP messages have to be generated a global scope address is borrowed from another interface, such as the loopback interface.
Re: IPv6 addressing for core network
On 9 feb 2011, at 10:48, sth...@nethelp.no wrote: The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors. I know it's immature, but I can't wait for some new hire at vendor C or vendor J to reread the RFCs and implement the all routers anycast address according to spect and then see sparks fly. Like I said, global scope addresses on your router-to-router interfaces is such IPv4 thinking.
Re: IPv6 addressing for core network
On 9 feb 2011, at 11:16, sth...@nethelp.no wrote: If you can get router ICMP handling changed such that the ICMP packet generated by traceroute is sent from the loopback address, we might be able to do without global scope addresses on router-to-router interfaces. But until then... I'm pretty sure this is standard behavior for routers, and especially Cisco routers. However, I can't find any documentation for this real quick, either in an RFC or Cisco documentation.
Too bigs are sacred, was: Re: IPv6 addressing for core network
On 9 feb 2011, at 18:30, David Freedman wrote: (yes, even ICMP TOOBIG can be filtered safely if you have designed things in a sane way) NO. Even if you run with 1280-byte MTUs everywhere so you'd think path MTU discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4 translators.
Re: IPv6 - a noobs prespective
On 9 feb 2011, at 19:30, Tony Hain wrote: Making the mass change of enabling the servers at the point you expect service to work is just asking for support calls... Do that on june 8 like everyone else. :-) http://isoc.org/wp/worldipv6day/
Re: Looking for an IPv6 naysayer...
On 9 feb 2011, at 20:53, William Herrin wrote: * Carrier NAT buys us enough years to build an IPv4 successor You're kidding, right? How long did it take exactly to get where we are now with IPv6? 18, 19 years? And yet there's still all kinds of stuff that isn't really ready for prime time yet. * Next protocol should really be designed to support interoperability with the old one from the bottom up. IPv6 does not That's because it's not the headers that aren't incompatible (the protocol translation is ok even though it could have been a bit better) but the addresses. A system that knows about 32-bit addresses will just not talk to a system with a 128-bit address. Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. But then, 32-bit ASes interoperate with 16-bit ones with no trouble and still after a decade the support for that is not nearly good enough, either.
Re: Looking for an IPv6 naysayer...
On 9 feb 2011, at 20:21, Scott Helms wrote: IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently [...] For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable. The good thing is that as an ISP, you don't have to give everyone the same thing. For the content people, it's either an record in the DNS or no record in the DNS. But as an ISP, you can keep your existing customers on existing IPv4 using existing hardware, while you roll out CGNAT + IPv6 for new customers using new gear. (Yes, that's still going to be annoying, but annoying in the sort of I wish I didn't have to but I guess I do kind of way rather than the this will bankrupt the company kind of way.) As long as your legacy users have an IPv4 address they can always use tunneling to get IPv6 (you may want to set up a tunnel termination box for this) if they need IPv6. But they won't really _need_ IPv6 (at least not very soon) because they can set up port mappings etc and everything they need can work over IPv4. For the new users, there are no port mappings behind the CGNAT so they do need IPv6 for hosting services and for VoIP and peer-to-peer file sharing. They also can't get a protocol 41 tunnel so you, their ISP, has to provide them with IPv6. But just CGNAT with no IPv6 is going to be very bad. Maybe 95% of your users won't notice, but do you really want the other 5% to tie up your support lines?
Re: Looking for an IPv6 naysayer...
On 9 feb 2011, at 21:17, George Herbert wrote: Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but when did 7 happen? RFC 1475, apparently: http://www.iana.org/assignments/version-numbers/version-numbers.xhtml
Re: Looking for an IPv6 naysayer...
On 9 feb 2011, at 21:23, George Bonser wrote: While that is true, it is no worse than the situation right now. In the US, the vast majority of users are already behind a NAT (I would say over 90% of them are) so they are already experiencing this breakage. There's a big difference between being able to have uPNP IGD or NAT-PMP open up holes in the NAT (or do it manually) and being 100% incapable of getting any and all incoming sessions. And between having 64k ports for a home and having 64k ports for 100, 1000, 1 ? homes.
IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 9 feb 2011, at 21:26, William Herrin wrote: You're kidding, right? How long did it take exactly to get where we are now with IPv6? 18, 19 years? Tech like carrier NAT theoretically yeilds address reclamation in excess of 80%. Most IPv4 space is unused anyway, but it's not being reclaimed much despite that. (How many IP addresses does the US federal government need? Few people would think ~ 10 /8s. Especially since many of them aren't even lit up.) * Next protocol should really be designed to support interoperability with the old one from the bottom up. IPv6 does not That's because it's not the headers that aren't incompatible (the protocol translation is ok even though it could have been a bit better) but the addresses. No, it's because decisions were made to try to abandon the old DFZ table along with IPv4 and institute /64 as a standard subnet mask. But for those choices, you could directly translate the IPv4 and IPv6 headers back and forth, at least until one of the addresses topped 32 bits. The transition to IPv6 could be little different than the transition to 32-bit AS numbers -- a nuisance, not a crisis. You recompile your software with the new IN_ADDR size and add IP header translation to the routers, but there's no configuration change, no new commands to learn, etc. It's not that simple. But I agree on one thing: it could have been better. What needs to be done to move from IPv4 to IPv6 is three things: 1. the headers 2. the addresses 3. the applications Today, only IPv6 applications can use IPv6 addresses and only when IPv6 applications use IPv6 addresses will there be IPv6 headers. It would have been better to roll out the headers first. That would have meant changes to routers, because routers touch the headers. But if translating between IPv6 with 32-bit addresses and IPv4 can be done with low overhead (which is more or less the case today, BTW) then it would have been possible to upgrade from IPv4 to IPv6 subnet by subnet. This way, there wouldn't have had to be any dual stack, and once people had deployed IPv6 they would have kept using it. Today, and especially some years ago, IPv6 would/will often atrophy after having been deployed initially because of lack of use. Apps could have been upgraded the same way they have now, with the only difference that using an IPv4-mapped IPv6 address meant generating an IPv6 packet, not an IPv4 packet as is done today. Once 128-bit addresses are being used going from an IPv6 subnet to an IPv4 subnet becomes problematic, but this can be solved with stateful translation so most stuff keeps working anyway. And remember, servers and apps that can't work through a stateful translator can still get 32-bit addresses so everything keeps working without trouble. However, it's easy to come up with all of this in 2011. In 1993 the world was very different, and many things we take for granted today were still open questions then. It's very illuminating to read up on the mailinglist discussions from back then. People complained about IPv6 a decade or half a decade ago, too. Back then there may have been a chance to come up with a different protocol as a successor for IPv4, but it's way too late for that now. Anyway, most non-legacy applications support 128-bit addresses now and we have a pretty decent NAT64 spec sitting in the RFC editor queue (even if I do say so myself) so it's just a matter of sitting tight until we're through the painful part of the transition.
Re: Failure modes: NAT vs SPI
On 4 feb 2011, at 22:02, Dave Cardwell wrote: Without wanting to get into whether NAT provides security to hosts that exist on the inside. I am curious if the potential to overflow ND caches with incomplete* entries exists on currently shipping CPE hardware and if NAT helps prevent this? e.g. In v4 with a /24 on the inside an attacker can send a single packet to each consecutive address causing at most 254 arp requests to be sent on the lan segment and upto 253 incomplete entries, until they timeout. In v6 with a /64 on the inside it seems like the same tactic would lead to more outstanding ND requests than any realistically sized cache would support. Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... This is of course a very big problem, and one of the reasons why everyone who's tried IPv6 immediately turns it off again: script kiddies are continuously scanning the entire IPv6 address space so this happens to regular IPv6 users all the time. Since this is a problem that is inherent to the ND protocol that is impossible to fix without modifying the IPv6 standards significantly, the easiest way to solve this with the least amount of impact to applications, the ability to host services and the end-to-end model in particular is to use a single public IPv6 address and NAT all local stuff behind it. (BTW, there have been some discussions on NAT66 in the IETF, but that wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, because with IPv6, there obviously isn't any reason to use address sharing. The thinking is that such a 1-to-1 NAT is less harmful than a port overloading 1-to-many NAT so it would be beneficial to specify the former to avoid the latter. But many people within the IETF don't support that strategy.)
Re: Failure modes: NAT vs SPI
On 7 feb 2011, at 17:15, Jay Ashworth wrote: Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order... I see you decided to go with sarcastic. Not sure if Owen noticed... :-) I'm sure it's clear to you that no one's doing it now is not a valid response to prophylactic secure network planning... Well, no and yes. There's only a few panes of glass keeping people out of most houses. We know glass is easy to break. We know it gets broken and people get in who aren't wanted there once in a while. Still only a few people see the need to install steel bars in front of their windows. In real life we take risks all the time. In the networked world somehow it always has to be all or nothing, with few people occupying the reasonable middle ground. But in this case, we know there's a potential problem and waiting for it to become acute is not the best approach. So, you're not going to actually address the problem seriously? Vendors should modify their neighbor discovery implementations such that it still works even when large numbers of addresses are scanned. The easiest way would be to keep only a limited number of incomplete ND cache entries and throw those away on an LRU base, but create a full ND cache entry that is kept around when a neighbor advertisement is received, even if there is no incomplete ND cache entry at that time. AFAIK the incomplete ND cache entries don't do anything we can't do without. Solving this with NAT is the classic example of shooting a mosquito with a canon. I also don't think any protocol modifications are necessary.
IPv6 routing talk @ RIPE, was: Re: quietly....
On 2 feb 2011, at 23:40, Lamar Owen wrote: I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). Now, taking the op hat off for a moment, and stepping down from the soapbox, this is something that could be useful; has this talk been recorded and/or transcribed? If so, that's a useful resource, and, an hour and a half of relevant material is much easier to swallow than some of the books out there. Yes, they recorded it (but in pretty low quality and they didn't bother to cut out the many minutes during which we tried to get the projector and my laptop to talk to each other). It's linked at the top of this page: http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html These are the slides: http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf
Re: quietly....
On 3 feb 2011, at 17:16, Jon Lewis wrote: When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want. People are going to want NAT66...and not providing it may slow down IPv6 adoption. Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? Or do you propose to make IPv6 home gateways the same way IPv4 home gateways work, where it's usually not even possible to turn it off? Consumer systems need to be able to function without a firewall device, anyway. Who brings a firewall to a wifi hotspot, or puts one between his laptop and 3G adapter? I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4.
