Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Justin M. Streiner wrote: I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments. As I already wrote: : That's not the point. The problem is that SRAMs scale well but : CAMs do not. it is a lot more difficult to quickly look up 1M routes with /48 than 2M routes with /24. If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4. The routing table grows mostly because of multihoming, regardless of whether it is v4 or v6. The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. Regards, Tim.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links. And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore traffic engineering pollution, but that doesn't get better or worse). Regards, Tim.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
(2012/06/25 18:00), Tim Franklin wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Are you saying they are end systems and local LANs? Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Tim Franklin wrote: at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. That's exactly why routing table is exploding today, at least with v4. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 25, 2012, at 12:06 AM, Masataka Ohta wrote: Justin M. Streiner wrote: I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments. As I already wrote: : That's not the point. The problem is that SRAMs scale well but : CAMs do not. it is a lot more difficult to quickly look up 1M routes with /48 than 2M routes with /24. It is incrementally more difficult, but not a lot at this point. Further, 2M routes in IPv4 at the current prefix:ASN ratios would only map to about 100,000 routes in IPv6. (IPv6 prefix:AS ratio is currently about 3:1 while IPv4 is around 14:1, so if all 35,000 active AS were advertising 3 IPv6 routes, we would be at about 100,000. Most of the growth in the IPv4 routing table represents increases in the prefix:ASN ratio whereas most of the growth in the IPv6 routing table represents additional ASNs coming online with IPv6.) If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4. The routing table grows mostly because of multihoming, regardless of whether it is v4 or v6. Assertion proved false by actual data. The majority of the growth in the IPv4 routing table is actually due to disaggregation and slow start. A smaller proportion is due to traffic engineering and multihoming. (See Geoff Huston's various presentations and white papers on this). The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links. This is not a solution. This is an administrative nightmare for the multihomed sites which has very poor failure survival characteristics. 1. Established flows do not survive a failover. 2. Every end host has to have knowledge of reachability which is not readily available in order to make a proper source address selection. The solution, in fact, is to move IDR to being locator based while intra-domain routing is done on prefix. This would allow the global table to only contain locator information and not care about prefixes. Currently, in order to do that, we unfortunately have to wrap the entire datagram up inside another datagram. If we were to create a version of the IPv6 header that had a field for destination ASN, we could do this without encapsulation. Unfortunately, encapsulation brings all the MTU baggage of tunneling. More unfortunately, changing the header comes with the need to touch the IP stack on every end host. Neither is an attractive option. It would have been better if IETF had actually solved this instead of punting on it when developing IPv6. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 25, 2012, at 7:09 AM, Masataka Ohta wrote: (2012/06/25 18:00), Tim Franklin wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Are you saying they are end systems and local LANs? Masataka Ohta Yes... Most people think of everything off the ISP network as Edge. So from the CPE outward, is the Edge to most people's thinking. Your definition of center vs. edge is misplaced compared to everyone else. This is what created the confusion between us when I first said 99% of the center was already IPv6 -- If you don't count CPE outwards as part of the center, then that is a valid statement. If you count the CPE, etc. as center and only count the very end host as edge, then, my other statement (that IPv6 deployment in this area is accelerating) is true. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote privately to me, but as I think I need public responses, I'm Ccing to nanog fairly quoting part of his response: Moreover, it is easy to have a transport protocol with 32bit or 48bit port numbers with the end to end fashion only by modifying end part of the Internet. The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. They still believed the fairy tale even when they designed automated tunneling. But, as most of them have grown up a little not to believe fairly tales, they are trying other possibilities. However, so far, they are not so successful. Masataka Ohta PS Rest of his response is omitted, because I think it is not worth quoting.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, Jun 22, 2012 at 8:46 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: MAJOR SNIP The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. Just injecting a real-world comment/observation here: I am sitting at home, on my natively IPv6 connected, Comcast-provided residential service. My phone is sitting next to me, connected to VZW's IPv6-capable LTE network. When I go to one of my client sites, they get IPv6 through a HE.net tunnel. Another client site uses ATT and/or CenturyLink for IPv6 connectivity. *... the list goes on ...* In all cases, IPv6 is alive and well for me. More importantly (even though the last-mile is not ubiquitously IPv6-enabled in all service regions) those five providers have backbones that are 100% up and running, native IPv6 all over the place. So what is the fairy tale?? Am I saying we are all done, and that IPv6 is fully deployed? Of course not, lots of work to do in the enterprise and last-mile areas ... but progress has been noticeable and is accelerating. /TJ
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
TJ wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. Am I saying we are all done, and that IPv6 is fully deployed? Of course not, lots of work to do in the enterprise and last-mile areas ... but progress has been noticeable and is accelerating. Owen tried to deny my point that: : Moreover, it is easy to have a transport protocol with : 32bit or 48bit port numbers with the end to end fashion : only by modifying end part of the Internet. As the enterprise and last-mile areas do not need to be modified to accommodate a new transport protocol, they belong to the center part. Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Masataka Ohta Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. QED, your statement does not stand up to current events. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. Remember that you wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 22, 2012, at 6:15 PM, Masataka Ohta wrote: Owen DeLong wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. Remember that you wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? You redefined center. My definition of center when I claimed 99% was the major backbones and core routers. That is the CENTER of the internet. Different definition of center (yours) where the center includes everything except the edge-most hosts, different metrics for completion and challenges. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Rate of deployment is more inclusive than just the 'center', that would be my guess. Are we really taking this already nearly-pointless conversation to an all new low and arguing semantics? Clearly some of us disagree with each other, perhaps we just hold our tongues ( fingers) and let the real world decide?? /TJ
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On 06/22/2012 08:35 PM, TJ wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Rate of deployment is more inclusive than just the 'center', that would be my guess. Are we really taking this already nearly-pointless conversation to an all new low and arguing semantics? Clearly some of us disagree with each other, perhaps we just hold our tongues ( fingers) and let the real world decide?? /TJ There might be good money in a PPV cagematch-style event.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
(2012/06/23 10:35), TJ wrote: Rate of deployment is more inclusive than just the 'center', that would be my guess. But, the context, as you can see, is this: : Even though it may be easy to make end systems and local : LANs v6 capable, rest, the center part, of the Internet : keep causing problems. : : Masataka Ohta : : Those problems are getting solved more and more every day. that the problems are caused by the center part. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 22 Jun 2012, Masataka Ohta wrote: Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. I really don't see where you're getting that from. The biggest consumers of IPv4 space in the US tended to get initial IPv6 blocks from ARIN that were large enough to accommodate their needs for some time. One large v6 prefix in the global routing table is more efficient in terms of the impact on the global routing table than the patchwork of IPv4 blocks those same providers needed to get over time to accommodate growth. Those 'green-field' deployments of IPv6, coupled with the sparse allocation model that the RIRs seem to be using will do a lot to keep v6 routing table growth in check. I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments. If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4. jms
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: Ah, you're on the I should be required to allow direct outside connection to my interior machines if I want to be connected to the Internet crowd. Speaking for myself, I'm one of the if I want to allow direct outside connection to my interior machines I should be able to crowd. And also one of the if I and someone else want to connect our hosts directly we should be able to crowd. That is, I don't want the architecture of the Internet to be crippled by NAT everywhere. If you want to NAT *your* network, go for it. As a local stalwart is wont to say, I encourage my competitors to do that ;-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: That is, I don't want the architecture of the Internet to be crippled by NAT everywhere. If you want to NAT *your* network, go for it. in this case, an air gap might be encouraged randy
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer wrote: Speaking for myself, I'm one of the if I want to allow direct outside connection to my interior machines I should be able to crowd. While direct and interior are not compatible that you actually mean some indirections... Anyway, what if, your ISP assigns a globally unique IPv4 address to your home router (a NAT box) which is UPnP capable? That's what the largest retail ISP in Japan is doing. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, 2012-06-21 at 21:04 +0900, Masataka Ohta wrote: Karl Auer wrote: Speaking for myself, I'm one of the if I want to allow direct outside connection to my interior machines I should be able to crowd. While direct and interior are not compatible that you actually mean some indirections... I am a native English speaker, and I actually meant exactly what I actually wrote. I have found direct and interior to be completely compatible. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 5:04 AM, Masataka Ohta wrote: Karl Auer wrote: Speaking for myself, I'm one of the if I want to allow direct outside connection to my interior machines I should be able to crowd. While direct and interior are not compatible that you actually mean some indirections... Anyway, what if, your ISP assigns a globally unique IPv4 address to your home router (a NAT box) which is UPnP capable? That's what the largest retail ISP in Japan is doing. Masataka Ohta Does not scale. Not enough IPv4 addresses to do that for 6.8 billion people on the planet. What if my ISP just routes my /48? Seems to work quite well, actually. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: Does not scale. Not enough IPv4 addresses to do that for 6.8 billion people on the planet. It is the first step to have the RSIP style transparent Internet. The second step is to use port numbers for routing within ISPs. But, it is not necessary today. What if my ISP just routes my /48? Seems to work quite well, actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 4:40 PM, Masataka Ohta wrote: Owen DeLong wrote: Does not scale. Not enough IPv4 addresses to do that for 6.8 billion people on the planet. It is the first step to have the RSIP style transparent Internet. The second step is to use port numbers for routing within ISPs. But, it is not necessary today. Still doesn't scale. 40 bits isn't enough to uniquely identify a conversation end-point. If you use port numbers for routing, you don't have enough port numbers for conversation IDs. What if my ISP just routes my /48? Seems to work quite well, actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Solvable. IPv6 has enough bits that we can use map/encap or other various forms of herarchical overlay ASN-based routing to resolve those issues over time. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: Owen DeLong wrote: What if my ISP just routes my /48? Seems to work quite well, actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Do you have any *realistic* and *actual* reason to suspect that the IPv6 routing table will explode any further than the IPv4 has already? Hint - Owen's /48 will just get aggregated and announced just like the cable companies *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - at which point he's a new entry in the v6 routing tables - but *also* almost certainly a new entry in the v4 routing table. Routing table size depends on the number of AS's, not the amount of address space the routes cover. pgpBjpETVNgvj.pgp Description: PGP signature
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 5:36 PM, valdis.kletni...@vt.edu wrote: On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: Owen DeLong wrote: What if my ISP just routes my /48? Seems to work quite well, actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Do you have any *realistic* and *actual* reason to suspect that the IPv6 routing table will explode any further than the IPv4 has already? Hint - Owen's /48 will just get aggregated and announced just like the cable companies *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - at which point he's a new entry in the v6 routing tables - but *also* almost certainly a new entry in the v4 routing table. Routing table size depends on the number of AS's, not the amount of address space the routes cover. Um, unlikely. My /48 is an ARIN direct assignment: 2620:0:930::/48 It's not really aggregable with their other customers. I do multihome and I am one entry in the v6 routing tables. However, I'm actually two entries in the v4 routing table. 192.159.10.0/24 and 192.124.40.0/23. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: It is the first step to have the RSIP style transparent Internet. The second step is to use port numbers for routing within ISPs. But, it is not necessary today. Still doesn't scale. 40 bits isn't enough to uniquely identify a conversation end-point. It's 48 bit. If you use port numbers for routing, you don't have enough port numbers for conversation IDs. That you use IPv4 addresses for routing does not make it unusable for identifications. Moreover, it is easy to have a transport protocol with 32bit or 48bit port numbers with the end to end fashion only by modifying end part of the Internet. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Solvable. It was solvable. IPv6 has enough bits that we can use map/encap or other various forms of herarchical overlay ASN-based routing to resolve those issues over time. The reality is that situation has been worsening over time. As RFC2374 was obsoleted long ago, it is now impossible to restore it. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
valdis.kletni...@vt.edu wrote: Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Do you have any *realistic* and *actual* reason to suspect that the IPv6 routing table will explode any further than the IPv4 has already? That's not the point. The problem is that SRAMs scale well but CAMs do not. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
valdis.kletni...@vt.edu wrote: hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays. So you're admitting that the NAT breaks things badly enough at the ISP level that running a forwarding ALG is easier than actually making the NAT work. No, I don't. I just wrote that, if servers' port numbers are not changeable, which has nothing to do with NAT, ISPs or someone else can run servers, not ALGs. It's like operating a server for whois, when whois commands had a hard coded fixed IP address of the server. Note that, at that time, the Internet was completely transparent that your argument has nothing to do with the transparency. (HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff) As you can see, there is no such problem. You haven't actually *deployed* your solution in a production environment, have you? Because we still have enough IPv4 addresses, because most users are happy with legacy NAT and because some people loves legacy NAT, there is not much commercial motivation. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 8:44 AM, Masataka Ohta wrote: Because we still have enough IPv4 addresses, because most users are happy with legacy NAT and because some people loves legacy NAT, there is not much commercial motivation. Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine transparent to mean inbound communication is possible after negotatiation with multiple levels of NAT. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Dave Hart wrote: Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). They are sane, because there is no proper support for multiple addresses (as is demonstrated by a host with a v4 and a v6 addresses) nor automatic renumbering with neither v4 nor v6. Here, v6 is guilty for lack of transparency because they are the promised features of v6. But, there are people, including me, still working on them both with v4 and v6 and we know they are not a very hard problems. You stand out as insane for attempting to redefine transparent to mean inbound communication is possible I just say it is as transparent as hosts directly connected to the Internet with port based routing such as RSIP [RFC3102] hosts: : Abstract :This document examines the general framework of Realm Specific IP :(RSIP). RSIP is intended as a alternative to NAT in which the end- :to-end integrity of packets is maintained. We focus on :implementation issues, deployment scenarios, and interaction with :other layer-three protocols. and despite IESG note on it, RSIP is transparent to IPsec if SPI is regarded as port numbers. after negotatiation with multiple levels of NAT. It will be necessary with, according to your definition, insane configuration with multiple levels of NAT. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. The problem is that you are arguing against non existing redefinitions. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
- Original Message - From: Dave Hart daveh...@gmail.com Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine transparent to mean inbound communication is possible after negotatiation with multiple levels of NAT. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. Ah, you're on the I should be required to allow direct outside connection to my interior machines if I want to be connected to the Internet crowd. Got it. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 20, 2012 at 11:05 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Dave Hart daveh...@gmail.com Sure, there are folks out there who believe NAT gives them benefits. Some are actually sane (small multihomers avoiding BGP). You stand out as insane for attempting to redefine transparent to mean inbound communication is possible after negotatiation with multiple levels of NAT. However, it does not invalidate end to end NAT as a counter argument against people insisting on IPv6 so transparent with a lot of legacy NAT used by people who loves it. That is, end to end transparency can not be a reason to insist on IPv6. It certainly is, for those of us not arguing by redefinition. Ah, you're on the I should be required to allow direct outside connection to my interior machines if I want to be connected to the Internet crowd. Not quite. I'd go for I should be able to permit direct outside connection to my interior machines via stable IPv6 prefix, or it's not really the Internet to me. Packet filter to your heart's content. 1:1 NAT your clients if you believe breaking connectivity is in your interest. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
valdis.kletni...@vt.edu wrote: And you tell the rest of the world that customer A's SMTP port is on 125, and B's is on 225, and Z's is up at 2097, how? How? In draft-ohta-e2e-nat-00.txt, I already wrote: A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. However, port numbers for DNS and SMTP are, in general, implicitly assumed by DNS and are not changeable. When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers. Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays. (HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff) As you can see, there is no such problem. (Totally overlooking the debugging issues that arise when a customer tries to run a combination of applications that in aggregate have 101 ports open..) The applications are broken, if they can't handle temporally error of EAGAIN to use the 101st port. Unlike legacy NAT, where no error can be returned for failed port allocation, end to end NAT can take care of the situation. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: Showing that you don't actually understand what everyone else means when they say end-to-end. Where is your point only to demonstrate that you don't understand whatend to end means? No carrier is going to implement that for obvious reasons. Besides, that's not transparent end-to-end, that's predictably opaque end-to-end. With no reasoning of you, I can simply say: WRONG UPnP provides information for clients to restore IP and TCP headers from local ones back to global ones, which is visible to applications. But it doesn't work across multiple layers of NAT. It is trivially easy to make UPnP works across multiple layers of UPnP capable NAT. Now, redraw the diagram for the real world scenario: host - UPnP NAT - Carrier NAT - Internet - Carrier NAT - UPnP NAT - host Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers? It is trivially: host - home UPnP NAT - Carrier UPnP NAT - Internet - Carrier UPnP NAT - home UPnP NAT - host Masataka Ohta
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: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Tue, 2012-06-19 at 22:28 +0900, Masataka Ohta wrote: It is trivially: host - home UPnP NAT - Carrier UPnP NAT - Internet - Carrier UPnP NAT - home UPnP NAT - host Trivially? I think this looks much nicer: host - Internet - host The way it used to be before NAT, and the way, with IPv6, it can be again. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 19, 2012, at 8:44 AM, Alexandru Petrescu wrote: 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). It's easy to put a 16 bit value into a 64 bit bucket. It's very hard to put a 64 bit value into a 16 bit bucket. Just saying. 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. Well, there's another issue... On such a network, how would you go about doing ND? How do you construct a solicited node multicast address for such a node if it has, say, a /108 prefix? Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer wrote: host - home UPnP NAT - Carrier UPnP NAT - Internet - Carrier UPnP NAT - home UPnP NAT - host Trivially? I think this looks much nicer: host - Internet - host Yes, if only the Internet were uniform. However, compared to V6 incapable V6 capable host - Internet- home router - Internet - 6/4 tunnel V6 capable 6/4 tunnelV6 capable end point - Internet - end point - Internet - V6 incapable home router - Internet - host which can often be: V6 incapable V6 capable host - Internet- home router - Internet - 6/4 tunnel V6 *INCAPABLE* 6/4 tunnelV6 capable end point - Internet - end point - Internet - V6 incapable home router - Internet - host host - home UPnP NAT - Carrier UPnP NAT - Internet - Carrier UPnP NAT - home UPnP NAT - host is just trivial and uniform. The way it used to be before NAT, and the way, with IPv6, it can be again. With IPv6, see above. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Tue, 19 Jun 2012 22:21:11 +0900, Masataka Ohta said: Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end For SMTP, you'll have already consumed the 3 packet handshake and the EHLO, MAIL FROM, and at least one RCPT TO before you know which end host to demultiplex to (and even then, you may not unless the end hosts are running a DNS that advertises MX's with the NAT'ed IP in them). At that point, you have little choice but to then start up a conversation with the end host and relay the EHLO/MAIL FROM/RCPT TO and hope to heck that the end host doesn't reply differently to you than you did to the other end (in particular, you had to respond to the EHLO with a list of extensions supported - if you said you supported an extension that the end system doesn't actually have, you get to do fixups on the fly as you continue the MITM). And some things, like ssh or anything that uses OpenSSL, you'll have a very hard time because you need to respond with the right certificate or key, which you don't have. hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays. So you're admitting that the NAT breaks things badly enough at the ISP level that running a forwarding ALG is easier than actually making the NAT work. (HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff) As you can see, there is no such problem. You haven't actually *deployed* your solution in a production environment, have you? pgp4hXectQN3r.pgp Description: PGP signature
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 12, 2012, at 10:47 PM, Masataka Ohta wrote: Dave Hart wrote: It is not transparent when you have to negotiate an inbound path for each service. I mean, for applications, global address and global port numbers are visible. Showing that you don't actually understand what everyone else means when they say end-to-end. UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. UPnP gateway configured with purely static port mapping needs no security. Assuming shared global address of 131.112.32.132, TCP/UDP port 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, ... No carrier is going to implement that for obvious reasons. Besides, that's not transparent end-to-end, that's predictably opaque end-to-end. When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible. UPnP provides information for clients to restore IP and TCP headers from local ones back to global ones, which is visible to applications. But it doesn't work across multiple layers of NAT. See the following protocol stack. UPnP capable NAT GW Client +-+ | public | | appli- | | cation | information +-+ +--+ for reverse translation | public | | UPnP |--|transport| +-+-+ +-+ | public | private | | private | |transport|transport| |transport| +-+-++-++-+ | public | private || private || private | | IP| IP|| IP|| IP| +-+---+---+ | privatte datalink | private datalink| +---+---+ Now, redraw the diagram for the real world scenario: host - UPnP NAT - Carrier NAT - Internet - Carrier NAT - UPnP NAT - host Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers? Yeah, thought so. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 13 Jun 2012 14:47:35 +0900, Masataka Ohta said: Dave Hart wrote: is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. UPnP gateway configured with purely static port mapping needs no security. Assuming shared global address of 131.112.32.132, TCP/UDP port 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, And you tell the rest of the world that customer A's SMTP port is on 125, and B's is on 225, and Z's is up at 2097, how? (HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff) (Totally overlooking the debugging issues that arise when a customer tries to run a combination of applications that in aggregate have 101 ports open..) pgpty9ayzmHgd.pgp Description: PGP signature
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer wrote: BTW, I'm assuming here that by multicast filtering you mean switching that properly snoops on MLD and sends multicast packets only to the correct listeners. Er, do you want to say MLD noise is not a problem? On this point I think you are wrong. Except for router advertisements, most NDP packets are sent to a solicited node multicast address, and so do NOT go to all nodes. It is the same as broadcast only in a network with switches that do not do MLD snooping. But, MLD packets must go to all routers. So I'm not sure how DAD traffic would exceed ARP traffic. I wouldn't expect it to. Nor would I - which was the point of my response to an original poster who said it might. For the original poster, : 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. MLD noise around a router is as bad as ARP/ND noise. That's how IPv6 along with SLAAC is totally broken. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Tue, 2012-06-12 at 17:16 +0900, Masataka Ohta wrote: Er, do you want to say MLD noise is not a problem? I did not say or imply that MLD noise is (or is not) a problem. I took issue with the idea that DAD traffic - the specific kind of traffic mentioned by the original poster - was likely to exceed ARP traffic. But, MLD packets must go to all routers. As I understand it, DAD is not MLD and does not itself cause any MLD traffic. The MLD that happens around the same time as DAD happens anyway, as the node adds itself to all-link-local-nodes and its own solicited-node-multicast group. Except in that DAD is NDP, and both NDP and MLD use ICMPv6 as their transport, DAD has nothing to do with MLD? You might be right that MLD is noisy, but I don't think that has anything to do with the original discussion. : 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. MLD noise around a router is as bad as ARP/ND noise. Possibly true, but that's another discussion. And is the MLD traffic as bad *everywhere* on the link, as ARP is? I strongly suspect not, because the payoff for MLD is a lessening of traffic going to all nodes. That's how IPv6 along with SLAAC is totally broken. I think we have different ideas of what constitutes totally broken. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer wrote: : 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. MLD noise around a router is as bad as ARP/ND noise. Possibly true, but that's another discussion. Then, you could have simply argued that there is no ARP problem with IPv6, because ND, not ARP, were another discussion. That's how IPv6 along with SLAAC is totally broken. I think we have different ideas of what constitutes totally broken. It is because you avoid to face the reality of MLD. Masataka Ohta
RE: IPv6 /64 links (was Re: ipv6 book recommendations?)
Masataka Ohta wrote: Karl Auer wrote: : 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. MLD noise around a router is as bad as ARP/ND noise. Possibly true, but that's another discussion. Then, you could have simply argued that there is no ARP problem with IPv6, because ND, not ARP, were another discussion. That's how IPv6 along with SLAAC is totally broken. I think we have different ideas of what constitutes totally broken. It is because you avoid to face the reality of MLD. MLD != ND MLD == IGMP ND ~= ARP ND is less overhead on end systems than ARP because it is only received by nodes that are subscribed to a specific multicast group rather than broadcast reception by all. There is no difference in L2 resolution traffic at the packet level on the network. There are multicast join messages for groups specific to ND use, but those should not be frequent, and were a specific tradeoff in minor additional network load to reduce significant end system load. There are DAD messages that impact group members, but in IPv4 there are gratuitous ARP broadcasts which impact all nodes, so while the number of messages for that function is the same, the system-wide impact is much lower. Multicast group management is inherently noisy, but a few more bits on the wire reduces the load on the significantly larger number of end systems. Get over it ... Tony
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Tony Hain wrote: It is because you avoid to face the reality of MLD. MLD != ND MLD == IGMP OK. ND ~= ARP Wrong, because ND requires MLD while ARP does not. ND is less overhead on end systems than ARP Today, overhead in time is more serious than that in processor load. As ND requires MLD and DAD, overhead in time when addresses are assigned is very large (several seconds or more if multicast is not very reliable), which is harmful especially for quicking moving mobile hosts. because it is only received by nodes that are subscribed to a specific multicast group rather than broadcast reception by all. Broadcast reception by all is good because that's how ARP can detect duplicated addresses without DAD overhead in time. Multicast group management is inherently noisy, Thus, IPv6 is inherently noisy while IPv4 is not. but a few more bits on the wire reduces the load on the significantly larger number of end systems. Get over it ... First of all, with CATENET model, there is no significantly large number of end systems in a link. Secondly, even if there are significantly large number of end systems in a link, with the end to end principle, network equipments must be dumb while end systems must be intelligent, which means MLD snooping is unnecessary and end systems must take care of themselves, violation of which results in inefficiencies and incompleteness of ND. Masataka Ohta
RE: IPv6 /64 links (was Re: ipv6 book recommendations?)
Masataka Ohta Tony Hain wrote: It is because you avoid to face the reality of MLD. MLD != ND MLD == IGMP OK. ND ~= ARP Wrong, because ND requires MLD while ARP does not. Note the ~ ... And ARP requires media level broadcast, which ND does not. Not all media support broadcast. ND is less overhead on end systems than ARP Today, overhead in time is more serious than that in processor load. As ND requires MLD and DAD, overhead in time when addresses are assigned is very large (several seconds or more if multicast is not very reliable), which is harmful especially for quicking moving mobile hosts. So leveraging broadcast is why just about every implementation does a gratuitous ARP-and-wait multiple times, which is no different than DAD timing? MLD does not need to significantly increase time for address assignment. If hosts are moving quickly the fabric needs to be able to keep up with that anyway, so adding a new multicast member needs to be fast independent of IPv6 address assignment. because it is only received by nodes that are subscribed to a specific multicast group rather than broadcast reception by all. Broadcast reception by all is good because that's how ARP can detect duplicated addresses without DAD overhead in time. BS ... Broadcasts are dropped all the time, so some nodes miss them and they need to be repeated which causes further delay. On top of that, the widespread practice of a gratuitous ARP was the precedent for the design of DAD. Multicast group management is inherently noisy, Thus, IPv6 is inherently noisy while IPv4 is not. but a few more bits on the wire reduces the load on the significantly larger number of end systems. Get over it ... First of all, with CATENET model, there is no significantly large number of end systems in a link. Clearly you have never looked at some networks with 64k nodes on a link. Not all nodes move, and not all networks are a handful of end systems per segment. Secondly, even if there are significantly large number of end systems in a link, with the end to end principle, network equipments must be dumb while end systems must be intelligent, which means MLD snooping is unnecessary and end systems must take care of themselves, violation of which results in inefficiencies and incompleteness of ND. MLD snooping was a recent addition to deal with intermediate network devices that want to insert themselves into a process that was designed to bypass them. That is not a violation of the end systems taking care of themselves, it is an efficiency issue some devices chose to assert that isn't strictly required for end-to-end operation. Just because you have never liked the design choices and tradeoffs made in developing IPv6 doesn't make them wrong. I don't know anybody that is happy with all aspects of the process, but that is also true for all the bolt-on's developed to keep IPv4 running over the last 30 years. IPv4 had its day, and it is time to move on. Continuing to complain about existing IPv6 design does nothing productive. If there are constructive suggestions to make the outcome better, take them to the IETF just like all the constructive changes made to IPv4. Tony
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Tony Hain wrote: Note the ~ ... And ARP requires media level broadcast, which ND does not. Any multicast capable link is broadcast capable. Not all media support broadcast. A fundamental misunderstanding of people designed IPv6 is that they believed ATM not broadcast capable but multicast capable. As ND requires MLD and DAD, overhead in time when addresses are assigned is very large (several seconds or more if multicast is not very reliable), which is harmful especially for quicking moving mobile hosts. So leveraging broadcast is why just about every implementation does a gratuitous ARP-and-wait multiple times, Not at all. IPv4 over something does not have to be ARP. IPv6 is broken eventually requiring all link use ND, even though ND was designed for stational hosts with only Ethernet, PPP and ATM (with a lot of misunderstanding) in mind. MLD does not need to significantly increase time for address assignment. That DAD latency is already too bad does not validate additional latency of MLD. If hosts are moving quickly the fabric needs to be able to keep up with that anyway, so adding a new multicast member needs to be fast independent of IPv6 address assignment. If only IPv6 over something were defined reflecting link specific properties. Instead, universal timing specification of ND and MLD ignoring various links in the world makes it impossible to be fast. BS ... Broadcasts are dropped all the time, On Ethernet, broadcast is as reliable as unicast. MLD snooping was a recent addition MLD snooping ~= IGMP snooping. it is an efficiency issue some devices chose to assert that isn't strictly required for end-to-end operation. There certainly are many problems, including but not limited to efficiency ones, caused by ND ignoring the end to end principle to make routers more intelligent than hosts, against which MLD snooping cloud be a half solution. But, so what? Just because you have never liked the design choices and tradeoffs made in developing IPv6 doesn't make them wrong. It is the ignorance on the end to end principle which makes IPv6 wrong. Continuing to complain about existing IPv6 design does nothing productive. Insisting on broken IPv6 design does nothing productive. If there are constructive suggestions to make the outcome better, take them to the IETF just like all the constructive changes made to IPv4. IPv6 is a proof that IETF has lost the power to make the world better. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 12, 2012, at 4:24 PM, Masataka Ohta wrote: Tony Hain wrote: Note the ~ ... And ARP requires media level broadcast, which ND does not. Any multicast capable link is broadcast capable. BZZT! but thank you for playing. Many NBMA topologies support multicast. Not all media support broadcast. A fundamental misunderstanding of people designed IPv6 is that they believed ATM not broadcast capable but multicast capable. This is, in fact, true. Yes, you can synthesize ATM broadcast-like behavior, but it is not broadcast. As ND requires MLD and DAD, overhead in time when addresses are assigned is very large (several seconds or more if multicast is not very reliable), which is harmful especially for quicking moving mobile hosts. So leveraging broadcast is why just about every implementation does a gratuitous ARP-and-wait multiple times, Not at all. IPv4 over something does not have to be ARP. IPv4 over anything requires some form of L2 address resolution in any case where L2 addresses must be discovered. IPv6 is broken eventually requiring all link use ND, even though ND was designed for stational hosts with only Ethernet, PPP and ATM (with a lot of misunderstanding) in mind. Not really. BS ... Broadcasts are dropped all the time, On Ethernet, broadcast is as reliable as unicast. BS. Just because you have never liked the design choices and tradeoffs made in developing IPv6 doesn't make them wrong. It is the ignorance on the end to end principle which makes IPv6 wrong. End-to-end is significantly more broken in IPv4 because of the need for NAT than it is in IPv6. IIRC, you were the one promoting even more borked forms of NAT to try and compensate for this. If there are constructive suggestions to make the outcome better, take them to the IETF just like all the constructive changes made to IPv4. IPv6 is a proof that IETF has lost the power to make the world better. IPv6 is quite a bit better than IPv4 in many ways. It could be better still, but, it is definitely superior to current IPv4 implementations and vastly superior to the IPv4 implementations that existed when IPv6 was designed. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: Any multicast capable link is broadcast capable. BZZT! but thank you for playing. Many NBMA topologies support multicast. When you specify a link as a small subset of NBMA, it is broadcast capable, as was demonstrated by history of CLIP. If you want to have a large (as large as broadcast is not practical) link in NBMA, multicast control messages badly implode. So leveraging broadcast is why just about every implementation does a gratuitous ARP-and-wait multiple times, Not at all. IPv4 over something does not have to be ARP. IPv4 over anything requires some form of L2 address resolution in any case where L2 addresses must be discovered. For a mobile link around a base station, during link set up, the base station and mobile hosts know MAC addresses of each other. The base station can (or, must, in case of hidden terminals) relay packets between mobile hosts attacked to it. There is no ARP nor ARP-and-wait necessary. IPv6 is broken eventually requiring all link use ND, even though ND was designed for stational hosts with only Ethernet, PPP and ATM (with a lot of misunderstanding) in mind. Not really. I know it happening within WG discussions. End-to-end is significantly more broken in IPv4 because of the need for NAT than it is in IPv6. More? So, even you think IPv6 is more or less broken. IIRC, you were the one promoting even more borked forms of NAT to try and compensate for this. I just need a UPnP capable NAT to restore the end to end transparency. IPv6 is quite a bit better than IPv4 in many ways. It could be better still, but, it is definitely superior to current IPv4 implementations and vastly superior to the IPv4 implementations that existed when IPv6 was designed. That is a commonly heard propaganda. However, these days, few believe it. Actually in this thread, your statement is proven to be untrue w.r.t. amount of noises on link bandwidth in large links. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, Jun 13, 2012 at 4:23 AM, Masataka Ohta wrote: I just need a UPnP capable NAT to restore the end to end transparency. You're not restoring transparency, you're restoring communication after stateful reconfiguration of the network for each service. It is not transparent when you have to negotiate an inbound path for each service. Even for apps that work today through local NATs, the future is dim. Increasing use of carrier NAT will force apps to additionally try Port Control Protocol to overcome evolving IPv4 brokenness. UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Dave Hart wrote: It is not transparent when you have to negotiate an inbound path for each service. I mean, for applications, global address and global port numbers are visible. UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. UPnP gateway configured with purely static port mapping needs no security. Assuming shared global address of 131.112.32.132, TCP/UDP port 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, ... When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible. UPnP provides information for clients to restore IP and TCP headers from local ones back to global ones, which is visible to applications. See the following protocol stack. UPnP capable NAT GW Client +-+ | public | | appli- | | cation | information +-+ +--+ for reverse translation | public | | UPnP |--|transport| +-+-+ +-+ | public | private | | private | |transport|transport| |transport| +-+-++-++-+ | public | private || private || private | | IP| IP|| IP|| IP| +-+---+---+ | privatte datalink | private datalink| +---+---+ Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer ka...@biplane.com.au a écrit sur 07/06/2012 06:09:46 PM : On this point I think you are wrong. Except for router advertisements, most NDP packets are sent to a solicited node multicast address, and so do NOT go to all nodes. It is the same as broadcast only in a network with switches that do not do MLD snooping. So I'm not sure how DAD traffic would exceed ARP traffic. I wouldn't expect it to. Nor would I - which was the point of my response to an original poster who said it might. Karl, Actually, your analysis seems fair for a normal broadcast network. It's true that DAD is fairly rare. RS and RAs are also part of ND though, but they shouldn't be a large part of the trafic. My comment was probably skewed by my perspective as an MSO. Docsis networks are not really broadcast in nature and the gateway (CMTS) sees all the ND trafic (ND-proxying), including DAD and RS, which can become a fair amount of trafic in some specific situations. /JF
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
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. 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: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer ka...@biplane.com.au wrote: a) DAD only happens when an IPv6 node is starting up. ARP happens whenever a node needs to talk to another node that it hasn't seen in while. DAD is a special case of ND. It happens every time the system selects an address. (i.e. startup with non-SLAAC address, and when privacy extensions generates an address.) b) DAD only goes to solicited node multicast addresses, i.e., only to those nodes that share the same last 24 bits as the target address. ARP goes to every node on the link (broadcast). This assumes a network of devices that do multicast filtering, correctly. This is not a good assumption even in large enterprises. Common residential gear usually doesn't understand multicast at all. (unless you're a uverse tv customer using ethernet and paid close attention to your hardware.) c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. Effectively the same as broadcast in the IPv6 world. If everyone is running IPv6, then everyone will see the packet. (things not running ipv6 can filter it out, but odds are it'll be put on the cable.) So I'm not sure how DAD traffic would exceed ARP traffic. I wouldn't expect it to. Looking at the output of my 3745, it fires 3 ND's at startup and is then silent. (TWC has no IPv6 on my node, but v4 ARP broadcasts amount to ~16K/s) --Ricky
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, Jun 7, 2012 at 8:42 PM, Ricky Beam jfb...@gmail.com wrote: On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer ka...@biplane.com.au wrote: c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. Effectively the same as broadcast in the IPv6 world. If everyone is running IPv6, then everyone will see the packet. (things not running ipv6 can filter it out, but odds are it'll be put on the cable.) Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 7, 2012, at 1:27 PM, Ricky Beam wrote: 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. Nope... There's also ND and the solicited node address. 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.) Modern embedded IPv6 systems in short order will have IPv6 implemented in the chip ala the Wizard W5100 chip that is very popular for IPv4 in embedded systems and micro-controllers today. 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.) While one cannot assume 64+64 on networks you don't control and CIDR is the rule for IPv6, having a common 64+64 subnet size widely deployed has a number of advantages. I am interested to hear what people are using in lieu of ND and ARP on NBMA and/or BMA multipoint IPv6 networks with netmasks longer than /64. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, 2012-06-07 at 16:42 -0400, Ricky Beam wrote: On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote: a) DAD only happens when an IPv6 node is starting up. ARP happens whenever a node needs to talk to another node that it hasn't seen in while. DAD is a special case of ND. It happens every time the system selects an address. (i.e. startup with non-SLAAC address, and when privacy extensions generates an address.) Er - OK. I should have said happens when an address is assigned to an interface. It is still, however, way less traffic than ARP, which was my point. Possible exception - a network where everyone is using privacy addresses. b) DAD only goes to solicited node multicast addresses This assumes a network of devices that do multicast filtering, correctly. Yes, it does. It assumes a properly provisioned and configured IPv6 network. While that may not be common now, it will become more common. And it is a self-correcting problem - people who don't want lots of noise will implement their networks correctly, those who don't care will do as they wish. No change there :-) BTW, I'm assuming here that by multicast filtering you mean switching that properly snoops on MLD and sends multicast packets only to the correct listeners. c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. Effectively the same as broadcast in the IPv6 world. If everyone is running IPv6, then everyone will see the packet. (things not running ipv6 can filter it out, but odds are it'll be put on the cable.) On this point I think you are wrong. Except for router advertisements, most NDP packets are sent to a solicited node multicast address, and so do NOT go to all nodes. It is the same as broadcast only in a network with switches that do not do MLD snooping. So I'm not sure how DAD traffic would exceed ARP traffic. I wouldn't expect it to. Nor would I - which was the point of my response to an original poster who said it might. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote: Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Still not quite correct :-) The filtering is done by a MLD-aware switch, which will send multicast packets only to nodes that are listening to the appropriate multicast group. The filtering you describe is pretty much what ARP does - ALL nodes receive the packet, all but one ignore it. It depends on the platform whether the CPU that does the ignoring is just in the NIC or is in the node itself. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, Jun 7, 2012 at 10:14 PM, Karl Auer ka...@biplane.com.au wrote: On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote: Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Still not quite correct :-) The filtering is done by a MLD-aware switch, which will send multicast packets only to nodes that are listening to the appropriate multicast group. The filtering you describe is pretty much what ARP does - ALL nodes receive the packet, all but one ignore it. It depends on the platform whether the CPU that does the ignoring is just in the NIC or is in the node itself. Karl, you seem to fail to understand how ethernet NICs are implemented in the real world. Ignoring the optional (but common) promiscuous mode support and various offloading, IPv4 ARP is sent as ethernet broadcast and the NIC hardware and driver is in no position to filter -- it must be done by the IP stack. In contrast, ND is sent as ethernet multicast which are filtered by receivers in hardware. Whether or not the switches are smart enough to filter is an implementation decision that has no bearing on the requirement to filter in the NIC hardware. Cheers, Dave Hart
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote: Karl, you seem to fail to understand how ethernet NICs are implemented in the real world. Ignoring the optional (but common) promiscuous mode support and various offloading, IPv4 ARP is sent as ethernet broadcast and the NIC hardware and driver is in no position to filter -- it must be done by the IP stack. In contrast, ND is sent as ethernet multicast which are filtered by receivers in hardware. Whether or not the switches are smart enough to filter is an implementation decision that has no bearing on the requirement to filter in the NIC hardware. I'm the first to admit that I often don't know stuff. One good reason to be on the NANOG mailing list! But in this case... Yes - whether with ARP or ND, any node has to filter out the packets that do not apply to it (whether it's done by the NIC or the host CPU is another question, not relevant here). But in a properly switched IPv6 network, many/most ND packets do not arrive at most nodes' network interfaces at all, so those nodes have no filtering work to do. Yes, the nodes that DO get a packet - those listening on the relevant multicast group, often a solicited node multicast group - DO need to filter out the NDs that don't apply to them, but the point is that a vastly reduced number of nodes are thus inconvenienced compared. The original post posited that ND could cause as much traffic as ARP. My point is that it probably doesn't, because the ND packets will only be seen on the specific switch ports belonging to those nodes that are listening to the relevant multicast groups, and only those nodes will actually receive the ND packets. In contrast to ARP, which is broadcast, always, to all nodes, and thus goes out every switch port in the broadcast domain. This is pretty much the *point* of using multicast instead of broadcast. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
In message 1339116492.2754.162.camel@karl, Karl Auer writes: --=-ebOzahzuucm9tstf70zM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote: Karl, you seem to fail to understand how ethernet NICs are implemented in the real world. Ignoring the optional (but common) promiscuous mode support and various offloading, IPv4 ARP is sent as ethernet broadcast and the NIC hardware and driver is in no position to filter -- it must be done by the IP stack. In contrast, ND is sent as ethernet multicast which are filtered by receivers in hardware. Whether or not the switches are smart enough to filter is an implementation decision that has no bearing on the requirement to filter in the NIC hardware. I'm the first to admit that I often don't know stuff. One good reason to be on the NANOG mailing list! But in this case... Yes - whether with ARP or ND, any node has to filter out the packets that do not apply to it (whether it's done by the NIC or the host CPU is another question, not relevant here). But in a properly switched IPv6 network, many/most ND packets do not arrive at most nodes' network interfaces at all, so those nodes have no filtering work to do. Yes, the nodes that DO get a packet - those listening on the relevant multicast group, often a solicited node multicast group - DO need to filter out the NDs that don't apply to them, but the point is that a vastly reduced number of nodes are thus inconvenienced compared. The original post posited that ND could cause as much traffic as ARP. My point is that it probably doesn't, because the ND packets will only be seen on the specific switch ports belonging to those nodes that are listening to the relevant multicast groups, and only those nodes will actually receive the ND packets. In contrast to ARP, which is broadcast, always, to all nodes, and thus goes out every switch port in the broadcast domain. This is pretty much the *point* of using multicast instead of broadcast. The point of multicast is be able to reject traffic sooner rather than later. Running IPv6 with a nic that doesn't support several multicast addresses is a real pain which I know from experience. It can however be done. Regards, K. --=20 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 2012-06-08 at 11:08 +1000, Mark Andrews wrote: This is pretty much the *point* of using multicast instead of broadcast. The point of multicast is be able to reject traffic sooner rather than later. Well - yes - and my description was of how, when properly configured and on the right hardware, unwanted multicast IPv6 packets do not even reach the NIC. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, Jun 8, 2012 at 12:48 AM, Karl Auer ka...@biplane.com.au wrote: Yes - whether with ARP or ND, any node has to filter out the packets that do not apply to it (whether it's done by the NIC or the host CPU is another question, not relevant here). It is relevant to the question of the scalability of large L2 networks. With IPv4, ARP presents not only a network capacity issue, but also a host capacity issue as every node expends software resources processing every broadcast ARP. With ND, only a tiny fraction of hosts expend any software capacity processing a given multicast packet, thanks to ethernet NIC's hardware filtering of received multicasts -- with or without multicast-snooping switches. The original post posited that ND could cause as much traffic as ARP. My point is that it probably doesn't, because the ND packets will only be seen on the specific switch ports belonging to those nodes that are listening to the relevant multicast groups, and only those nodes will actually receive the ND packets. In contrast to ARP, which is broadcast, always, to all nodes, and thus goes out every switch port in the broadcast domain. This is pretty much the *point* of using multicast instead of broadcast. I agree.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 2012-06-08 at 03:08 +, Dave Hart wrote: networks. With IPv4, ARP presents not only a network capacity issue, but also a host capacity issue as every node expends software resources processing every broadcast ARP. With ND, only a tiny fraction of hosts expend any software capacity processing a given multicast packet, thanks to ethernet NIC's hardware filtering of received multicasts -- with or without multicast-snooping switches. So we are actually sort of agreeing. That's a relief :-) However, preventing packets getting to the NICs *at all* is a pretty big win, because even if a clever NIC can prevent a host CPU being interrupted, the packet was still wasting bandwidth on the path to the NIC. I would go so far as to say that MLD snooping makes the NIC side of things almost irrelevant. Almost :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
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?)
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?)
Thus spake Chuck Church (chuckchu...@gmail.com) on Wed, Jun 06, 2012 at 10:58:05AM -0400: Does anyone know the reason /64 was proposed as the size for all L2 domains? Some day eui-48 will run out. So, just assume eui-64 now and map into it. Also, as you point out below, not all L2 is ethernet. 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? A good history lesson for this addressing model would be to look at IPX. (And maybe also IRDP for ipv4). When we did our first trial ipv6 deployments here in the early 2000's we were still running IPX, so I guess SLAAC wasn't hard to grasp. Dale
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
It is because of IEEE EUI-64 standard. It was believed at the time of IPv6 development that EUI-48 would run out of numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't quite made that change (though Firewire does appear to use EUI-64 already), it will likely occur prior to the EOL for IPv6. There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 space. The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps it as follows: let AA = XX xor 0x02. AAYY:ZZff:feRR:SSTT ff:fe above is literal. IPv6 was originally going to be a 32-bit address space, but, the developers and proponent of SLAAC convinced IETF to add 64 more bits to the IPv6 address for this purpose. Since bits are free when designing a new protocol, there really was no reason to impose such limitations. You really don't gain anything by going to /80 at this point. There are more than enough addresses available in IPv6 for any foreseeable future even with /64 subnets. Owen On Jun 6, 2012, at 7:58 AM, Chuck Church wrote: 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?)
On 06/06/2012 03:05 PM, Owen DeLong wrote: It is because of IEEE EUI-64 standard. It was believed at the time of IPv6 development that EUI-48 would run out of numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't quite made that change (though Firewire does appear to use EUI-64 already), it will likely occur prior to the EOL for IPv6. There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 space. The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps it as follows: let AA = XX xor 0x02. AAYY:ZZff:feRR:SSTT ff:fe above is literal. IPv6 was originally going to be a 32-bit address space, but, the developers did you mean originally going to be a 64-bit address space... and proponent of SLAAC convinced IETF to add 64 more bits to the IPv6 address for this purpose. Since bits are free when designing a new protocol, there really was no reason to impose such limitations. You really don't gain anything by going to /80 at this point. There are more than enough addresses available in IPv6 for any foreseeable future even with /64 subnets. Owen On Jun 6, 2012, at 7:58 AM, Chuck Church wrote: 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 Smithan...@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 -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 6, 2012, at 1:02 PM, Steve Clark wrote: On 06/06/2012 03:05 PM, Owen DeLong wrote: It is because of IEEE EUI-64 standard. It was believed at the time of IPv6 development that EUI-48 would run out of numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't quite made that change (though Firewire does appear to use EUI-64 already), it will likely occur prior to the EOL for IPv6. There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 space. The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps it as follows: let AA = XX xor 0x02. AAYY:ZZff:feRR:SSTT ff:fe above is literal. IPv6 was originally going to be a 32-bit address space, but, the developers did you mean originally going to be a 64-bit address space... Uh, yeah... Sorry... Brain fart. Originally a 64-bit address space. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: It is because of IEEE EUI-64 standard. Right, so far. It was believed at the time of IPv6 development that EUI-48 would run out of numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't quite made that change (though Firewire does appear to use EUI-64 already), it will likely occur prior to the EOL for IPv6. Wrong. It is because I pointed out that IEEE1394 already use EUI-64. Since bits are free when designing a new protocol, there really was no reason to impose such limitations. Bits are not free. Remembering a 64 bit value human, a 128 bit value divine, which makes IPv6 network operation hard. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 2012-06-06 at 10:35 -0400, jean-francois.tremblay...@videotron.com wrote: 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. That doesn't sound right to me. a) DAD only happens when an IPv6 node is starting up. ARP happens whenever a node needs to talk to another node that it hasn't seen in while. b) DAD only goes to solicited node multicast addresses, i.e., only to those nodes that share the same last 24 bits as the target address. ARP goes to every node on the link (broadcast). c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. So I'm not sure how DAD traffic would exceed ARP traffic. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
