Re: IPv6 Pain Experiment
Owen DeLong wrote: As a result, you are properly rewarded to make a fool of yourself in public. If I have, it certainly won’t be the first time. Enjoy it, if you can. PERIOD. Masataka Ohta
Re: IPv6 Pain Experiment
> On Oct 9, 2019, at 15:10 , Masataka Ohta > wrote: > > Owen DeLong wrote: > > >> It is merely that you don't understand ICMP at all. > > > Really, it's not, but I know you like to feel smug and > > superior, so enjoy that. > > Are you saying you are so great that only the greatest can > be superior to you, which must be enjoyable? > Not at all… But please, as usual, do not let your failure to properly interpret what I said interfere with the conclusions you choose to draw. > Then, you are wrong. Were that what I was saying, I probably would be wrong. Since it bears so little resemblance to what I actually said, I think it is safe to say that your interpretation is in error here. >>> You should really feel indebted to me because it's not a pleasure >>> for me to answer questions having no valid points. >> Rest assured that I will not feel slighted in any way if you were to >> stop doing so. Please feel free to stop at any time. > > If only you have humbly asked properly targeted question as: > > > Explain that to ICMP ECHO packets. > > you could have been answered properly. Echo was one example. It is not the only one. There are other ICMP packets which do not necessarily contain information about some other TCP or UDP datagram as well. I did ask a property targeted question. The fact that you failed to consider a properly scoped variety of possibilities is not my fault. > Instead, you intentionally vaguely asked: > > > Explain that to ICMP packets. > > trying to trick me with your poor understanding on ICMP and UDP. I wasn’t trying to trick anyone. I was making a snide comment about your failure to consider the much broader implications of your erroneous assumptions. I did not actually expect a reply. Please note that your interpretation of it as a question shows the extent of your error in that it was a statement and not a question, thus ending with a period (.) and not a question mark (?). Perhaps if I say “note the absence of the word ka at the end of my original statement” that will fit into your brain better. > As a result, you are properly rewarded to make a fool of > yourself in public. If I have, it certainly won’t be the first time. However, I think from what I have seen in comments by others both on and off list that is not really the case outside of your mind. Owen
Re: IPv6 Pain Experiment
Owen DeLong wrote: >> It is merely that you don't understand ICMP at all. > Really, it's not, but I know you like to feel smug and > superior, so enjoy that. Are you saying you are so great that only the greatest can be superior to you, which must be enjoyable? Then, you are wrong. You should really feel indebted to me because it's not a pleasure for me to answer questions having no valid points. Rest assured that I will not feel slighted in any way if you were to stop doing so. Please feel free to stop at any time. If only you have humbly asked properly targeted question as: > Explain that to ICMP ECHO packets. you could have been answered properly. Instead, you intentionally vaguely asked: > Explain that to ICMP packets. trying to trick me with your poor understanding on ICMP and UDP. As a result, you are properly rewarded to make a fool of yourself in public. Masataka Ohta
Re: IPv6 Pain Experiment
On Tue, Oct 8, 2019 at 12:38 PM wrote: > On October 8, 2019 at 12:04 b...@herrin.us (William Herrin) wrote: > > On Tue, Oct 8, 2019 at 12:01 PM wrote: > > My main point is, as I said, Bits is Bits, whether they're human > > readable (for some value of "human") like URLs or long hex strings > > which perhaps are less human readable. > > > > Bits aren't just bits. Bits with useful properties (such as aggregability which > > coincides with the routing structure) are better bits. > > Yet somehow we manage to start with URLs (for example.) URLs have lots of useful properties. None of them facilitate network routing but they facilitate lots of other useful stuff. > My point is whatever is used it can be mapped to something perhaps > more efficient given some design goals, such as the DNS does. And for > that matter route lookup tables w/in routers. Mapped by who? The genius of the Internet's design lies in its answer to that question: the end to end principle. The end to end principle says that the endpoints (not middleboxes) should resolve those mappings so that the middleboxes need not manage abstractions. Packet switching is just fancy statistical multiplexing of a circuit-switched network... until you remove stateful management of the connections from the data path and keep it on the endpoints. Then it's more. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
> On Oct 9, 2019, at 12:08 , b...@theworld.com wrote: > > > On October 8, 2019 at 23:51 o...@delong.com (Owen DeLong) wrote: > (responding to my P.S.) > >>P.S. My prediction? >> >>The world's major telcos et al, having had enough of various problems, >>from address exhaustion to non-stop security disasters, and the >>chaotic responses, propose and begin implementing an alternative. And >>that won't be through the IETF or similar. >> >> >> I tend to doubt it. >> >> While I don’t discount what you say about telcos below, the thing to remember >> is that insisted that VOIP would never displace TDM in the average >> enterprise. >> >> When was the last time you saw a business phone system using TDM and not >> IP phones? > > Sorry, I was referring to telcos as the major so-called "tier 1" and > long line providers, the cell phone service providers (along with the > likes of comcast but there aren't many like that), and in many > countries the monopoly providers of the whole, pardon the expression, > cloud of comm services, rather than their voice function which has > largely become just another app. I wasn’t talking about voice specifically either, other than to cite it as an example proving that they don’t always guess or bet right, even with the big capitalization and government embedded infrastructure. > First they (the collective group I describe) honestly believe they can > manage large-scale engineering projects w/o the help of a lot of > volunteers beyond /fait accompli/ -- please stamp this new technology > we collectively have agreed to as a "standard". Compare and contrast > 5G for example. Yeah, it’s going to be very interesting to watch whether 5G turns into anything beyond an incredible money sink. > Second are the liability issues. They may generally manage to escape > direct liability e.g. for business damage due to address exhaustion or > security problems etc but insurance companies, banks, et al, can't and > those are big players with sway over the "telcos" to do something > about services they are paying collectively many billions per month > for and incurring damages from. No question there are interesting times ahead. Owen
Re: IPv6 Pain Experiment
On October 8, 2019 at 23:51 o...@delong.com (Owen DeLong) wrote: (responding to my P.S.) > P.S. My prediction? > > The world's major telcos et al, having had enough of various problems, > from address exhaustion to non-stop security disasters, and the > chaotic responses, propose and begin implementing an alternative. And > that won't be through the IETF or similar. > > > I tend to doubt it. > > While I don’t discount what you say about telcos below, the thing to remember > is that insisted that VOIP would never displace TDM in the average > enterprise. > > When was the last time you saw a business phone system using TDM and not > IP phones? Sorry, I was referring to telcos as the major so-called "tier 1" and long line providers, the cell phone service providers (along with the likes of comcast but there aren't many like that), and in many countries the monopoly providers of the whole, pardon the expression, cloud of comm services, rather than their voice function which has largely become just another app. The big capitalization and generally government embedded infrastructure players. The problem is two-fold. First they (the collective group I describe) honestly believe they can manage large-scale engineering projects w/o the help of a lot of volunteers beyond /fait accompli/ -- please stamp this new technology we collectively have agreed to as a "standard". Compare and contrast 5G for example. Second are the liability issues. They may generally manage to escape direct liability e.g. for business damage due to address exhaustion or security problems etc but insurance companies, banks, et al, can't and those are big players with sway over the "telcos" to do something about services they are paying collectively many billions per month for and incurring damages from. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
>> You’re selecting a very limited subset of ICMP that happens to >> contain a portion of a packet that happens to contain a port >> number (or two). > > It is merely that you don't understand ICMP at all. Really, it’s not, but I know you like to feel smug and superior, so enjoy that. > See above. The context is TCP. Now there is no context. Previously, there was both a UDP and TCP context and you only addressed TCP as if UDP was irrelevant. > You don't understand UDP, either, at all. Actually, I understand it quite well. >>> That's very elementary explanations on ICMP and UDP. >> Yes, thanks for yet another condescending comment proving that >> you completely missed the point of my post. It's always a pleasure. > > You should really feel indebted to me because it's not a pleasure > for me to answer questions having no valid points. Rest assured that I will not feel slighted in any way if you were to stop doing so. Please feel free to stop at any time. Owen
Re: IPv6 Pain Experiment
On Wed, 09 Oct 2019 18:51:12 +0900, Masataka Ohta said: > Owen DeLong wrote: > > Yes, thanks for yet another condescending comment proving that > > you completely missed the point of my post. It's always a pleasure. > You should really feel indebted to me because it's not a pleasure > for me to answer questions having no valid points. Of course, if you missed the point, by definition you won't find any valid points. And yes, you *did* totally miss Owen's point, which was that not all ICMP packets contain port information. As another data point, enough IP options will push some or all of TCP or UDP header information out of the returned data. pgpQ1aD4sHRPq.pgp Description: PGP signature
Re: IPv6 Pain Experiment
Owen DeLong wrote: Why do you think ICMP any different? Just as usual IP packets, inner IP packets contained in ICMPv4 error packets contain port numbers just after IP headers. Show me the port number in a type 8 or type 0 packet. First 8 bytes of data field can be used as 4 byte source and destination port numbers. As I wrote: > which is obviously fully operational with existing IPv4 backbone, we don't need the field interpreted by routers in existing IPv4 backbone. traceroute with ICMP ECHO works with identifier and sequence number. After the packet reaches a TCPng/UDPng aware NAT/A+P gateway, we can expect the field is interpreted as port numbers by the gateway, A+P routers beyond the gateway and the destination. You’re selecting a very limited subset of ICMP that happens to contain a portion of a packet that happens to contain a port number (or two). It is merely that you don't understand ICMP at all. The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking. And UDP? Applications over UDP may or may not confirm by 3 way handshaking or some other mechanism. That's UDP. Yes, but the context in which you proposed this as a be-all See above. The context is TCP. end-all solution doesn't allow for the existing things that brea when you make the assumptions you've obviously made. You don't understand UDP, either, at all. In case of UDP, the assumption is made by someone who designed application protocol over UDP. If the designer decided the confirmation is not necessary, the confirmation is not necessary and protocol is designed so. If the designer decided the confirmation is necessary, the confirmation is necessary and protocol is designed so. There is nothing I can or should do for the decision. That's very elementary explanations on ICMP and UDP. Yes, thanks for yet another condescending comment proving that you completely missed the point of my post. It's always a pleasure. You should really feel indebted to me because it's not a pleasure for me to answer questions having no valid points. Masataka Ohta
Re: IPv6 Pain Experiment
>> I’m betting that not all of the WWW addresses go to the same ASN. > > Perhaps you have noticed in your vast travels that domain names' > significance is generally read right to left not left to right like IP > addresses? Sure, but I’m betting that trying to aggregate routing around COM. would be just as tricky as trying to aggregate it around WWW. > P.S. My prediction? > > The world's major telcos et al, having had enough of various problems, > from address exhaustion to non-stop security disasters, and the > chaotic responses, propose and begin implementing an alternative. And > that won't be through the IETF or similar. I tend to doubt it. While I don’t discount what you say about telcos below, the thing to remember is that insisted that VOIP would never displace TDM in the average enterprise. When was the last time you saw a business phone system using TDM and not IP phones? Owen
Re: IPv6 Pain Experiment
> On Oct 8, 2019, at 09:48 , Michel Py wrote: > >> Owen DeLong wrote : >> I’m not sure how giving them DNS names makes them less resilient to DNS >> failures. > > How do you resolve the IP address of the PBX ? I hard-code (in the master > config). Usually, i have sufficiently resilient DNS that I use it. If I’m in an environment where hard-coding is required, I generally have software that is building the config file rather than doing it by hand. The config generation software can depend on DNS, even if the phone may not be able to in all runtimes. > The PBX does not have a DNS name. I want my support staff to know its IP on > the top of their head. Then make it something easy like prefix::5 and move on. Even if you’ve got a /48 like 2620:5af2:3ace::/48, you can use the first prefix for your PBX and then it’s just 2620:5af2:3ace::5/64. While that’s a little worse than IPv4 for remembering the prefix (3 4-digit numbers instead of 3 3-digit numbers), that prefix will be readily visible on any device that’s able to utilize the same network, so it’s not hard to look up and it’ s only 3 extra digits of typing and 1 extra separator mark. > DNS failures do not happen often, but they do happen. Fat fingers change or > delete the entry, the zone gets corrupted or partially corrupted, that kind > of stuff. If you’re pushing DNS edit -> Production, I suppose that’s true. If it matters that much, I usually have Edit->Staging->validation scripts->production. If the staging environment can’t resolve the critical infrastructure items (such as PBX), then it doesn’t change production. > There are things that redundant hardware and network will not solve. If the > PBX address becomes unresolvable, the SIP registrations will timeout and I'm > going to lose phones. Sure, but it should have a very long TTL and shouldn’t become unresolvable in less time than it takes you to identify and solve the DNS problem. > Granted, it would not take that much time to troubleshoot, but just the > possibility, not matter how remote, that it could happen makes it a > non-option. In which case, I’d definitely set up validation before shipping on my DNS updates. > If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but > it is resilient. Uh, only if the PBX is on the same segment as every phone. (does not scale unless you buy a PBX for each phone segment). And the fe80:: alternative is SO MUCH more elegant than 169.254… Just sayin’ Owen
Re: IPv6 Pain Experiment
> On Oct 8, 2019, at 02:29 , Masataka Ohta > wrote: > > Owen DeLong wrote: > >>> Separation between address and port is vague. >> Explain that to ICMP packets. > > Why do you think ICMP any different? > > Just as usual IP packets, inner IP packets contained in > ICMPv4 error packets contain port numbers just after IP headers. Show me the port number in a type 8 or type 0 packet. > Moreover, unlike stupid ICMPv6, ICMPv4 error packets are > guaranteed to contain 8B of inner packet payload (enough > for 32 bit port number) after IP header. You’re selecting a very limited subset of ICMP that happens to contain a portion of a packet that happens to contain a port number (or two). > If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name), >>> >>> The point of TCP use IP address for identification is hosts >>> can confirm IP address is true by 3 way handshaking. >> And UDP? > > Applications over UDP may or may not confirm by 3 way > handshaking or some other mechanism. > > That's UDP. Yes, but the context in which you proposed this as a be-all end-all solution doesn’t allow for the existing things that brea when you make the assumptions you’ve obviously made. > That's very elementary explanations on ICMP and UDP. Yes, thanks for yet another condescending comment proving that you completely missed the point of my post. It’s always a pleasure. Owen
Re: IPv6 Pain Experiment
Nicholas Warren wrote: It's not 1990 any more, a TB of RAM now costs a few thousand dollars Maybe. and is dropping rapidly (similar for fancy router RAM), Definitely not. It's not 2010 any more. Masataka Ohta
Re: IPv6 Pain Experiment
William Herrin wrote: The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking. Yeah, but that touches one of the central flaws of the design of IP, v4 and v6. We are talking about design of TCP, not IP. No part of identifying and authenticating communication should reside at layer 3. That's why we have port numbers for TCP, though you may call something equivalent to them SPIs for IPsec. The IP address shouldn't identify anything. It should reflect only the host's current position in the network. You are saying IP address should identify current position in the network. The address should be as ephemerally attached to the endpoint as the layer 2 MAC address and as quickly changeable. Without disrupting upper layer communication. It would be a crying shame to replace the layer 4 protocols without doing something about that flaw. Just say "IP mobility". And it's layer 3 issue. I actually came up with a solution to BGP scalability. If you abandon stability of the layer 3 address, just throw it out the window, it turns out to be relatively easy to build a routing protocol which constructs ephemeral address hierarchies that represent the current state of connections in the network even though the physical network itself is still a general graph. The ephemeral hierarchies aggregate well reducing the worldwide routing table to a few tens of thousands of routes. Then, you need two sets of IP addresses, one for physical network another for virtual network. Former needs large routing table. With IP mobility, the latter needs no routing table or BGP. Only to replace well known port numbers by well known connection IDs and port scanning by connection ID scanning? Easy to make this impractical. QUIC has. It can be made so by sparsely populated port number space. So, when all what needed are more bits for address and port, don't try to put all the complicated features someone might have thought useful. Masataka Ohta
Re: IPv6 Pain Experiment
On October 8, 2019 at 19:12 nwar...@barryelectric.com (Nicholas Warren) wrote: > Sweet deals, would you kindly share your vendor? > > > It's not 1990 any more, a TB of RAM now costs a few thousand dollars > and is dropping rapidly (similar for fancy router RAM), we have > processor chips with 64 cores available practically off the shelf for > under $10K (32-core literally off the shelf, try any Microcenter), > etc. etc. etc. https://www.amazon.com/Corsair-Vengeance-128GB-3000MHz-Memory/dp/B019X5RN84 128GB DDR4 3000MHZ, $614.99, 8x (for 1TB) $5534.91 https://www.newegg.com/p/N82E16819113581?item=N82E16819113581=region_mc=knc-googleadwords-pc_mmc=knc-googleadwords-pc-_-pla-_-processors+-+server-_-N82E16819113581=CjwKCAjw5_DsBRBPEiwAIEDRW9nFdIuUnfGyEWeXuDb77ndDA-phHT2-eUYIHkFNiPoOzzQ7cwgoLxoC1WMQAvD_BwE=aw.ds Newegg, 64-core, AMD/EPYC, $7522. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
On October 8, 2019 at 12:04 b...@herrin.us (William Herrin) wrote: > On Tue, Oct 8, 2019 at 12:01 PM wrote: > > My main point is, as I said, Bits is Bits, whether they're human > readable (for some value of "human") like URLs or long hex strings > which perhaps are less human readable. > > > Bits aren't just bits. Bits with useful properties (such as aggregability > which > coincides with the routing structure) are better bits. Yet somehow we manage to start with URLs (for example.) My point is whatever is used it can be mapped to something perhaps more efficient given some design goals, such as the DNS does. And for that matter route lookup tables w/in routers. So at the end of the day all that is absolutely needed is (reasonable) unambiguity because in general ambiguity can't be fixed, the packet has to go somewhere. Different schemes might present different design opportunities but they all need to be unambiguous as routing endpoints. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
On Tue, 08 Oct 2019 19:12:30 -, Nicholas Warren said: > Sweet deals, would you kindly share your vendor? Well, I just type "128G DIMM" into google, and the very first hit tells me that I can get a 128G DIMM for $1,398, that and 8 DiMM slots gets me to 1T just over $11K. If I have 16 DIMM slots like a decent server-class board should have, I can do 64G cards for $308 and I'm done for under $5k. I didn't dig further, because I already had evidence to support the claim: > It's not 1990 any more, a TB of RAM now costs a few thousand dollars > and is dropping rapidly (similar for fancy router RAM) > processor chips with 64 cores available practically off the shelf for > under $10K (32-core literally off the shelf, try any Microcenter), AMD 32-core Ryzen Threadripper is $1,799. Find a 2-socket motherboard and you're at 64 cores for well under $5K for the chipsets. https://www.newegg.com/amd-ryzen-threadripper-2990wx/p/N82E16819113541 pgphvPywfuB9w.pgp Description: PGP signature
Re: IPv6 Pain Experiment
Sweet deals, would you kindly share your vendor? It's not 1990 any more, a TB of RAM now costs a few thousand dollars and is dropping rapidly (similar for fancy router RAM), we have processor chips with 64 cores available practically off the shelf for under $10K (32-core literally off the shelf, try any Microcenter), etc. etc. etc.
Re: IPv6 Pain Experiment
On Tue, Oct 8, 2019 at 12:01 PM wrote: > My main point is, as I said, Bits is Bits, whether they're human > readable (for some value of "human") like URLs or long hex strings > which perhaps are less human readable. > Bits aren't just bits. Bits with useful properties (such as aggregability which coincides with the routing structure) are better bits. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
On Mon, Oct 7, 2019 at 11:59 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > William Herrin wrote: > > If we're going to replace TCP and UDP, initiate > > the link with a name (e.g. dns name), > > The point of TCP use IP address for identification is hosts > can confirm IP address is true by 3 way handshaking. Yeah, but that touches one of the central flaws of the design of IP, v4 and v6. No part of identifying and authenticating communication should reside at layer 3. The IP address shouldn't identify anything. It should reflect only the host's current position in the network. The address should be as ephemerally attached to the endpoint as the layer 2 MAC address and as quickly changeable. Without disrupting upper layer communication. It would be a crying shame to replace the layer 4 protocols without doing something about that flaw. I actually came up with a solution to BGP scalability. If you abandon stability of the layer 3 address, just throw it out the window, it turns out to be relatively easy to build a routing protocol which constructs ephemeral address hierarchies that represent the current state of connections in the network even though the physical network itself is still a general graph. The ephemeral hierarchies aggregate well reducing the worldwide routing table to a few tens of thousands of routes. > Only to replace well known port numbers by well known connection > IDs and port scanning by connection ID scanning? Easy to make this impractical. QUIC has. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
On October 7, 2019 at 23:13 o...@delong.com (Owen DeLong) wrote: > > > > On Oct 7, 2019, at 20:16 , b...@theworld.com wrote: > > > > > > Well if you all really want your heads to explode I was invited to > > give a talk a few years ago in Singapore at the local HackerSpace. > > > > It called for something creative and different, not really an IETF > > sort of crowd. > > > > So I proposed we dump numeric addresses entirely and use basically > > URLs in IP packets and elsewhere. > > > > I really meant something like 'IP://www.TheWorld.com' in the > > source/dest addr, possibly more specific for multiple interfaces but > > whatevs. > > It doesn’t break my brain, but it really doesn’t make a lot of sense when > you get down to it. No, doesn't break your brain, but then you proceed to look at an electric car and protest "but where do you put the gasoline?!" (i.e., describe current routing architecture.) Yes, Owen, given my admittedly off-beat (isn't that how I introduced it?) proposal some things would have to change, as I said in the note you were responding to, more than once. >There’s also the issue that prefixes of that address format don’t tend to >aggregate well. > >I’m betting that not all of the WWW addresses go to the same ASN. Perhaps you have noticed in your vast travels that domain names' significance is generally read right to left not left to right like IP addresses? I did finish with: > I'd agree the idea is several RFCs short of an internet but hey it's > something to think about. My main point is, as I said, Bits is Bits, whether they're human readable (for some value of "human") like URLs or long hex strings which perhaps are less human readable. The only non-negotiable criteria is whether a given bitstring choice is sufficiently unique to indicate routing endpoints. It's not 1990 any more, a TB of RAM now costs a few thousand dollars and is dropping rapidly (similar for fancy router RAM), we have processor chips with 64 cores available practically off the shelf for under $10K (32-core literally off the shelf, try any Microcenter), etc. etc. etc. It might be reasonable to think about how we might take advantage of what we've learned in 30 years, particularly starting with the premise that IPv6 adoption isn't doing very well. Perhaps we can do better. I'm not quite sure the knee-jerk reaction "but we're neck deep in the big muddy, we must continue forward! look at how long and how much trouble it took us to get even neck deep!" should be dispositive. P.S. My prediction? The world's major telcos et al, having had enough of various problems, from address exhaustion to non-stop security disasters, and the chaotic responses, propose and begin implementing an alternative. And that won't be through the IETF or similar. Something I have learned about telcos and other vast business and govt enterprises is they are willing to sit back, for decades if necessary, and watch the pioneers break sod, find and grow the markets, take the hits, fight range wars among themselves, etc. And only then when what can be gained, and how, becomes clear they move in with their vast capitalization and organizational skills. "...now we stand outcast and starving 'mid the wonders we have made", old union song. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
RE: IPv6 Pain Experiment
On October 8, 2019 at 03:00 michel...@tsisemi.com (Michel Py) wrote: > > Owen DeLong wrote : > > Well… I don’t run into this very often any more, but I guess if you have a > > poorly run DNS environment, it might be more of an issue. > > About half of my devices, including all the VOIP phones, do not have DNS. I > just cannot afford to lose the phones if there is a DNS failure. They have > DHCP, but not DNS. Considering the audience here configuration, maintenance, and repair might involve entering numeric IP addresses. Not the average user? I don't know, define average, how many tens of millions of sites out there have more than just edge routers? How many have adequate educational and reference materials in their native language? etc. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
RE: IPv6 Pain Experiment
> Owen DeLong wrote : > I’m not sure how giving them DNS names makes them less resilient to DNS > failures. How do you resolve the IP address of the PBX ? I hard-code (in the master config). The PBX does not have a DNS name. I want my support staff to know its IP on the top of their head. DNS failures do not happen often, but they do happen. Fat fingers change or delete the entry, the zone gets corrupted or partially corrupted, that kind of stuff. There are things that redundant hardware and network will not solve. If the PBX address becomes unresolvable, the SIP registrations will timeout and I'm going to lose phones. Granted, it would not take that much time to troubleshoot, but just the possibility, not matter how remote, that it could happen makes it a non-option. If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but it is resilient. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
Owen DeLong wrote: Separation between address and port is vague. Explain that to ICMP packets. Why do you think ICMP any different? Just as usual IP packets, inner IP packets contained in ICMPv4 error packets contain port numbers just after IP headers. Moreover, unlike stupid ICMPv6, ICMPv4 error packets are guaranteed to contain 8B of inner packet payload (enough for 32 bit port number) after IP header. If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name), The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking. And UDP? Applications over UDP may or may not confirm by 3 way handshaking or some other mechanism. That's UDP. That's very elementary explanations on ICMP and UDP. Masataka Ohta
Re: IPv6 Pain Experiment
> On Oct 7, 2019, at 23:59 , Masataka Ohta > wrote: > > William Herrin wrote: > >>> I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, >>> which is obviously fully operational with existing IPv4 backbone, is >>> better. > >> Not a fan of port numbers. > > Separation between address and port is vague. Explain that to ICMP packets. > >> If we're going to replace TCP and UDP, initiate >> the link with a name (e.g. dns name), > > The point of TCP use IP address for identification is hosts > can confirm IP address is true by 3 way handshaking. And UDP? Owen
Re: IPv6 Pain Experiment
William Herrin wrote: I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, which is obviously fully operational with existing IPv4 backbone, is better. Not a fan of port numbers. Separation between address and port is vague. If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name), The point of TCP use IP address for identification is hosts can confirm IP address is true by 3 way handshaking. negotiate a connection ID and continue with the connection ID. No ports, no port scanning. Only to replace well known port numbers by well known connection IDs and port scanning by connection ID scanning? > QUIC comes pretty close to getting it right. It's another second system syndrome. Keep using TCP/UDP as is except for port number length. Masataka Ohta
Re: IPv6 Pain Experiment
> On Oct 7, 2019, at 20:16 , b...@theworld.com wrote: > > > Well if you all really want your heads to explode I was invited to > give a talk a few years ago in Singapore at the local HackerSpace. > > It called for something creative and different, not really an IETF > sort of crowd. > > So I proposed we dump numeric addresses entirely and use basically > URLs in IP packets and elsewhere. > > I really meant something like 'IP://www.TheWorld.com' in the > source/dest addr, possibly more specific for multiple interfaces but > whatevs. It doesn’t break my brain, but it really doesn’t make a lot of sense when you get down to it. You’re basically producing a numeric address that is limited in character scope is all. An octet can represent 8 bits of a binary address, period. It’s up to you whether you display that to the human as ASCII characters (limited printable selection), Unicode (even more overhead and wastage), numeric (current practice and zero waste in hex form), or otherwise. > Leave out the implied 'IP://' and my example is 16 chars just like > IPv6. Yeah, but it doesn’t tell the whole story because the domain name needs to map (in some cases) to multiple on-the-wire addresses so you’re either going to have mass confusion in that you’e got service names and service addresses that look like names underneath that aren’t actually names, or, you’re going to be back to having addresses that could look like names, but don’t for sanity’s sake and then you’re back to unreadable addresses. > Routers could of course do what they like with those internally such > as maintain a hash table to speed look-ups. Not anyone outside of > router software developers' problem. There’s also the issue that prefixes of that address format don’t tend to aggregate well. I’m betting that not all of the WWW addresses go to the same ASN. > If one agreed on a standard hash algorithm further performance > improvements could be realized (e.g., inter-router comm could add the > hashes, who cares, implementation nit.) > > So the question is how long would these be on average and even if it > was a little longer would anyone care? Is a nanosecond saved really a > nanosecond earned? In some applications, yes. In others, not so much. > We're already kind of committed to IP addresses not really meaning > anything (that is, no routing info implied), they are mostly only a > way to pick the next interface to push the packet out of and only need > to be unique, sort of, with exceptions (umm, multicast.) Well, yes and no. In the theoretical world, sure. However, as a practical matter, we depend a great deal on prefix aggregation and being able to carry only summary routes for large chunks of address space in distal routing tables. > BITS IS BITS. They're just bits either way. And in my proposal pretty > easy to remember bits. Until they aren’t because at some point, there needs to be a decoupling between the human-readable form you give and the actual network hierarchy necessary for managing a functional internet. > And Look Ma! No more DNS! Or a much reduced role. You say that as if it’s a good thing. I remain rather thoroughly unconvinced. > I'd agree the idea is several RFCs short of an internet but hey it's > something to think about. I suppose if one is attempting to find a way to drum up business for the NSAID manufacturers, sure. Owen
Re: IPv6 Pain Experiment
> On Oct 7, 2019, at 20:00 , Michel Py wrote: > >> Owen DeLong wrote : >> Well… I don’t run into this very often any more, but I guess if you have a >> poorly run DNS environment, it might be more of an issue. > > About half of my devices, including all the VOIP phones, do not have DNS. I > just cannot afford to lose the phones if there is a DNS failure. They have > DHCP, but not DNS. I usually set these up with DHCP-registered DNS names for the phones. (Dynamic DNS) It works pretty well. I’m not sure how giving them DNS names makes them less resilient to DNS failures. Owen
Re: IPv6 Pain Experiment
Well if you all really want your heads to explode I was invited to give a talk a few years ago in Singapore at the local HackerSpace. It called for something creative and different, not really an IETF sort of crowd. So I proposed we dump numeric addresses entirely and use basically URLs in IP packets and elsewhere. I really meant something like 'IP://www.TheWorld.com' in the source/dest addr, possibly more specific for multiple interfaces but whatevs. Leave out the implied 'IP://' and my example is 16 chars just like IPv6. Routers could of course do what they like with those internally such as maintain a hash table to speed look-ups. Not anyone outside of router software developers' problem. If one agreed on a standard hash algorithm further performance improvements could be realized (e.g., inter-router comm could add the hashes, who cares, implementation nit.) So the question is how long would these be on average and even if it was a little longer would anyone care? Is a nanosecond saved really a nanosecond earned? We're already kind of committed to IP addresses not really meaning anything (that is, no routing info implied), they are mostly only a way to pick the next interface to push the packet out of and only need to be unique, sort of, with exceptions (umm, multicast.) BITS IS BITS. They're just bits either way. And in my proposal pretty easy to remember bits. And Look Ma! No more DNS! Or a much reduced role. I'd agree the idea is several RFCs short of an internet but hey it's something to think about. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
Folks should be aware that if you do not assume extreme pressure (which is what it is taking to get IPv6 deployed), it turns out to be quite hard to get the deployment incentives and structures for a map-and-encaps scheme to actually work for Internet-wide deployment. It does work for a range of special cases. Yours, Joel On 10/7/2019 10:58 PM, Michel Py wrote: William Herrin wrote : I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention. If I couldn't do that, my debate opponent was right -- a greenfield approach to IPv6 made more sense despite the deployment challenge. I think that, 12 years ago, you had the best mouse trap. Map-encap, where you select a decapsulator (consult the map) and then send a tunneled packet (encapsulated) does some cool stuff, but it's a pretty significant change to the network architecture. Definitely not configuration-free. I am so painfully aware of this. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
RE: IPv6 Pain Experiment
> Owen DeLong wrote : > Well… I don’t run into this very often any more, but I guess if you have a > poorly run DNS environment, it might be more of an issue. About half of my devices, including all the VOIP phones, do not have DNS. I just cannot afford to lose the phones if there is a DNS failure. They have DHCP, but not DNS. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
RE: IPv6 Pain Experiment
> William Herrin wrote : > I was out to prove a point. I needed a technique that, at least in theory, > would start working as a result of software > upgrades alone, needing no configuration changes or other operator > intervention. If I couldn't do that, my debate > opponent was right -- a greenfield approach to IPv6 made more sense despite > the deployment challenge. I think that, 12 years ago, you had the best mouse trap. > Map-encap, where you select a decapsulator (consult the map) and then send a > tunneled packet (encapsulated) does > some cool stuff, but it's a pretty significant change to the network > architecture. Definitely not configuration-free. I am so painfully aware of this. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
On Mon, 2019-10-07 at 18:02 -0700, Owen DeLong wrote: > It certainly would have been a higher level of pain in the short run, > but it also would have led to a much shorter period of pain. There's a thing in (biological) evolution that says a species cannot become less fit, even if that is the best or only path to greater fitness. We operate as intelligent entities only as individuals. As a group, we are as dumb as any bacterium. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75
Re: IPv6 Pain Experiment
> On Oct 5, 2019, at 13:36 , b...@theworld.com wrote: > > > On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: >> >> OK… Let’s talk about how? >> >> How would you have made it possible for a host that only understands 32-bit >> addresses to exchange traffic with a host that only has a 128-bit address? > > A bit in the header or similar (version field) indicating extending > addressing (what we call IPv6, or similar) is in use for this packet. > This still requires you to basically rewrite the L3 stack to accommodate the new addresses. > They may not be able to talk but rather than a whole new stack it > would have just been an extension of the commonly used IPv4 stack, > more like a (e.g.) new ICMP option. Uh, no, it would still have required reimplementing the entire L3 stuff at pretty much the same work level as the current IPv6 mechanism. You would still have needed to update: All L4->L3 binding code All Name Resolution code You’d still be faced with all the really hard problems that came with IPv4->IPv6 transition: Updating your applications to understand 128-bit addresses in logs, etc. Updating your provisioning systems to track 128-bit addresses. etc. > Or even an octet indicating how many octets in this address, default > would be four (or even a nybble indicating how many 16-bit words.) This doesn’t make transition any easier and it makes ASIC processing of packet forwarding a heck of a lot harder. > Something simple like that could have, at least in the early stages > (which we're still in w/ IPv6 unfortunately), have been entirely > handled in userspace in the software. Nope… It really couldn’t and that would actually be worse… Right now, the biggest hurdles to IPv6 adoption aren’t the kernel level changes for a new stack, they’re the legacy application changes needed to support bigger addresses. > IPv4? Do the usual. Extended addressing? Hand to a userspace > library. A minor poke to the drivers plus the userspace software. In > many cases wouldn't even require a reboot to install, but at worst a > quick reboot to install the low-level driver that knows to switch > extended addressing packets to userspace. I think you’re very confused about where the pain points with IPv6 are and what it would take to actually implement what you are suggesting here. > Particularly if the low 32 bits indicated the same IPv4 interface w/in > a campus so primarily only the routers needed to interpret the rest of > the address. Uh, so a packet arrives at your 32-bit only application and you can’t tell whether you need to reply to the student’s laptop on the other side of the room or the linear accelerator 3,000 miles away because that’s all included in the 96 bits you didn’t even see that got spirited away to some user-space translator layer. What am I missing? > So it'd get to the right router who'd hand it off to the right > (32-bit) host. Only a problem if your campus happened to have 4B+ > hosts (or maybe 2B+), not likely. Or if you need to communicate both within and outside of your campus (far more likely). > It's similar to IPv4v6 stacks but the host would return the full > address in the (extended) IP packet. How’s the host supposed to do that if the host hasn’t been updated to handle extended addressing? If the host has been updated, then there’s no difference from the current situation with IPv6… The need to update every host (and these days, more relevant, the need to update every application). > In current IPv4v6 stacks (NAT et al) the router has to keep track and > interpolate by rewriting the packets or similar. In what I describe > that's not necessary as each packet retains the full address as it > passes through the host. Yeah, except, you’re assuming every host gets updated with the necessary software to handle essentially IPv6 addressing without adding the IPv6 stack. This sounds like more pain for less gain to me. > Well, basically your question asks for a complete stack design right > here right now, is that really where we want to go? My point is that the changes to implement IPv6 on a given host (at the kernel level) are not significantly more than the changes you are proposing to do what you want. Difference is that they’ve mostly been done for the vast majority of hosts for IPv6 whereas yours would be a new implementation. It still doesn’t yield any greater compatibility because you’ve still got the difficulty of coping with the applications that simply can’t understand a larger internet (which is the biggest hurdle with IPv6 right now). > But the sort of thing I suggest was suggested. And did not gain consensus for the same reasons I outline above, I suspect. > Some of the considerations as to why not do it this way were good, > such as get some other bugs/limitations out of IPv4. And some not so > good like bit-level performance and compatibilty considerations that > have changed
Re: IPv6 Pain Experiment
On Mon, Oct 7, 2019 at 5:31 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > William Herrin wrote: > > > I was out to prove a point. I needed a technique that, at least in > theory, > > would start working as a result of software upgrades alone, needing no > > configuration changes or other operator intervention. > > I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, > which is obviously fully operational with existing IPv4 backbone, is > better. Not a fan of port numbers. If we're going to replace TCP and UDP, initiate the link with a name (e.g. dns name), negotiate a connection ID and continue with the connection ID. No ports, no port scanning. QUIC comes pretty close to getting it right. -Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
William Herrin wrote: I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention. I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P, which is obviously fully operational with existing IPv4 backbone, is better. Masataka Ohta
Re: IPv6 Pain Experiment
On Mon, Oct 7, 2019 at 3:32 PM Michel Py wrote: > >> Michel Py wrote : > >> When did you write this ? I read it before, just can't remember how long ago. > > > William Herrin wrote : > > 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled "The myth of IPv6-IPv4 interoperation." > > On one side of the argument, folks saying that the need to manage two configurations impairs IPv6's deployment. > > On the other, an individual whose thesis was the IPv6 could not have been designed to be backwards compatible > > with IPv4 in a way that required no new configuration, just incremental, backward-compatible software upgrades. > > Why did you choose this route, instead of encapsulating the packet with the extended address into an IPv4 packet ? I was out to prove a point. I needed a technique that, at least in theory, would start working as a result of software upgrades alone, needing no configuration changes or other operator intervention. If I couldn't do that, my debate opponent was right -- a greenfield approach to IPv6 made more sense despite the deployment challenge. Map-encap, where you select a decapsulator (consult the map) and then send a tunneled packet (encapsulated) does some cool stuff, but it's a pretty significant change to the network architecture. Definitely not configuration-free. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
RE: IPv6 Pain Experiment
>> Michel Py wrote : >> When did you write this ? I read it before, just can't remember how long ago. > William Herrin wrote : > 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled > "The myth of IPv6-IPv4 interoperation." > On one side of the argument, folks saying that the need to manage two > configurations impairs IPv6's deployment. > On the other, an individual whose thesis was the IPv6 could not have been > designed to be backwards compatible > with IPv4 in a way that required no new configuration, just incremental, > backward-compatible software upgrades. Why did you choose this route, instead of encapsulating the packet with the extended address into an IPv4 packet ? Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
On Mon, Oct 7, 2019 at 11:34 AM Michel Py wrote: > > William Herrin wrote : > > I want to divert from the current flame war to make my biennial semi-serious reminder that it was at least theoretically possible to > > expand the IPv4 address space rather than make a whole new protocol. That we did not do so was a failure of imagination. > > http://bill.herrin.us/network/ipxl.html > > That could have worked. Eventually, some form of IPv4 with "just" more bits could surface, but it will take a decade or more. > When did you write this ? I read it before, just can't remember how long ago. 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled "The myth of IPv6-IPv4 interoperation." On one side of the argument, folks saying that the need to manage two configurations impairs IPv6's deployment. On the other, an individual whose thesis was the IPv6 could not have been designed to be backwards compatible with IPv4 in a way that required no new configuration, just incremental, backward-compatible software upgrades. -Bill -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
On Sun, Oct 06, 2019 at 05:58:39PM -0400, Valdis Klētnieks wrote: > 8.8.4.5.13.9/40 > 8.8.4.5.17.168/40 > This is so unreadable to me :/ My brain keeps on wondering if this is an "IPv4+" or a phone number or a typo...
RE: IPv6 Pain Experiment
> William Herrin wrote : > I want to divert from the current flame war to make my biennial semi-serious > reminder that it was at least theoretically possible to > expand the IPv4 address space rather than make a whole new protocol. That we > did not do so was a failure of imagination. > http://bill.herrin.us/network/ipxl.html That could have worked. Eventually, some form of IPv4 with "just" more bits could surface, but it will take a decade or more. When did you write this ? I read it before, just can't remember how long ago. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
On Fri, Oct 4, 2019 at 4:48 PM Michel Py wrote: > > Owen DeLong wrote : > > How would you have made it possible for a host that only understands > 32-bit addresses to exchange traffic with a host that only has a 128-bit > address? > > With some kind of NAT mechanism, naturally. > I want to divert from the current flame war to make my biennial semi-serious reminder that it was at least theoretically possible to expand the IPv4 address space rather than make a whole new protocol. That we did not do so was a failure of imagination. http://bill.herrin.us/network/ipxl.html > > How would you have made a 128-bit address more human-readable? Does it > really matter? > > Everyone gets the numbers. > Everyone thinks they get numbers. Until they try to compute a netmask or perform any other non-rote IP networking task. The people who get hex tend to actually get numbers. Both ways. If you want to know for sure whether the other person understood you, explain it in hex. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: IPv6 Pain Experiment
I think we're basically on the same page. But what I described wouldn't use port numbers to fake extended addressing, just a flag and some extra IP header for the extended addr bits. On October 6, 2019 at 21:12 li...@packetflux.com (Forrest Christian (List Account)) wrote: > I've been ignoring this discussion because I feel this ship sailed many years > ago, and IPv6, like it or hate it, is the best way forward we have. > > But, assuming you're expanding the address space, the simplest solution is to > add the additional bits addresses at the end. > > I.E. every existing /32 gets an additional 64K addresses. Or how many > correspond to the additional number of bits. > > You can then add this without making any changes to the core of the > internet. > It's all routed just like it is today, only paying attention to the first > /32 > of the address. The remaining /16 or /32 or whatever is then only handled > internally by each network/ASN. Heck, you might be able to this without > changing IP at all - instead, you could probably add an extension address > layer > between IP and TCP. So it's TCP/EXPADDR/IP. > > The motivation to upgrade can then come from the endpoints. For a lot of > applications, one only would have to update the customer-end software (i.e. > web > browsers), and the server end. So if you're a google and are tired of > trying > to obtain more and more addresses, you just get the main browser vendors to > add > support for "IP Extended addressing" and then you add it on your servers. > The > internet in the middle doesn't care. As a host, all you need is a single / > 32. At some point, eyeball networks could start handing out the extended > addresses or using them for NAT, also alleviating their need for IP's. > > On the other hand, this sure seems similar to what we do today with CGNAT and > similar today since there are already 64K endpoints in both TCP and UDP per > ./ > 32 of IP > > On Sun, Oct 6, 2019 at 3:59 PM Valdis Klētnieks > wrote: > > On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said: > > > All a strictly IPv4 only host/router would need to understand in that > > case is the IHL, which it does already, and how to interpret whatever > > flag/option is used to indicate the presence of additional address > > bits mostly to ignore it or perhaps just enough to know to drop it if > > it's not implemented. > > So... how would a strict IPv4 router handle the case where > 8.8.4.5.13.9/40 > should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via > Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes > because there's yet another peering war and nobody's baked a cake yet, so > sending packets for either route to the wrong link will cause > blackholing? > > > > > -- > - Forrest -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
I didn't quite say nothing would need to be changed, only that the changes would be by and large very minimal, some new cases in the existing IPv4 stacks, rather than an entirely new stack. Particularly for hosts, if this bit (flag, whatever) is set be sure to copy the entire IP packet into your dest headers. The extended addressing I describe could probably be mostly implemented in hosts as a new ICMP option for extended addressing. On October 6, 2019 at 17:58 valdis.kletni...@vt.edu (Valdis Klētnieks) wrote: > On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said: > > > All a strictly IPv4 only host/router would need to understand in that > > case is the IHL, which it does already, and how to interpret whatever > > flag/option is used to indicate the presence of additional address > > bits mostly to ignore it or perhaps just enough to know to drop it if > > it's not implemented. > > So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 > should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via > Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes > because there's yet another peering war and nobody's baked a cake yet, so > sending packets for either route to the wrong link will cause blackholing? > > x[DELETED ATTACHMENT , application/pgp-signature] -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
On 10/7/2019 7:37 AM, Valdis Klētnieks wrote: On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said: Likewise for spam filtering - spam filtering would be knocked back to the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's dream come true, since IPv6 DNSBLs are practically worthless. Riddle me this: Why then have spammers not abandoned IPv4 and moved to IPv6 where we're totally powerless to stop their floods of spam? I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't stop the spam" - if that were true, then every organization that *has* moved to IPv6 would be drowning in spam. (1) as Stephen Satchell said... because a huge percentage of mailboxes (perhaps the vast majority?) are still behind servers that (wisely!) only listen on IPv4 for non-auth connections, so spammers would have to make extremely large deletions to their distribution list if they only sent to emails where the mail server only listened on IPv6. (2) For my own commercial anti-spam blacklist, I've had SEVERAL new subscribers this past year who specifically complained about spams that my anti-spam blacklists (AND all the other ones like Spamhaus, etc!) were NOT blocking. I requested more information about the ones that weren't getting blocked... and they were almost all IPv6-sent spams. I simply explained to them that they do NOT have to do this, and that most of that spam will go away the moment that their server only listens on IPv4 (at least, for non-SMTP-AUTH email - they can still listen for IPv6 authenticated email without these problems). I also explained to them that there hadn't been a situation in the history of the world where an email didn't make it to a server that only listened on IPv4 for non-authenticated email. (3) Many IPv6 mail servers have had to invest/expend significantly more resources per mailbox. (4) trying to get everyone to move too quickly to IPv6 POTENTIALLY actually damages email and harms OTHER's spam filtering. Why? Because it enables listwashing. A spammer can literally send to 10s of thousands of email addresses each from a separate /64 block, with a one-to-one relationship between the /64 block and the recipient email address. Then they can listwash spamtrap addresses based on which of those /64 blocks get blacklisted. It ALSO harms email because shady marketers get the idea that there are endless new IPs to burn through, and that only emboldens them. So when it comes to email, it turns out that IPv4 scarcity (for non-auth connections) is a feature not a bug! But, if desired, you can STILL have massive amounts of IPv6 clients sending via SMTP authentication - so this won't limit your ability for your refrigerator to send authenticated email to you! (so that greatly minimizes the "but we're running out" longer-term argument - besides the fact that this isn't really a HUGE problem anyways - since IPv6 clients already are already able to connect to IPv4 servers) -- Rob McEwen https://www.invaluement.com
Re: IPv6 Pain Experiment
On 10/7/19 4:37 AM, Valdis Klētnieks wrote: > On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said: >> Likewise for spam filtering - spam filtering would be knocked back to >> the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's >> dream come true, since IPv6 DNSBLs are practically worthless. > > Riddle me this: Why then have spammers not abandoned IPv4 and moved to > IPv6 where we're totally powerless to stop their floods of spam? > > I'm tired of hearing the excuse "We can't move to IPv6 because then we > couldn't > stop the spam" - if that were true, then every organization that *has* moved > to IPv6 would be drowning in spam. Spammers haven't abandoned IPv4 for IPv6 because some significant percentage of mail servers are still IPv4 only. I know mine is, and will most likely stay that way for the reasons that Rob points out. Any link between an IPv6 spammer and an IPv4 mail server would have to undergo NAT of some form, and the IPv4 address of NAT would then be subject to blocking action. The BOFH model from the old NFS days won't work anymore.
Re: IPv6 Pain Experiment
On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said: > Likewise for spam filtering - spam filtering would be knocked back to > the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's > dream come true, since IPv6 DNSBLs are practically worthless. Riddle me this: Why then have spammers not abandoned IPv4 and moved to IPv6 where we're totally powerless to stop their floods of spam? I'm tired of hearing the excuse "We can't move to IPv6 because then we couldn't stop the spam" - if that were true, then every organization that *has* moved to IPv6 would be drowning in spam. pgp308XuGGKjm.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On 10/7/2019 2:03 AM, Masataka Ohta wrote: Forrest Christian (List Account) wrote: I've been ignoring this discussion because I feel this ship sailed many years ago, and IPv6, like it or hate it, is the best way forward we have. A problem is that there is a cliff edge in front of you. Likewise for spam filtering - spam filtering would be knocked back to the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's dream come true, since IPv6 DNSBLs are practically worthless. Yes, there are OTHER filtering techniques, but none that scale nearly so much with as extremely little resources required. And this is a problem for large and small organizations. Even the very largest email systems would be extremely disrupted if IPv4 DNSBLs (internal and/or 3rd party) were not available within the very near future. Solutions to this problem would then severely disrupt their business/financial models for those mail systems since the overhead costs per mailbox would significantly increase. -- Rob McEwen https://www.invaluement.com
Re: IPv6 Pain Experiment
Forrest Christian (List Account) wrote: I've been ignoring this discussion because I feel this ship sailed many years ago, and IPv6, like it or hate it, is the best way forward we have. A problem is that there is a cliff edge in front of you. But, assuming you're expanding the address space, the simplest solution is to add the additional bits addresses at the end. Sure. > On the other hand, this sure seems similar to what we do today with > CGNAT and similar today since there are already 64K endpoints in > both TCP and UDP per ./32 of IP The following draft makes it more explicit: https://tools.ietf.org/html/draft-ymbk-aplusp-10 The A+P Approach to the IPv4 Address Shortage R. Bush, Ed. Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional end point identifiers, A+P is equivalent to NAT with end to end transparency. Masataka Ohta
Re: IPv6 Pain Experiment
I've been ignoring this discussion because I feel this ship sailed many years ago, and IPv6, like it or hate it, is the best way forward we have. But, assuming you're expanding the address space, the simplest solution is to add the additional bits addresses at the end. I.E. every existing /32 gets an additional 64K addresses. Or how many correspond to the additional number of bits. You can then add this without making any changes to the core of the internet. It's all routed just like it is today, only paying attention to the first /32 of the address. The remaining /16 or /32 or whatever is then only handled internally by each network/ASN. Heck, you might be able to this without changing IP at all - instead, you could probably add an extension address layer between IP and TCP. So it's TCP/EXPADDR/IP. The motivation to upgrade can then come from the endpoints. For a lot of applications, one only would have to update the customer-end software (i.e. web browsers), and the server end. So if you're a google and are tired of trying to obtain more and more addresses, you just get the main browser vendors to add support for "IP Extended addressing" and then you add it on your servers. The internet in the middle doesn't care.As a host, all you need is a single /32. At some point, eyeball networks could start handing out the extended addresses or using them for NAT, also alleviating their need for IP's. On the other hand, this sure seems similar to what we do today with CGNAT and similar today since there are already 64K endpoints in both TCP and UDP per ./32 of IP On Sun, Oct 6, 2019 at 3:59 PM Valdis Klētnieks wrote: > On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said: > > > All a strictly IPv4 only host/router would need to understand in that > > case is the IHL, which it does already, and how to interpret whatever > > flag/option is used to indicate the presence of additional address > > bits mostly to ignore it or perhaps just enough to know to drop it if > > it's not implemented. > > So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 > should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via > Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes > because there's yet another peering war and nobody's baked a cake yet, so > sending packets for either route to the wrong link will cause blackholing? > > -- - Forrest
Re: IPv6 Pain Experiment
On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said: > All a strictly IPv4 only host/router would need to understand in that > case is the IHL, which it does already, and how to interpret whatever > flag/option is used to indicate the presence of additional address > bits mostly to ignore it or perhaps just enough to know to drop it if > it's not implemented. So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40 should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes because there's yet another peering war and nobody's baked a cake yet, so sending packets for either route to the wrong link will cause blackholing? pgpa4OOixbqzc.pgp Description: PGP signature
Re: IPv6 Pain Experiment
On October 6, 2019 at 16:35 jhellent...@dataix.net (J. Hellenthal) wrote: > And in which part of the header is this to be added ? I assume you mean the additional address. The IHL provides for up to 60 bytes of IP header length. 20 bytes is needed for the usual IPv4 header so an additional 40 bytes are available or 20 bytes for each of source and destination, adding the 4 bytes already present that's 24 bytes for each of source and destination or a theoretical total of 192 bits of (each) source and dest address. All a strictly IPv4 only host/router would need to understand in that case is the IHL, which it does already, and how to interpret whatever flag/option is used to indicate the presence of additional address bits mostly to ignore it or perhaps just enough to know to drop it if it's not implemented. > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says a > lot about anticipated traffic volume. > > > On Oct 6, 2019, at 15:58, b...@theworld.com wrote: > > > > > >> On October 6, 2019 at 15:18 mpal...@hezmatt.org (Matt Palmer) wrote: > >>> On Sat, Oct 05, 2019 at 04:36:50PM -0400, b...@theworld.com wrote: > >>> > >>> On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: > > OK… Let’s talk about how? > > How would you have made it possible for a host that only understands > 32-bit addresses to exchange traffic with a host that only has a > 128-bit address? > >>> > >>> A bit in the header or similar (version field) indicating extending > >>> addressing (what we call IPv6, or similar) is in use for this packet. > >> > >> How does that allow the host that only understands 32-bit addresses to > >> exchange traffic with a host which sets this header bit? > > > > As I said, it doesn't, but it lets each host decide that rather than > > the router tho if the host just knows enough to copy out the entire > > src/dst address (imagine the bits beyond the first 32 were in > > something like an extended ICMP options field w/in the IP header) then > > the rest could operate identically to ipv4. > > > > So all you'd need added to a host IPv4 stack would be if you see this > > extended addressing flag/bit/whatever then there's more that needs to > > be copied out to each outgoing IP packet. > > > > It would be the routers' job to interpret those extra bits for routing. > > > > -- > >-Barry Shein > > > > Software Tool & Die| b...@theworld.com | > > http://www.TheWorld.com > > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > > The World: Since 1989 | A Public Information Utility | *oo* -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
And in which part of the header is this to be added ? -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Oct 6, 2019, at 15:58, b...@theworld.com wrote: > > >> On October 6, 2019 at 15:18 mpal...@hezmatt.org (Matt Palmer) wrote: >>> On Sat, Oct 05, 2019 at 04:36:50PM -0400, b...@theworld.com wrote: >>> >>> On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: OK… Let’s talk about how? How would you have made it possible for a host that only understands 32-bit addresses to exchange traffic with a host that only has a 128-bit address? >>> >>> A bit in the header or similar (version field) indicating extending >>> addressing (what we call IPv6, or similar) is in use for this packet. >> >> How does that allow the host that only understands 32-bit addresses to >> exchange traffic with a host which sets this header bit? > > As I said, it doesn't, but it lets each host decide that rather than > the router tho if the host just knows enough to copy out the entire > src/dst address (imagine the bits beyond the first 32 were in > something like an extended ICMP options field w/in the IP header) then > the rest could operate identically to ipv4. > > So all you'd need added to a host IPv4 stack would be if you see this > extended addressing flag/bit/whatever then there's more that needs to > be copied out to each outgoing IP packet. > > It would be the routers' job to interpret those extra bits for routing. > > -- >-Barry Shein > > Software Tool & Die| b...@theworld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
On October 6, 2019 at 15:18 mpal...@hezmatt.org (Matt Palmer) wrote: > On Sat, Oct 05, 2019 at 04:36:50PM -0400, b...@theworld.com wrote: > > > > On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: > > > > > > OK… Let’s talk about how? > > > > > > How would you have made it possible for a host that only understands > > 32-bit addresses to exchange traffic with a host that only has a 128-bit > > address? > > > > A bit in the header or similar (version field) indicating extending > > addressing (what we call IPv6, or similar) is in use for this packet. > > How does that allow the host that only understands 32-bit addresses to > exchange traffic with a host which sets this header bit? As I said, it doesn't, but it lets each host decide that rather than the router tho if the host just knows enough to copy out the entire src/dst address (imagine the bits beyond the first 32 were in something like an extended ICMP options field w/in the IP header) then the rest could operate identically to ipv4. So all you'd need added to a host IPv4 stack would be if you see this extended addressing flag/bit/whatever then there's more that needs to be copied out to each outgoing IP packet. It would be the routers' job to interpret those extra bits for routing. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
RE: IPv6 Pain Experiment
>>> Owen DeLong wrote : >>> How would you have made it possible for a host that only understands 32-bit >>> addresses to exchange traffic with a host that only has a 128-bit address? >> Michel Py wrote : >> With some kind of NAT mechanism, naturally. >> Which is not possible with the current IPv6 address format, if you want >> something stateless and that does not rely on DNS. > Owen DeLong wrote : > Well, what address format would you propose that would make it better? Let’s > talk actual workable detailed proposals rather than just hand-waving. We need IPv8. Oh wait, where is Jim Fleming ? Oh wait. We need IPv10. Where is the las troll ? can't even remember his name, pathetic. Jim Fleming, we need you back. Seriously, the latest troll attempts have been quite unsatisfying. Owen, I am not going to share my address format with you. You are not ready for it. Do you remember the last time we presented back-to-back ? >> Try to say FACEB00C to someone who does not speak your langage. > Well, your abuse of the phonetic alphabet might be part of the problem… I am not the one abusing the phonetic alphabet here. Last time I checked, the public IPv6 for facebook was 2a03:2880:f003:c07:face:b00c::2 Clever. I would have done the same. Old IPX days : FEED.BABE.BEEF In french : CAFE (literally : C0FEE, but 4 digits) As of pilot talk, the "niner" part of it is a total no-no out of the US. You are preaching to the choir in your next email, and you are wrong. You and I can do hex, the rest of the world can not. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
On Sat, Oct 05, 2019 at 04:36:50PM -0400, b...@theworld.com wrote: > > On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: > > > > OK… Let’s talk about how? > > > > How would you have made it possible for a host that only understands > 32-bit addresses to exchange traffic with a host that only has a 128-bit > address? > > A bit in the header or similar (version field) indicating extending > addressing (what we call IPv6, or similar) is in use for this packet. How does that allow the host that only understands 32-bit addresses to exchange traffic with a host which sets this header bit? - Matt
Re: IPv6 Pain Experiment
On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote: > > OK… Let’s talk about how? > > How would you have made it possible for a host that only understands 32-bit > addresses to exchange traffic with a host that only has a 128-bit address? A bit in the header or similar (version field) indicating extending addressing (what we call IPv6, or similar) is in use for this packet. They may not be able to talk but rather than a whole new stack it would have just been an extension of the commonly used IPv4 stack, more like a (e.g.) new ICMP option. Or even an octet indicating how many octets in this address, default would be four (or even a nybble indicating how many 16-bit words.) Something simple like that could have, at least in the early stages (which we're still in w/ IPv6 unfortunately), have been entirely handled in userspace in the software. IPv4? Do the usual. Extended addressing? Hand to a userspace library. A minor poke to the drivers plus the userspace software. In many cases wouldn't even require a reboot to install, but at worst a quick reboot to install the low-level driver that knows to switch extended addressing packets to userspace. Particularly if the low 32 bits indicated the same IPv4 interface w/in a campus so primarily only the routers needed to interpret the rest of the address. So it'd get to the right router who'd hand it off to the right (32-bit) host. Only a problem if your campus happened to have 4B+ hosts (or maybe 2B+), not likely. It's similar to IPv4v6 stacks but the host would return the full address in the (extended) IP packet. In current IPv4v6 stacks (NAT et al) the router has to keep track and interpolate by rewriting the packets or similar. In what I describe that's not necessary as each packet retains the full address as it passes through the host. Well, basically your question asks for a complete stack design right here right now, is that really where we want to go? But the sort of thing I suggest was suggested. Some of the considerations as to why not do it this way were good, such as get some other bugs/limitations out of IPv4. And some not so good like bit-level performance and compatibilty considerations that have changed considerably since 1990. Were the 36-bit'ers still at the table in 1990? Probably. And CGNAT et al wasn't really conceived of yet or not very completely so it was assumed this would all be so urgent as to propel itself into the mainstream. > > How would you have made a 128-bit address more human-readable? Does it > really matter? That really depends on your priorities. If the priority was, as with ipv4, location independence so all bits are equally meaningful (i.e., necessary to know what's desired), then it's difficult. If it were actually treated as a potential problem then more defaults may have been engineered in. But since this is a human interface problem I lean towards better software to view and manipulate addrs and let the engineers do what they need to do. It's the tail wagging the dog or perhaps the dog returning to its, um, whatever. We developed, w/ IPv4, this entire culture and software regime which thought it was reasonable to sometimes enter/read IPv4 addrs because they weren't too hard and then carried that over to IPv6 (not in theory, in practice.) Meaning, for example, if DNS isn't working for you then you're often left to entering raw IP addresses manually, and "you" can often be non-technical users. IPv4, not a big deal, IPv6, challenging. Mere cut+paste no doubt helps. > > IPv4 is not particularly human readable. How many hosts do you keep IPv4 > addresses in your head for? How long does it take you to get someone at the > other end of a support call to correctly transcribe an IPv4 address? IPv4 is not that much more difficult than a phone number. IPv6 is. IPv4 benefits from chunking, like phone numbers. If I have an idea of the "net", by which I mean the part which comes up repeatedly (such as w/in a campus) often the first two numbers, then all I really have to remember anew is the last two numbers, maybe only the last. For IPv6 it can be more difficult to commit a prefix to memory even if it's used somewhat regularly. But I'd agree this is mostly a red herring, better human interface software should help and that might take time to evolve. > > All of this is mostly absurd as DNS names are human readable regardless of > whether they point to A, , or both records. As I said it often comes up precisely because, for some reason, DNS isn't available or not working correctly. > > Owen > Anyhow, this is all fantasy sports. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: IPv6 Pain Experiment
> On Oct 4, 2019, at 20:23 , Owen DeLong wrote: > > > >> On Oct 4, 2019, at 16:48 , Michel Py wrote: >> >>> Owen DeLong wrote : >>> How would you have made it possible for a host that only understands 32-bit >>> addresses to exchange traffic with a host that only has a 128-bit address? >> >> With some kind of NAT mechanism, naturally. >> Which is not possible with the current IPv6 address format, if you want >> something stateless and that does not rely on DNS. > > Well, what address format would you propose that would make it better? Let’s > talk actual workable detailed proposals rather than just hand-waving. > > We already have a number of such solutions: > NAT64 > 464XLAT > B4/AFTR > etc. > >>> How would you have made a 128-bit address more human-readable? Does it >>> really matter? >> >> I have found it difficult to talk hex with people from other countries. Sorry, hit send too soon. Won’t rehash previously posted content, but here’s what got missed… In addition, hex makes it MUCH easier to do subnetting. Each digit aligns with a nibble boundary, so instead of having to memorize/calculate 8 different powers of two ranging from 1-128, you only need to memorize 4 ranging from 0-8. Further, given the bountiful amount of IPv6 space available, you shouldn’t really need to subnet off nibble boundaries unless you really want to. How many people do you know (as a percentage) that divide RFC-1918 space into non-octet-aligned subnets? Remember the handy subnet calculators for IPv4 that broke down all the net mask possibilities: / 9, /17, /25 — .0/.128 (0-127 and 128-255) /10, /18, /26 — .0/.64/.128/.192 (0-63, 64-127, 128-191, 192-255) … /15, /23, /31 — .0/.2/.4/.6/.8/.10/.12/.14/.16/… Yeah, compare that to: /n % 4 = 0 — Aligns with nibble boundary. 1 — 0/8 (0-7, 8-f) 2 — 0/4/8/c (0-3, 4-7, 8-b, c-f) 3 — 0/2/4/6/8/a/c/e (0-1, 2-3, 4-5, 6-7, 8-9, a-b, c-d, e-f) Subnetting is MUCH MUCH MUCH simpler in IPv6, especially if you follow the intended architecture/recommendations. Owen
Re: IPv6 Pain Experiment
> On Oct 4, 2019, at 16:48 , Michel Py wrote: > >> Owen DeLong wrote : >> How would you have made it possible for a host that only understands 32-bit >> addresses to exchange traffic with a host that only has a 128-bit address? > > With some kind of NAT mechanism, naturally. > Which is not possible with the current IPv6 address format, if you want > something stateless and that does not rely on DNS. Well, what address format would you propose that would make it better? Let’s talk actual workable detailed proposals rather than just hand-waving. We already have a number of such solutions: NAT64 464XLAT B4/AFTR etc. >> How would you have made a 128-bit address more human-readable? Does it >> really matter? > > I have found it difficult to talk hex with people from other countries. I haven’t had that much trouble. > Try to say FACEB00C to someone who does not speak your langage. Well, your abuse of the phonetic alphabet might be part of the problem… > Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. Foxtrot, Alpha, Charlie, Echo, colon, Bravo, Zero, Zero, Charlie has worked relatively well for me. > 250.206.176.192 works all the time. Everyone gets the numbers. Really? I’ve actually had more confusion over this… especially five vs. nine (unless I resort to pilot-speak which often confuses them even more). two, five, zero, point, two, zero, six, point, one, seven, six, point, one, nine, two will almost invariably result in some random member of the set: 290.206.176.152 250.206.176.152 250.206.176.192 290.206.176.192 And that’s an address not particularly fraught… Consider, instead: 193.159.155.159 Sometimes I get lucky with one, niner, tree, point, one, fife, niner, point, one, fife, fife, point, one, fife, niner. However, that’s rare. I guess it depends in part on who you are speaking with. Owen > > Michel. > > > > > TSI Disclaimer: This message and any files or text attached to it are > intended only for the recipients named above and contain information that may > be confidential or privileged. If you are not the intended recipient, you > must not forward, copy, use or otherwise disclose this communication or the > information contained herein. In the event you have received this message in > error, please notify the sender immediately by replying to this message, and > then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
On Fri, Oct 04, 2019 at 11:48:33PM +, Michel Py wrote: > > Owen DeLong wrote : > > How would you have made it possible for a host that only understands 32-bit > > addresses to exchange traffic with a host that only has a 128-bit address? > > With some kind of NAT mechanism, naturally. That word "naturally" is doing an *awful* lot of work there. > > How would you have made a 128-bit address more human-readable? Does it > > really matter? > > I have found it difficult to talk hex with people from other countries. > > Try to say FACEB00C to someone who does not speak your langage. > Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. > 250.206.176.192 works all the time. Everyone gets the numbers. That word "Everyone" is doing an *awful* lot of work there. All this hand-waving is creating quite a breeze. Think I'll put on a sweater. - Matt
RE: IPv6 Pain Experiment
> Owen DeLong wrote : > How would you have made it possible for a host that only understands 32-bit > addresses to exchange traffic with a host that only has a 128-bit address? With some kind of NAT mechanism, naturally. Which is not possible with the current IPv6 address format, if you want something stateless and that does not rely on DNS. > How would you have made a 128-bit address more human-readable? Does it really > matter? I have found it difficult to talk hex with people from other countries. Try to say FACEB00C to someone who does not speak your langage. Foxtrox Alpha Charlie Echo Bravo Zero Zero Charlie does not go through either. 250.206.176.192 works all the time. Everyone gets the numbers. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: IPv6 Pain Experiment
> On Oct 2, 2019, at 17:54 , Matt Hoppes > wrote: > > I disagree on that. Ipv4 is very human readable. It is numbers. > > Ipv6 is not human numbers. It’s hex, which is not how we normally county. > > It is all water under the bridge now, but I really feel like ipv6 could have > been made more human friendly and ipv4 interoperable. > >> On Oct 2, 2019, at 8:49 PM, Doug Barton wrote: >> >>> On 10/2/19 3:03 PM, Naslund, Steve wrote: >>> The next largest hurdle is trying to explain to your server guys that you >>> are going to go with all dynamically assigned addressing now >> >> Completely false, but a very common misconception. There is nothing about >> IPv6 that prevents you from assigning static addresses. >> >>> and explaining to your system admin that can’t get a net mask in v4 figured >>> out, how to configure their systems for IPv6. >> >> If they only need an outbound connection, they probably don't need any >> configuration. The instructions for assigning a static address for inbound >> connections vary by OS, but I've seen a lot of them, and none of them are >> more than 10 lines long. >> >> Regarding the previous comments about all the drama of adding DNS records, >> etc.; that is what IPAM systems are for. If you're small enough that you >> don't need an IPAM for IPv4, you almost certainly don't for IPv6. >> >> IPv6 is different, but it's not any more difficult to learn than IPv4. (You >> weren't born understanding IPv4 either.) >> >> Doug OK… Let’s talk about how? How would you have made it possible for a host that only understands 32-bit addresses to exchange traffic with a host that only has a 128-bit address? How would you have made a 128-bit address more human-readable? Does it really matter? IPv4 is not particularly human readable. How many hosts do you keep IPv4 addresses in your head for? How long does it take you to get someone at the other end of a support call to correctly transcribe an IPv4 address? All of this is mostly absurd as DNS names are human readable regardless of whether they point to A, , or both records. Owen
Re: IPv6 Pain Experiment
Matt Harris wrote: That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6. If this is a concern, then get an allocation from your local RIR and announce it yourself. Then no provider lock-in based on address space of any sort. So, IPv6 did not failed, because manual renumbering is easy and, even if it is hard, we don't need CIDER. Very convincing argument. In general any sort of provider move is going to be disruptive if you don't have your own address space, Automatic renumbering is the technology to make it not disruptive. It is doable, if the tricky part of nameserver address changes is properly taken care of. But, people who think renumbering just a prefix change can not do it, resulting in garbages like A6 RRs or IPv6 itself. Masataka Ohta
Re: IPv6 Pain Experiment
On 10/4/19 7:45 AM, Warren Kumari wrote: On Fri, Oct 4, 2019 at 5:13 AM Masataka Ohta wrote: Doug Barton wrote: And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix. This is the same as saying "If you need to change providers in IPv4, once you have your addressing plan in place all you have to do is change the prefix", or "To build the Eiffel Tower, all you have to do is bolt bits of metal together" -- it's technically correct*, but handwaves away the actual complexity and scale of work. Yes, you (clearly) can renumber v6 networks, and it's *probably* easier than renumbering v4, but "just change the prefix" oversells it. I was assuming that this audience understands the relative complexity of changing the network parts of the address, and leaving the subnet and host parts in place. And by and large, it is not true that you can do this with IPv4. You might occasionally get lucky with it, but that would be the exception, not the rule. As for your Eiffel Tower example, the design and architecture are the pieces that would already be in place as part of your networking plan, so in a sense we're talking about RE-building the Eiffel Tower by taking off one bit of metal (the old network) and bolting another piece in its place. Not building it all over again from scratch. So you can credibly accuse me of underselling the renumbering effort, but don't engage in hyperbole to try to balance the scales. Renumbering has its pain points regardless of the protocol, but if you've designed your network correctly IPv6 renumbering is considerably easier than it is in IPv4. Doug
Re: IPv6 Pain Experiment
On Friday, 4 October, 2019 05:55, "Doug Barton" said: > ... unless you're large enough to have your own address space. And even > if you do need to change providers, once you have your addressing plan > in place all you have to change is the prefix. And if this is hard, we should be beating up hardware (and software) vendors to make it easier. Case in point, my home broadband has a /56 routed to it. (It's a dynamic /56, and it does change, which is broken in itself, but that's another discussion). The ISP-supplied router has a basic GUI-driven IPv6 firewall - in which I can edit only the host parts of the local addresses, and the /64 is automatically filled in from the current prefix. Routed prefix changes, all the firewall rules change to match. I'm not a firewall guy, but wouldn't it be cool if grown-up firewalls did this (if they don't already)? Maybe with a bit more control, so you explicitly set $IPV6_PREFIX somewhere in the config, and can base all your other config off it. Maybe with the ability to have multiple such prefixes active at the same time, so while you're renumbering, your firewall rules, interface addressing, RAs, ... all cover both IPv6 prefixes just by adding one line of config to the "prefixes I have" stanza. Even without the tools built-in, s/2001:db8:1::/2001:db8:2::/g feels like a manageable piece of work, not a blocker. Regards, Tim.
Re: IPv6 Pain Experiment
On Fri, Oct 4, 2019 at 5:13 AM Masataka Ohta wrote: > > Doug Barton wrote: > > > And even > > if you do need to change providers, once you have your addressing plan > > in place all you have to change is the prefix. > This is the same as saying "If you need to change providers in IPv4, once you have your addressing plan in place all you have to do is change the prefix", or "To build the Eiffel Tower, all you have to do is bolt bits of metal together" -- it's technically correct*, but handwaves away the actual complexity and scale of work. Yes, you (clearly) can renumber v6 networks, and it's *probably* easier than renumbering v4, but "just change the prefix" oversells it. > Your attempt to hype people that renumbering were easy has > zero probability of success here. > > > Except that it's not failing, > > It failed from the beginning. W *: Yes, the best kind of correct. > > Masataka Ohta -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Re: IPv6 Pain Experiment
On Thu, Oct 3, 2019 at 10:42 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Doug Barton wrote: > > >> Automatic renumbering involving DNS was important design goal > >> of IPv6 with reasons. > >> > >> Lack of it is still a problem. > > > Meanwhile, the thing that most people miss about IPv6 is that except in > > edge cases, you never have to renumber. You get a massive address block > > that you can use as long as you pay your bill. > > That is called "provider lock-in", which is the primary > reason, when IPng WG was formed, why automatic renumbering > is necessary for IPv6. > If this is a concern, then get an allocation from your local RIR and announce it yourself. Then no provider lock-in based on address space of any sort. In general any sort of provider move is going to be disruptive if you don't have your own address space, so that should be taken into account when choosing to use address space that is somebody else's for production services that need to be reachable globally. > So, again, stop spreading FUD. > > Look at the fact that IPv6 failed badly. > Huh? IPv6 has succeeded slowly, not failed badly. There are loads of us using it in production today just fine.
Re: IPv6 Pain Experiment
Doug Barton wrote: And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix. Your attempt to hype people that renumbering were easy has zero probability of success here. Except that it's not failing, It failed from the beginning. Masataka Ohta
Re: IPv6 Pain Experiment
On 10/3/19 8:41 PM, Masataka Ohta wrote: Doug Barton wrote: Automatic renumbering involving DNS was important design goal of IPv6 with reasons. Lack of it is still a problem. Meanwhile, the thing that most people miss about IPv6 is that except in edge cases, you never have to renumber. You get a massive address block that you can use as long as you pay your bill. That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6. ... unless you're large enough to have your own address space. And even if you do need to change providers, once you have your addressing plan in place all you have to change is the prefix. So, again, stop spreading FUD. Look at the fact that IPv6 failed badly. Except that it's not failing, deployment and bits transported go up every month. Almost all of the large content providers are accessible via IPv6, and all of the major US mobile carriers are using it, some exclusively. I get that you WANT it to fail, and you're entitled to your opinion. You're even entitled not to deploy it. But you're not entitled to your own facts. Doug
Re: IPv6 Pain Experiment
I'm going to reply in some detail to your points here because they are very common arguments that have real answers. Those who have heard all this before are free to move on. :) You sound like someone who doesn't have experience with IPv6. I don't intend any criticism, I'm simply saying that once you start working with it, you learn it, and almost all of these concerns evaporate. Just like what happened when you learned IPv4. On 10/3/19 8:20 AM, Naslund, Steve wrote: I don’t think the issue is the readability of the addresses (although hex does confuse some people), mainly it is the length and ability to deal with any string of numbers that long for a human, Coming from IPv4 world, it's very common that when you're working with addresses directly most or even sometimes all, of the bits are different. By and large this isn't the case with IPv6. If you sized your RIR request properly, you'll have the same /32 (or shorter) prefix across your entire network. That covers the first two hextets of the network portion of the address (that is, half the network portion). One of the great things about IPv6 is sparse allocation. The next hextet (third of four in the network section of the address) are the bits from /33 through /48. Since except for all but the largest sites you'll assign a /48 per site (65,536 /64s) that hextet will be the same across the entire site. For a really large office site, or a medium size data center, you might assign a /44 (1,048,576 /64s), so 3/4 of that hextet will be stable across that site. For a large data center you might assign a /40 (16,777,216 /64s) so half the hextet will be stable across that site. So let's say a site is allocated 2001:0db8:1234::/48. A common practice is to use the top of the space for infrastructure, so 2001:0db8:1234:0/49 (32,768 /64s) would be the same prefix used everywhere at that site, and every site would have the same admin prefix. Hopefully by now you can see the opportunities ... and I do realize that you can do static addressing in IPv6 (but I sure would not want to since the manual entry of the addresses is going to be error prone on both the host and into DNS). Copy and paste is your friend. Seriously. If you're typing things in you're doing it wrong. Obviously there are a very few situations where you don't have a choice, but seriously, copy and paste. :) It is just way harder for a human to deal with hex v6 address than to easily memorize four decimal numbers in v4. Most system admins and engineers can rattle off the IPv4 address of a lot of their systems like gateways, DNS servers, domain controllers, etc. Can you imagine keeping those v6 addresses in your head the same way? Why would you bother? That's what DNS is for. Also, see above, where you can establish patterns that make this easier for the very few situations where you actually have to use addresses, and also easier to spot check them when you do. Think about reading them over the phone, typing them into a support case, typing a configuration sheet to be entered by some remote hands etc. I am not saying it is insurmountable, it is just something people need to get used to. To me, that is the biggest reason not to do more manual assignments than we need to. I do understand why they need to be the way they are but I can't see anyone thinking IPv6 addresses are easier to read and handle. No one said easier. Just different. And not hard to learn as you work with them over time. It is not a misconception that most server guys are used to static addressing and not auto-assignment. See the other messages where we talked about how static addressing for services is not a problem for IPv6. I also takes some time to get people to stop hardcoding static addressing into system configurations. There are lots of applications that have dialog boxes asking for addresses instead of names. That needs to stop in an auto-configured or DHCP environment Yes, things are different ... one could even argue better, but yes, different. (yeah, I know all about DHCP reservations but I hate them). They aren't that bad, but made much easier with a good IPAM. :) Your comment regarding small networks not needing IPv6 is exactly my point. The original post was talking about MANDATING the use of IPv6 to the exclusion of (or taxation of) IPv4. My point is that there is not really a need to do so in a lot of use cases. Is there a huge advantage to stop using RFC1918 addressing within our network? No, not really. You've obviously never had to renumber two large internal networks after a merger. Would I build a completely new enterprise on IPv4...probably not. Would I recommend that every global enterprise eradicate the use of IPv4 in the next couple of yearsno. No serious person is doing that. hope this helps, Doug
Re: IPv6 Pain Experiment
Doug Barton wrote: Automatic renumbering involving DNS was important design goal of IPv6 with reasons. Lack of it is still a problem. Meanwhile, the thing that most people miss about IPv6 is that except in edge cases, you never have to renumber. You get a massive address block that you can use as long as you pay your bill. That is called "provider lock-in", which is the primary reason, when IPng WG was formed, why automatic renumbering is necessary for IPv6. So, again, stop spreading FUD. Look at the fact that IPv6 failed badly. Masataka Ohta
Re: IPv6 Pain Experiment
Mark Andrews wrote: Please explain how https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ would not work. Update messages are designed to be forwarded and that includes signed UPDATE messages be they TSIG or SIG(0). Named already forwards UPDATE messages if your tell it to. Forward to which IP address of the primary? Unupdated one? We already have UPDATE clients that lookup SRV records to send UPDATE With SRV? You introduce yet another server, address of which may also be updated!? Congratulations, you have made barely solvable problem unsolvable. Masataka Ohta
Re: IPv6 Pain Experiment
On 10/3/19 5:35 PM, Masataka Ohta wrote: Doug Barton wrote: Not if you configure your services (like DNS) with static addresses,which as we've already discussed is not only possible, but easy. That's your opinion. But, as Mark Andrews said: > Actually you can do exactly the same thing for glue. If Mark wants to do that on his network, he can. That doesn't mean that you have to. I show it not so easy. No, you've shown that there are ways to do things differently than using static addresses for your services. > Please stop spreading FUD regarding this topic. Automatic renumbering involving DNS was important design goal of IPv6 with reasons. Lack of it is still a problem. If you're talking clients (system using only outbound connections) then they will renumber with SLAAC+DHCPv6 the same way that IPv4 clients renumber with DHCP now. If you're talking about services (with inbound connections) then yes, IF you ever have to renumber, AND you use static addresses instead of SLAAC, you'll have to do them by hand. But weren't you just arguing that dynamic addresses for services is a bad thing? Which way do you want it? Because you can have it either way. In fact, you can have it BOTH ways if you want it, depending on the service. I find static addresses for services easier myself, but Mark is a lot smarter than I am, so I'm perfectly ready to be proven wrong. Meanwhile, the thing that most people miss about IPv6 is that except in edge cases, you never have to renumber. You get a massive address block that you can use as long as you pay your bill. The chance that you'll have to renumber, ever, is incredibly small. So, again, stop spreading FUD. Doug
Re: IPv6 Pain Experiment
John Levine wrote: Automatic renumbering involving DNS was important design goal of IPv6 with reasons. News flash: nobody used the A6 RRTYPE which was intended to support IPv6 renumbering. In 2002, RFC 3363 made A6 experimental. In 2012, RFC 6563 made A6 historic. These days we all use , and we assign static addresses to our IPv6 servers. FYI, A6 is totally useless for automatic renumbering. Masataka Ohta
Re: IPv6 Pain Experiment
> On 4 Oct 2019, at 10:35 am, Masataka Ohta > wrote: > > Doug Barton wrote: > >> Not if you configure your services (like DNS) with static addresses,which as >> we've already discussed is not only possible, but easy. > > That's your opinion. But, as Mark Andrews said: > > > Actually you can do exactly the same thing for glue. > > I show it not so easy. For TSIG % nsupdate zone com update del ns1.example.com a update add ns1.example.com 3600 in a 1.2.3.4 key [hmac:]keyname secret send % For SIG(0) % nsupdate -k keyfile zone com update del ns1.example.com a update add ns1.example.com 3600 in a 1.2.3.4 send % Please explain how https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ would not work. Update messages are designed to be forwarded and that includes signed UPDATE messages be they TSIG or SIG(0). Named already forwards UPDATE messages if your tell it to. We already have UPDATE clients that lookup SRV records to send UPDATE messages to dedicated servers. You home router may contain one of them today. If you have a Mac it already includes such a client. See System Preferences/Sharing/Edit/Use Dynamic Global Hostname which allows you to specify the TSIG key to update the DNS entries for the Mac. That looks for a SRV record before falling back to the nameservers for the zone. Apple registered the SRV prefix a decade or so ago. None of this is technically hard to do. It’s bolting together existing stuff. It just requires a willingness to deploy. Ask for it and it will appear. This isn’t a technical problem. It is a political problem. > > Please stop spreading FUD regarding this topic. > > Automatic renumbering involving DNS was important design goal > of IPv6 with reasons. > > Lack of it is still a problem. > > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Pain Experiment
In article you write: >Doug Barton wrote: > >> Not if you configure your services (like DNS) with static addresses, >> which as we've already discussed is not only possible, but easy. Yup. >Automatic renumbering involving DNS was important design goal >of IPv6 with reasons. News flash: nobody used the A6 RRTYPE which was intended to support IPv6 renumbering. In 2002, RFC 3363 made A6 experimental. In 2012, RFC 6563 made A6 historic. These days we all use , and we assign static addresses to our IPv6 servers. R's, John
Re: IPv6 Pain Experiment
On 10/3/19 5:34 PM, John Levine wrote: In article you write: that gets me on to my small annoyance... /64 bit subnet masks for local networks. really? Yup. Making everything is a /64 is the best because means never again having to waste brain cycles on right-sizing subnets. And the total space is large enough that you're not shooting yourself in the foot anytime soon.
Re: IPv6 Pain Experiment
Doug Barton wrote: Not if you configure your services (like DNS) with static addresses, which as we've already discussed is not only possible, but easy. That's your opinion. But, as Mark Andrews said: > Actually you can do exactly the same thing for glue. I show it not so easy. > Please stop spreading FUD regarding this topic. Automatic renumbering involving DNS was important design goal of IPv6 with reasons. Lack of it is still a problem. Masataka Ohta
Re: IPv6 Pain Experiment
In article you write: >that gets me on to my small annoyance... /64 bit subnet masks for >local networks. really? Yup. > ALL of that address space and then throw such >a large range away on subnets commonly populated >with no more than a couple of hundred clients...maybe a few thousand >at worst. what a mistake. Nope. The whole point of 128 bit addresses is that you can waste bits with wild abandon. My upstream originally assigned me a /64 but since I have two network segments, they gave me a /48, of which I am using two /64s. Since they have a /32, they won't run short of /48's until they have 65,000 clients with multi segment networks, which will take a very long time. In the unlikely event that happens, they can upgrade their /32 to a /31, since ARIN allocates the /32's with slop between them. The programming and configuration is much easier since we can always assume that every network will have a /64 and no more and no less. >I come from a background where we had IPv4/DECNET/AppleTalk/IPX all >around the place - Unlike all of them, one mistake that IPv6 did *not* make was to make addresses too short. In the same way, IPv6 ULAs are a lot better than IPv4 RFC1918 space. So long as you follow the spec and pick a truly random ULA prefix, even if your networks later merge with others the chances of ULAs colliding rounds to zero.
Re: IPv6 Pain Experiment
On Thu, Oct 03, 2019 at 03:20:50PM +, Naslund, Steve wrote:
> Can you imagine keeping those v6 addresses in your head the same way?
I don't have to imagine, I do it on a daily basis. Doesn't seem to cause me
any grief.
In my experience, IPv4 addresses which need to be used directly on a regular
basis tend to follow certain patterns or rules of thumb ("default gateway is
on the (first|last) address in the range", for instance), and the same thing
tends to happen with similarly situated IPv6 addresses.
- Matt
RE: IPv6 Pain Experiment
--- aar...@gvtc.com wrote: From: "Aaron Gould" Thank God for DNS ;) No, just Paul Mockapetris... :-) https://en.wikipedia.org/wiki/Paul_Mockapetris scott
Re: IPv6 Pain Experiment
On 10/3/19 13:13, Mark Andrews wrote: On 4 Oct 2019, at 4:35 am, Seth Mattinen wrote: On 10/2/19 15:03, Naslund, Steve wrote: In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers. That stuff I expect to support v6. This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an obsolete appliance, etc. The dumb legacy app that supports the ancient obsolete pen plotter that we must keep forever, etc. Using the plotter example, why is it obsolete and must be replaced if it still works? It's a waste of money to dump fully functional hardware because software. The argument to justify its replacement needs to be something along the lines of the new plotter will output faster and save X hours a day which is equal to Y hours of time over a year. Not that the new one supports IPv6 and yeah that's about it. Oh the new one also supports TLSv1.3 to make sure your plots can't be intercepted by your cube neighbor as you walk across the office. Firstly adding IPv6 doesn’t remove IPv4. I know that. What I'm trying to say is that many companies aren't willing to throw away working equipment to gain a nebulous (to them) software feature like IPv6 that doesn't improve on its hardware functional state.
Re: IPv6 Pain Experiment
> On 4 Oct 2019, at 4:35 am, Seth Mattinen wrote: > > On 10/2/19 15:03, Naslund, Steve wrote: >> In my experience, the biggest hurdle to installing a pure IPv6 has nothing >> to do with network gear or network engineers. That stuff I expect to >> support v6. This biggest hurdle is the dumb stuff like machinery >> interfaces, surveillance devices, the must have IP interface on such and >> such of an obsolete appliance, etc. The dumb legacy app that supports the >> ancient obsolete pen plotter that we must keep forever, etc. > > > Using the plotter example, why is it obsolete and must be replaced if it > still works? It's a waste of money to dump fully functional hardware because > software. The argument to justify its replacement needs to be something along > the lines of the new plotter will output faster and save X hours a day which > is equal to Y hours of time over a year. Not that the new one supports IPv6 > and yeah that's about it. Oh the new one also supports TLSv1.3 to make sure > your plots can't be intercepted by your cube neighbor as you walk across the > office. Firstly adding IPv6 doesn’t remove IPv4. The plotter is one piece of legacy gear that almost certainly doesn’t need to be reached from the other side of the planet and even when the core is IPv6-only, it can still be reached via NAT64 or IPv4 tunnels. Yes, your home router will likely get a check box on its static DHCP page saying NAT64 this entry and many be even add a DDNS entry for it as well. I’m pretty sure I could configure a LEDE (OpenWRT) box to do this today. Throw a Raspberry Pi (or similar) in front of the plotter (or even the whole shop floor) with NAT64 configured and it is now IPv6 capable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Pain Experiment
On Thu, 03 Oct 2019 20:11:23 +0100, Alan Buxey said: > trivial-ish (these days) - you have so much choice...and eventually > decent routers doing SLAAC will finally be able to serve > other details such as DNS/time/etc via SLAAC - servers? give them Well... if you want that... > that gets me on to my small annoyance... /64 bit subnet masks for > local networks. really? ALL of that address space and then throw such Then using a /96 isn't going to work very well. You don't want SLAAC, /96's work just fine. pgp4Rt_y3Fp2A.pgp Description: PGP signature
RE: IPv6 Pain Experiment
Thank God for DNS ;) -aaron -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Alan Buxey Sent: Thursday, October 3, 2019 2:22 PM To: Naslund, Steve Cc: nanog@nanog.org Subject: Re: IPv6 Pain Experiment hi, > Go ahead and read your v4 address over the phone and then do the same with > your v6 address. Which is easier? I do understand all about these addresses > both being binary underneath ( I've been doing this for over 30 years now). > However it is much easier to communicate using four decimal octets. ::1 so much quicker than 127.0.0.1 ;-) > People generally do not like change and being forced to learn something new. some people dont... but its called progress. I'd have to worry about someone whose only experience is of TCP/IP networking (and only IPv4 at that). do they also get wobbly when their data is now on a big broadcast collision domain network after all those years of moving it to a switched system? >That is just human nature. You have to give them a reason to want to do it >(more money, better service, less long term cost, etc.). the ability to communicate to the rest of the growing world where IPv4 addresses just arent there anymore? >It is hard to make the case to eliminate v4 in use cases where it is working >perfectly fine (especially RFC1918 inside an enterprise). 2 things on this. just an internal network? yes, you could say 'why bother'? I *could* think about being in that campbut actually, i'd stick the security hat on and say, just like I did with wireless 'we dont have any wireless' - oh really? without being in the domain and having kit that will detect it/trace its source etc how will you know int he IPv6 world...if you arent the one controlling it on your network (and reporting on it) then you will have clients happily talking to each other on it, tunnelling it around the place (hello all those TEREDO tunnels) and being the router for traffic. all the fun with ff02::1 on your local segment ;-) alan
Re: IPv6 Pain Experiment
hi, > Go ahead and read your v4 address over the phone and then do the same with > your v6 address. Which is easier? I do understand all about these addresses > both being binary underneath ( I've been doing this for over 30 years now). > However it is much easier to communicate using four decimal octets. ::1 so much quicker than 127.0.0.1 ;-) > People generally do not like change and being forced to learn something new. some people dont... but its called progress. I'd have to worry about someone whose only experience is of TCP/IP networking (and only IPv4 at that). do they also get wobbly when their data is now on a big broadcast collision domain network after all those years of moving it to a switched system? >That is just human nature. You have to give them a reason to want to do it >(more money, better service, less long term cost, etc.). the ability to communicate to the rest of the growing world where IPv4 addresses just arent there anymore? >It is hard to make the case to eliminate v4 in use cases where it is working >perfectly fine (especially RFC1918 inside an enterprise). 2 things on this. just an internal network? yes, you could say 'why bother'? I *could* think about being in that campbut actually, i'd stick the security hat on and say, just like I did with wireless 'we dont have any wireless' - oh really? without being in the domain and having kit that will detect it/trace its source etc how will you know int he IPv6 world...if you arent the one controlling it on your network (and reporting on it) then you will have clients happily talking to each other on it, tunnelling it around the place (hello all those TEREDO tunnels) and being the router for traffic. all the fun with ff02::1 on your local segment ;-) alan
Re: IPv6 Pain Experiment
hi,
the old UK reverse name notation actually comes from some sensible
ideas - firstly from the big-endian processing methods - but also the
most important part of the address
comes first - ideal for global routing decisions early. who cares
about the actual hostname , get to the actual TLD ;-)
anyway, a little unfair as that decision was made before the Internet
domain standard was agreed/established. hey, competing systems...one
of them usually wins. in this case the
other one did ;-)
as for IPv6, the topic of this thread. having done campus IPv6
deployments, working out addressing schemes, sorting out kit upgrades
(and broken by many 'oh, IPv6 is in a future
release' or 'its on our roadmap' vendor promises) a few things. it
gives us native end to end on a network that is now too big to handle
that with IPv4 - NAT etc causing all kinds of new
things to be cooked up to ensure things dont break. deploying it is
trivial-ish (these days) - you have so much choice...and eventually
decent routers doing SLAAC will finally be able to serve
other details such as DNS/time/etc via SLAAC - servers? give them
static addresses...simple ones that dont populate all the last half...
that gets me on to my small annoyance... /64 bit subnet masks for
local networks. really? ALL of that address space and then throw such
a large range away on subnets commonly populated
with no more than a couple of hundred clients...maybe a few thousand
at worst. what a mistake.
I come from a background where we had IPv4/DECNET/AppleTalk/IPX all
around the place - to be honest, 2 fairly simply IP protocols being
handled/routed has never kept me up at night
and I enjoyed many times of cleaning things up and getting people to
realise what access their systems needed...a quick refresh of access
rules (on hosts and in network kit) and
monitoring ('you monitor that service on its IPV4...why not IPv6' was
said way too many times)
address format? at least you can put :c01d:c0ff:ee and dead:beef etc
in your addresses... as others have said, IPv4 is only a number in a
superficial sense (who HASNT been burnt
by an engineer putting a few 0's into IP address boxes on kit that
forces all fields to be populated? we had A6 and mess, things
took a while to iron out and just like
BSD dying, IPv6 deployment (and DNSSEC!) just really hasnt been
'completed' yet. but thats okay, because I'm still curious why the US
techies didnt just bite the bullet and
got for IPv8 ;-)
alan
Re: IPv6 Pain Experiment
On 10/2/19 15:03, Naslund, Steve wrote: In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers. That stuff I expect to support v6. This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an obsolete appliance, etc. The dumb legacy app that supports the ancient obsolete pen plotter that we must keep forever, etc. Using the plotter example, why is it obsolete and must be replaced if it still works? It's a waste of money to dump fully functional hardware because software. The argument to justify its replacement needs to be something along the lines of the new plotter will output faster and save X hours a day which is equal to Y hours of time over a year. Not that the new one supports IPv6 and yeah that's about it. Oh the new one also supports TLSv1.3 to make sure your plots can't be intercepted by your cube neighbor as you walk across the office.
RE: IPv6 Pain Experiment
>Another misconception. Humans (by and large) count in decimal, base 10. >IPv4 is not that. It only LOOKS like that. In fact, the similarity to familiar >decimal numbers is one of the reasons that people who are new to networking >stumble early on, find CIDR challenging, etc. Go ahead and read your v4 address over the phone and then do the same with your v6 address. Which is easier? I do understand all about these addresses both being binary underneath ( I've been doing this for over 30 years now). However it is much easier to communicate using four decimal octets. >I do understand that the hex thing presents a (small) learning curve. >But work with it for a little while and it will become familiar, just like >IPv4 did. The question here is how do I convince an enterprise of the need to feel the pain of learning it and do I want to be the guy going under the bus the first time someone screws up and takes some business critical system down. People generally do not like change and being forced to learn something new. That is just human nature. You have to give them a reason to want to do it (more money, better service, less long term cost, etc.). It is hard to make the case to eliminate v4 in use cases where it is working perfectly fine (especially RFC1918 inside an enterprise). Steven Naslund Chicago IL
Re: IPv6 Pain Experiment
On 10/2/19 10:27 PM, Masataka Ohta wrote: The tricky part is in converting a domain name of a primary nameserver to IP addresses, when the IP addresses of the primary nameserver changes. If the primary nameserver ask DNS its IP address to send an update request to itself, it will get old addresses. Not if you configure your services (like DNS) with static addresses, which as we've already discussed is not only possible, but easy. Please stop spreading FUD regarding this topic. Thanks! Doug
RE: IPv6 Pain Experiment
I don’t think the issue is the readability of the addresses (although hex does confuse some people), mainly it is the length and ability to deal with any string of numbers that long for a human, and I do realize that you can do static addressing in IPv6 (but I sure would not want to since the manual entry of the addresses is going to be error prone on both the host and into DNS). It is just way harder for a human to deal with hex v6 address than to easily memorize four decimal numbers in v4. Most system admins and engineers can rattle off the IPv4 address of a lot of their systems like gateways, DNS servers, domain controllers, etc. Can you imagine keeping those v6 addresses in your head the same way? Think about reading them over the phone, typing them into a support case, typing a configuration sheet to be entered by some remote hands etc. I am not saying it is insurmountable, it is just something people need to get used to. To me, that is the biggest reason not to do more manual assignments than we need to. I do understand why they need to be the way they are but I can't see anyone thinking IPv6 addresses are easier to read and handle. It is not a misconception that most server guys are used to static addressing and not auto-assignment. I also takes some time to get people to stop hardcoding static addressing into system configurations. There are lots of applications that have dialog boxes asking for addresses instead of names. That needs to stop in an auto-configured or DHCP environment (yeah, I know all about DHCP reservations but I hate them). Your comment regarding small networks not needing IPv6 is exactly my point. The original post was talking about MANDATING the use of IPv6 to the exclusion of (or taxation of) IPv4. My point is that there is not really a need to do so in a lot of use cases. The basic issue is that many system administrators know how to set up and configure IPv4 and a lot less of them know how to do IPv6, over time that will change but for now it is an indisputable fact. If I want to go to IPv6 across the board, I suppose I could do the education and drag them into it. However as long as my public facing interfaces are mostly fronted by firewalls and load balancers I can just do IPv6 at the border and be done with it for now. Will it hurt anyone the leave the existing v4 address assignments there as well? No, not really. Is there a huge advantage to stop using RFC1918 addressing within our network? No, not really. Would I build a completely new enterprise on IPv4...probably not. Would I recommend that every global enterprise eradicate the use of IPv4 in the next couple of yearsno. Steven Naslund Chicago IL On 10/2/19 5:54 PM, Matt Hoppes wrote: > I disagree on that. Ipv4 is very human readable. It is numbers. > > Ipv6 is not human numbers. It’s hex, which is not how we normally county. > > It is all water under the bridge now, but I really feel like ipv6 could have > been made more human friendly and ipv4 interoperable. > >> On Oct 2, 2019, at 8:49 PM, Doug Barton wrote: >> >>> On 10/2/19 3:03 PM, Naslund, Steve wrote: >>> The next largest hurdle is trying to explain to your server guys that you >>> are going to go with all dynamically assigned addressing now >> >> Completely false, but a very common misconception. There is nothing about >> IPv6 that prevents you from assigning static addresses. >> >>> and explaining to your system admin that can’t get a net mask in v4 figured >>> out, how to configure their systems for IPv6. >> >> If they only need an outbound connection, they probably don't need any >> configuration. The instructions for assigning a static address for inbound >> connections vary by OS, but I've seen a lot of them, and none of them are >> more than 10 lines long. >> >> Regarding the previous comments about all the drama of adding DNS records, >> etc.; that is what IPAM systems are for. If you're small enough that you >> don't need an IPAM for IPv4, you almost certainly don't for IPv6. >> >> IPv6 is different, but it's not any more difficult to learn than IPv4. (You >> weren't born understanding IPv4 either.) >> >> Doug
Re: IPv6 Pain Experiment
Denis Fondras wrote: What? It's a typical configuration with glues. For example, in my organization, ns1.noc.titech.ac.jp is the primary for noc.titech.ac.jp and titech.ac.jp. Sorry, you are right, I probably haven't understood. A more artificial configuration is primary1.childzone.parentzone.example.com is the primary for parentzone.example.com and primary2.childzone.parentzone.example.com is the primary for childzone.parentzone.example.com But, note that DNS operators in the real world are so creative. Masataka Ohta
Re: IPv6 Pain Experiment
Denis Fondras wrote: What if primary.childzone.parentzone.example.com is the primary for parentzone.example.com, and childzone.parentzone.example.com? In that specific case it looks like you are asking for trouble regardless of address family :) What? It's a typical configuration with glues. For example, in my organization, ns1.noc.titech.ac.jp is the primary for noc.titech.ac.jp and titech.ac.jp. Masataka Ohta
Re: IPv6 Pain Experiment
Mark Andrews wrote: Actually you can do exactly the same thing for glue. KEY records below bottom of zone cut exactly the same way as you have A and below bottom of zone cut. The only difference is the zone listed in the UPDATE message. The tricky part is in converting a domain name of a primary nameserver to IP addresses, when the IP addresses of the primary nameserver changes. If the primary nameserver ask DNS its IP address to send an update request to itself, it will get old addresses. What if primary.childzone.parentzone.example.com is the primary for parentzone.example.com, and childzone.parentzone.example.com? Another problem is lack of redundancy that, when the primary server is down, dynamic update is impossible. > Now is that a “complicated” policy? My point is that configuring lengthy random string of security key is more painful than configuring addresses. Masataka Ohta
Re: IPv6 Pain Experiment
Actually you can do exactly the same thing for glue. KEY records below bottom
of zone cut exactly the same way as you have A and below bottom of zone
cut. The only difference is the zone listed in the UPDATE message.
zone example.com {
...
update-policy {
// allow a TSIG or SIG(0) update signed with
administrator.example.com to change anything in the zone
grant adminstrator.example.com. zonesub ANY;
// allow a TSIG or SIG(0) update signed with name X to update
anything at X
grant * self * ANY;
};
};
Now is that a “complicated” policy?
Coming soon “grant * tcp-self . PTR(1);” allow a TCP UPDATE to install a
single PTR record at the matching reverse name of the TCP source address.
https://gitlab.isc.org/isc-projects/bind9/merge_requests/2124
> On 3 Oct 2019, at 12:30 pm, Masataka Ohta
> wrote:
>
> Mark Andrews wrote:
>
>> There is also nothing stopping machines updating their addresses in
>> the DNS dynamically securely.
> Except that glue A/ can not be updated so easily
> and security configuration is even more painful than
> address configuration.
>
> Masataka Ohta
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Pain Experiment
George Michaelson wrote: Personally, I choose to favour continued deployment of IPv6. With I sometimes wish I understood why SRC was the first element off the wire, and not DST, Since rational ASIC/FPGA hardware can latch early on the SRC and begin routing faster if it appears in natural bit order first. you are saying IPv4 is better than IPv6. I do not favour the CGN v4 forever model, As NAT can be modified in backward compatible manner to preserve E2E transparency, don't mind. Masataka Ohta
Re: IPv6 Pain Experiment
Mark Andrews wrote: There is also nothing stopping machines updating their addresses in the DNS dynamically securely. Except that glue A/ can not be updated so easily and security configuration is even more painful than address configuration. Masataka Ohta
Re: IPv6 Pain Experiment
A fair comment would be "you massively mis-remember" and in both JANET-Email and IPv6 terms, I would not disagree. We're talking about things done, decisions made 35 or more years ago, to 25 years ago and my brain has had many fine beers since then. But the intent remains the same: we made choices, we have to live with them. The choices are maybe looking unwise but we cannot easily unwind them to any intent. Personally, I choose to favour continued deployment of IPv6. I believe in TCO and other terms, its a rational choice. I do not favour the CGN v4 forever model, but its going to go on for a long, long time. I ceased worrying which protocol I am using some years ago. Its not important to me, either seem to work. _G
Re: IPv6 Pain Experiment
George Michaelson wrote: Could look inside beyond first header state to see DST as payload. optimisation for ICMP feels like premature optimisation. But, its semi-rational. Frag which dropped this, was going to make IP difficult for any real use anyway, not bothered by the corner-case breaks. Coulda Woulda Shoulda So, you think traceroute useless. Masataka Ohta
Re: IPv6 Pain Experiment
On Thu, Oct 3, 2019 at 12:12 PM Masataka Ohta wrote: > > George Michaelson wrote: > > Or, why we even have SRC in the header: it does not > > inform routing. > > Primarily for ICMP. Could look inside beyond first header state to see DST as payload. optimisation for ICMP feels like premature optimisation. But, its semi-rational. Frag which dropped this, was going to make IP difficult for any real use anyway, not bothered by the corner-case breaks. Coulda Woulda Shoulda -G
