Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
I think, the length of Interface ID be 64 is so mostly because IEEE works now with 64bit EUI identifiers (instead of older 48bit MAC addresses). I.e. compatibility between IEEE and IETF IPv6 would be the main reason for this Interface ID to be 64. And this is so, even though there are IEEE links for which the MAC address is even shorter than 64bit, like 802.15.4 short addresses being on 16bit. For those, an IPv6 prefix length of 112bit would even make sense. But it's not done, because same IEEE which says the 15.4 MAC address is 16bit says that its EUI is 64bit. (what 'default' fill that with is what gets into an IPv6 address as well). The good thing isthere is nothing in the RFC IPv6 Addressing Architecture that makes the Interface ID to be MUST 64bit. It just says 'n'. What there _is_, is that when using RFC stateless addess autoconfiguration (not DHCP) and on Ethernet and its keen (WiFi, Bluetooth, ZigBee, more; but not USB nor LTE for example) then one must use Interface ID of 64bit; and consequently network prefix length of 64bit no more. Alex Le 06/06/2012 16:58, Chuck Church a écrit : Does anyone know the reason /64 was proposed as the size for all L2 domains? I've looked for this answer before, never found a good one. I thought I read there are some L2 technologies that use a 64 bit hardware address, might have been Bluetooth. Guaranteeing that ALL possible hosts could live together in the same L2 domain seems like overkill, even for this group. /80 would make more sense, it does match up with Ethernet MACs. Not as easy to compute, for humans nor processors that like things in 32 or 64 bit chunks however. Anyone have a definite answer? Thanks, Chuck -Original Message- From: jean-francois.tremblay...@videotron.com [mailto:jean-francois.tremblay...@videotron.com] Sent: Wednesday, June 06, 2012 10:36 AM To: an...@huge.geek.nz Cc: NANOG list Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) Anton Smith an...@huge.geek.nz a écrit sur 06/06/2012 09:53:02 AM : Potentially silly question but, as Bill points out a LAN always occupies a /64. Does this imply that we would have large L2 segments with a large number of hosts on them? What about the age old discussion about keeping broadcast segments small? The /64 only removes the limitation on the number of *addresses* on the L2 domain. Limitations still apply for the amount of ARP and ND noise. A maximum number of hosts is reached when that noise floor represents a significant portion of the link bandwidth. If ARP/ND proxying is used, the limiting factor may instead be the CPU on the gateway. The ND noise generated is arguably higher than ARP because of DAD, but I don't remember seeing actual numbers on this (anybody?). I've seen links with up to 15k devices where ARP represented a significant part of the link usage, but most weren't (yet) IPv6. /JF
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Le 07/06/2012 22:27, Ricky Beam a écrit : On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church chuckchu...@gmail.com wrote: Does anyone know the reason /64 was proposed as the size for all L2 domains? There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 is a classless addressing system. You can make your LAN ::/117 if you want to; SLAAC will not work there. SLAAC could work with ::/117 but not on Ethernet and its keen. There are many other links than Ethernet and IEEE. Nothing (no RFC) prohibits SLAAC with something longer than 64, provided a means to form an Interfac Identifier for that particular link is provided. I.e. a new document that specifies e.g. IPv6-over-LTE (replace LTE with something non-IEEE). Alex The reason the requirement is (currently) 64 is to accomodate EUI-64 hardware addresses -- firewire, bluetooth, fibre channel, etc. Originally, SLAAC was designed for ethernet and its 48bit hardware address. (required LAN mask was ::/80.) The purpose wasn't to put the whole internet into one LAN. It was to make address selection brainless, esp. for embeded systems with limited memory/cpu/etc... they can form an address by simply appending their MAC to the prefix, and be 99.9% sure it won't be in use. (i.e. no DAD required.) However, that was optimizing a problem that never existed -- existing tiny systems of the day were never destined to have an IPv6 stack, modern IPv6 hardware can select an address and perform DAD efficiently in well under 1K. (which is noise vs. the size of the rest of the IPv6 stack.) SLAAC has been a flawed idea from the first letter... if for no other reason than it makes people think 64bit network + 64bit host -- and that is absolutely wrong. (one cannot make such assumptions about networks they do not control. it's even worse when people design hardware thinking that.) --Ricky
Re: subnet prefix length 64 breaks IPv6?
Le 03/01/2012 23:36, Owen DeLong a écrit : On Dec 24, 2011, at 6:48 AM, Glen Kent wrote: SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). Ok, the last 64 bits of the 128 bit address identifies an Interface ID which is uniquely derived from the 48bit MAC address (which exists only in ethernet). Not exactly. Most media have some form of link-layer addressing. For Firewire, it's native EUI-64. For Ethernet, it's EUI-48 MAC addresses. For token ring, I believe there are also EUI-48 addresses. For FDDI (Remember FDDI?) I believe it was EUI-48 addresses. ATM and Frame Relay also have EUI addresses built in to their interfaces (though I don't remember the exact format and am too lazy to look it up at the moment). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. If we can do this for a p2p link, then why cant the same be done for an ethernet link? I'm not so sure the statement above is actually true. I think that's right, sorry. I mean - a reread of the PPPv6 RFC tells that the Interface ID negotiated by PPP is stricly 64bit length. (although it does refer to rfc4941 which specifically acks that note that an IPv6 identifier does not necessarily have to be 64 bits in length). It's a mess :-) Alex Owen Glen Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex Regards, K.
Re: subnet prefix length 64 breaks IPv6?
Le 28/12/2011 16:45, sth...@nethelp.no a écrit : If every route is nicely split at the 64-bit boundary, then it saves a step in matching the prefix. Admittedly a very inexpensive step. My point here is that IPv6 is still defined as longest prefix match, :-) yes agree, except that it's not known what longest prefix match is precisely. It is widely implemented in often closed source code, there is books about it and lectures to first-year students. I have heard it named crown jewels of some companies. High value and no specification == speculation. Alex so unless you *know* that all prefixes are= 64 bits, you still need the longer match. In this context, it is perfectly reasonable, and expected, that the use of longer prefixes will have a higher cost. In a way I agree with you. However, if I put my purchasing hat on, I would refuse to buy equipment that could only forward on the first 64 bits, *or* where the forwarding decision was much slower (hardware vs software) for prefixes longer than 64 bits. I would not be surprised if vendors decide that it is a *commercial* necessity to support full 128 bit matches. However, I think the number of routes, and your network architecture play a significant factor. Absolutely. In our network by far the largest number of IPv6 prefixes are EBGP prefixes in the 32 to 48 bit range. However, we also have for instance our own 128 bit loopbacks - they are obviously only in our IGP. I think a greater concern than simple routing and forwarding, would be additional services, such as queuing, or filtering. These may be implemented in hardware when a 64-bit boundary is used, but punted to CPU otherwise. Though this would be implementation specific and is something you would want to research for whatever hardware you're running. Again, that would be an excellent reason *not* to buy such equipment. And yes, we know equipment that cannot *filter* on full IPv6 + port number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my original point was that I still haven't seen equipment with forwarding problems for prefixes 64 bits. There are a few solutions that vendors will hopefully look into. One being to implement neighbor discovery in hardware (at which point table exhaustion also becomes a legitimate concern, so the logic should be such that known associations are not discarded in favor of unknown associations). I'm afraid I don't believe this is going to happen unless neighbor discovery based attacks become a serious problem. And even then it would take a long time. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: subnet prefix length 64 breaks IPv6?
Le 28/12/2011 13:13, Ray Soucy a écrit : On Wed, Dec 28, 2011 at 6:23 AM, Iljitsch van Beijnum iljit...@muada.com wrote: 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. This ambiguity has always bothered me. The address architecture RFC requires a 64-bit interface identifier, Well yes, but only if it's an address which doesn't start with 000 (3 zero bits). I understand an address which starts with 000 can have an interface id of length generic 128-n where n is prefix length. (RFC4291 Addressing Arch, pp. 6, 1st par). Generally speaking, my mind is disturbed by suggestions that the Interface ID must always be precisely of length 64. BEcause there is no particularly valid reason to impose it so, other than the vaguely useful and semantically doubtful 'u' bit - any software ever checks it on reception? At an extreme reading, it may look as the secure bit. Yours, Alex but it's required to be unenforced by implementation, which makes it more of a suggestion at best. I think the wording should be updated to changed MUST to SHOULD. That said, and despite my own use of prefix lengths other than 64-bit, I do believe that a 64-bit prefix for each host network is in our long-term interest. Not having to size networks based on the number of hosts is a good thing. Features made possible by a 64-bit address space is a good thing.
Re: subnet prefix length 64 breaks IPv6?
Le 24/12/2011 11:58, Karl Auer a écrit : On Sat, 2011-12-24 at 15:37 +0530, Glen Kent wrote: Ok. So does SLAAC break with masks 64? Break is not the right word. SLAAC only works with /64, But that is by design. SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex Regards, K.
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
Frank Bulk a écrit : I think they're (all) listed here: http://www.getipv6.info/index.php/Broadband_CPE And from an operators perspective (not manufacturer): Free ISP ADSL (and fiber) operator in France does IPv6 natively to the end user with Router Advertisement since 2 years now. I think these CPE (Customer Premises Equipment) are called simply box in France (freebox, livebox, dartybox, and more). Between the Free box and the core network there is proprietary IPv6-in-IPv4 encapsualtion, not 6to4. No DHCPv6-PD, which I feel as a big restriction. Plans for livebox and 9box IPv6 do exist if not already deployed. Spanish FON Fonera based on openwrt, when I checked 2008, did IPv6 somehow, not sure whether natively. http://boards.fon.com/viewtopic.php?f=1t=4532view=previous From memory, at least one Japanese residential operator did IPv6 to the home several years ago, with explicit IPv6 advertisement on TV during prime time. Alex Frank -Original Message- From: Wade Peacock [mailto:wade.peac...@sunwave.net] Sent: Wednesday, December 02, 2009 5:16 PM To: nanog@nanog.org Subject: Consumer Grade - IPV6 Enabled Router Firewalls. We had a discussion today about IPv6 today. During our open thinking the topic of client equipment came up. We all commented that we have not seen any consumer grade IPv6 enable internet gateways (routers/firewalls), a kin to the ever popular Linksys 54G series, DLinks , SMCs or Netgears. Does anyone have any leads to information about such products (In production or planned production)? We are thinking that most vendors are going to wait until Ma and Pa home user are screaming for them. Thoughts?
Re: Consumer Grade - IPV6 Enabled Router Firewalls.
Mohacsi Janos a écrit : On Thu, 3 Dec 2009, Matthew Moyle-Croft wrote: Mohacsi Janos wrote: According to Apple the latest Apple Airport Extreme does support DHCPv6 prefix delegation and native IPv6 uplink not only 6to4. Airports don't support DHCPv6 PD yet. I'm led to believe that they may in the future from my Apple friends but not yet. It does in a limited extent: http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00086.html Not sure that is DHCPv6 PD (Prefix Delegation), the discussion doesn't seem to say so. If it is it would be wonderful. I will check soon the hardware. Great, please report, thanks, Alex Best Regards, Janos Mohacsi
