Re: Let's Focus on Moving Forward Re: V6 still not supported
james.cut...@consultant.com wrote: > I have yet to find an economical way to manage a business merger > involving two large rfc1918 networks where end to end peering is > required and which partially or fully overlap. As you mention "overlap", you should mean business merger implies network and office merger, which causes relocation of a office, which, in general, requires provider change and renumbering of globally unique addresses, unless you own /24. > Ignoring short-sighted > financial management views, the best long term solution is globally > unique IPv6 addressing wherever possible. See above. Or, if you mean network merger remotely with VPN, small number of hosts requiring E2E transparency may be renumbered, but it is not so painful. Masataka Ohta
Re: MAP-T
JORDI PALET MARTINEZ via NANOG writes: > It comes from actual measurements in residential networks that already > offer IPv6. > > In typical residential networks, a very high % of the traffic is > Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 > enabled. I wonder about that... In our small corner of the world, Tore has these useful measurements from a dual stack "high volume" web site (a local newspaper). This is a mix of enterprise and residential users on all types of access (ethernet, HFC, GPON, DSL, pigeon): https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor.html These users have had native dual stack (DHCPv6-PD + DHCP) for 5+ years. And most of them use their operator provided CPEs where dual-stack is enabled by default. Still, as you can see, only 50% of the clients end up using IPv6. I don't know why, but assume this is caused by the client systems behind the CPE. Either they don't support IPv6 or the users have disabled it. > Typically, is also similar in mobile networks, and this has been > confirmed also by measurements in v6ops mailing list, for example from > T-Mobile. If I recall correctly that was 3-4 years ago and was already > 75% IPv6 traffic. Yes, for traditional mobile (i.e handsets) the picture is completely different. Same view shows an average of 85% IPv6 on mobile access: https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html Note that the last 3G cell was switched off in January 2021 in this network, eliminating any client older than 10 years in practice (2G is still supported, but... well, it's not going to show up on traffic volume measurments). > Enterprises usually have a lower IPv6 %, so actual numbers in a given > ISP my depend on the ratio of enterprise/residential customers. It may > also depend on the case of residentials, on the age of SmartTVs, which > may not be IPv6 enabled. Yes, this will also affect the first measurement since it is a mix of enterprise/residential. But the majority is residential, as this relative volume by time of day clearly shows: https://munin.fud.no/vg.no/www.vg.no/vg_ipv6_telenor.html In any case, I'll claim it's hard for a fixed access provider to achive much more than 50% IPv6 volume today. We'll have to start disabling IPv4 to get better results than that. Mobile is a different animal, with client systems being replaced constantly. Bjørn
Re: MAP-T
Bjørn Mork wrote on 27/03/2022 10:42: Yes, for traditional mobile (i.e handsets) the picture is completely different. Same view shows an average of 85% IPv6 on mobile access: https://munin.fud.no/vg.no/www.vg.no/vg_ds_telenor_mobil.html from the point of view of cgnat scaling, a more useful figure would be the number of ipv6 "sessions" vs natted ipv4 sessions. It's well established that many of the highest volume traffic sources on the internet are ipv6 enabled, but the long tail is definitely not. I.e. throughput is not necessarily a useful data point for substantiating many of the claims that are made here and elsewhere about ipv6 popularity. Nick
Re: Let's Focus on Moving Forward Re: V6 still not supported
On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote: > EzIP proposes to deploy 240/4 > address based RANs, each tethering off the current Internet via one IPv4 > public address. So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish. > As such, the collection of RANs forms an overlay network > layer wrapping around the current Internet core. Consequently, only the > SPRs in the RAN need to be able to transport 240/4 addressed packets. You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members. > This is why we talk about enabling new (but based on existing design) > routers to use 240/4 netblock for serving as SPRs, but not perturbing > any routers in the current Internet. As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN. It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used? > I would like to share one intriguing graphics (see URL below) that > is almost perfect for depicting the EzIP deployment configuration. > Consider the blue sphere as the earth or the current Internet core and > the golden colored land as the RANs. By connecting each continent, > country or all the way down to a Region to the earth via one IPv4 > address, we have the EzIP configuration. With this architecture, each > RAN looks like a private network. That sounds an entirely undesirable goal for the internet. brandon
Re: Let's Focus on Moving Forward Re: V6 still not supported
On 27 March 2022 15:53:25 Brandon Butterworth wrote: On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote: EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address. So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish. As such, the collection of RANs forms an overlay network layer wrapping around the current Internet core. Consequently, only the SPRs in the RAN need to be able to transport 240/4 addressed packets. You previously described this as like connecting CG-NATs together via a VPN. I don't see why we'd want to add maintaining a global VPN to already difficult peering relationships. It could be used to exlude non EzIP club members. This is why we talk about enabling new (but based on existing design) routers to use 240/4 netblock for serving as SPRs, but not perturbing any routers in the current Internet. As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN. It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. You might stand more chance if you gained some critical mass using the existing available 100.64/10 & rfc1918 space, and then those that find they need more in one RAN will make the case for 240/4 when it becomes necessary for them. Is 240/4 special to EzIP such that alternative numbers may not be used? I would like to share one intriguing graphics (see URL below) that is almost perfect for depicting the EzIP deployment configuration. Consider the blue sphere as the earth or the current Internet core and the golden colored land as the RANs. By connecting each continent, country or all the way down to a Region to the earth via one IPv4 address, we have the EzIP configuration. With this architecture, each RAN looks like a private network. That sounds an entirely undesirable goal for the internet. brandon It isn't the Internet. It's at best a very poorly connected spur gateway. Too many today don't remember the towers of Babel world prior to the Internet. If they did they'd understand that building on this type of idea is like burying yourself And any customers so unwise to get involved C
Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Abe: To your first point about denying that anyone is being stopped from working on IPv4, I'm referring to users being able to communicate via IPv4. I have seen no evidence of that. I'm not familiar with the process of submitting ideas to IETF, so I'll leave that for others who are more knowledgeable on that to speak up if they're so inclined. Thank you jms On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen wrote: > > 1)"... no one is stopping anyone from working on IPv4 ... ": > After all these discussions, are you still denying this basic issue? For > example, there has not been any straightforward way to introduce IPv4 > enhancement ideas to IETF since at least 2015. If you know the way, please > make it public. I am sure that many are eager to learn about it. Thanks. >
Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
On Fri, 25 Mar 2022, Baldur Norddahl wrote: On Fri, 25 Mar 2022 at 17:32, Joe Provo wrote: That said, prepending pretty much anything more than your current view of the Internet's diameter in ASNs is useless in practice. That is one way of viewing it. But prepending can also be used for traffic engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does not appear to discuss this at all. The depth of prepending used this way only relates to how many different classes of peers you can imagine in your setup and is not at all related to the "internet's diameter". Is prepending used for any purpose other than TE? The point I think Joe was trying to make was prepending once or even a few times has uses. Prepending more than a few times is unlikely to accomplish anything a few prepends didn't get done. Prepending 50, 100, 200+ times is kind of a universal "We have no clue what we're doing and you should reject our routes." Once upon a time, such long prepends would break certain BGP implementations, causing session resets when a route like this was encountered. Hopefully, that's not a problem anymore, but enough networks likely still block excessive prepends that you shouldn't expect to be able to do this and have your route globally accepted...just like you can't advertise a v4 /25 and expect global reachability if there are no covering aggregate advertisements. The interesting question here is, "did they really think a few more prepends would get the job done?" or did they misunderstand their router's prepend function, prepend 21299 (thinking they were telling it to prepend their ASN), and that got truncated because the syntax was actually telling it how many times to prepend the local AS? I'm guessing the latter, as they seem to have 254 prepends, and I'm guessing 255 is the max number of instances of their ASN their router is willing to put on an advertised route. -- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Hi, Justin: 1) " denying that anyone is being stopped from */working on/* IPv4, I'm referring to users being able to */communicate via /*IPv4. ": The two topics are quite different. It looks that we may have some language issues here. So, allow me to stop. Regards, Abe (2022-03-27 12:31) On 2022-03-27 12:11, Justin Streiner wrote: Abe: To your first point about denying that anyone is being stopped from working on IPv4, I'm referring to users being able to communicate via IPv4. I have seen no evidence of that. I'm not familiar with the process of submitting ideas to IETF, so I'll leave that for others who are more knowledgeable on that to speak up if they're so inclined. Thank you jms On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen wrote: 1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Let's Focus on Moving Forward Re: V6 still not supported
> On Mar 27, 2022, at 5:00 AM, Masataka Ohta > wrote: > > james.cut...@consultant.com wrote: > > > I have yet to find an economical way to manage a business merger > > involving two large rfc1918 networks where end to end peering is > > required and which partially or fully overlap. > > As you mention "overlap", you should mean business merger implies > network and office merger, which causes relocation of a office, Overlap here refers to network address space address space, a fundamental part of this discussion. Formerly separate networks containing separately managed rfc1918 spaces are prone to overlap require ingenious solutions for end-to-end traffic without renumbering. Mergers do not cause relocation of an office, which is not germane to this discussion. > which, in general, requires provider change and renumbering > of globally unique addresses, unless you own /24. Moot since we are not discussing office moves. However, renumbering to global IPv6 addressing allows easy coexistence with the global Internet > > > Ignoring short-sighted > > financial management views, the best long term solution is globally > > unique IPv6 addressing wherever possible. > > See above. See previous. > > Or, if you mean network merger remotely with VPN, small > number of hosts requiring E2E transparency may be renumbered, > but it is not so painful. Nobody mentioned VPN or limiting the number of hosts requiring E2E. “not so painful” is not meaningful metric in this discussion. > > Masataka Ohta
Re: Let's Focus on Moving Forward Re: V6 still not supported
According to james.cut...@consultant.com : >> which, in general, requires provider change and renumbering >> of globally unique addresses, unless you own /24. > >Moot since we are not discussing office moves. However, renumbering to global >IPv6 addressing allows easy coexistence with the global Internet Alternatively, if you have network addresses that you want to be sure don't leak to the global Internet, ULAs work well, too. If you pay attention to RFC 4193 and select your Global ID randomly, when you merge two networks there is no meaningful chance that the ULAs will overlap. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Re: Let's Focus on Moving Forward Re: V6 still not supported
On Sat, Mar 26, 2022, 21:42 John Gilmore wrote: > > Today Google is documenting to its cloud customers that they should use > 240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for > the citation.) We have received inquiries from two other huge Internet > companies, which are investigating or already using 240/4 as private > IPv4 address space. > I think the advice in the draft, and on the quoted page of Google cloud docs is that you can use whatever address space you want for your voc network. I think it also says that choosing poorly could make portions if the internet unreachable. I don't see that the docs specify usage of 240/4 though. >
Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC
Hi, Randy: 1) " ... does not mean it is trivial to get it done on *billions* of device. ... ": It looks that your mind is focused on upgrading existing IoTs. They are not to be perturbed according to the initial and short term EzIP deployment plans, because it basically is following the existing CG-NAT network configuration and master / client service model. Many RGs (Residential / Routing Gateways) are already capable of being a 240/4 DHCP client. (If not, commenting out one single line is likely all what is needed.). For the long term, it will be only those*/new/* IoTs desiring for end-to-end communication across RAN borders to have the ability of handling Option Words in the IP header. 2) " ... Your refusal to follow simple mailing list etiquette ... ": Sorry for the inconvenience that I have caused. Honestly, I am still trying to figure out what is the "required" etiquette, since what I have received were mostly "complaints" not constructive "instructions" (i.e., how about a cheat sheet of what to do and what not to?). So, I have been adjusting my writing style. (My best guess of the issue is mostly likely due to the Subject line which according to my business correspondence training is my own choice. I am baffled by why does it cause problems on this mailing list.) Regards, Abe (2022-03-27 15:16) On 2022-03-26 18:53, Randy Carpenter wrote: - On Mar 26, 2022, at 6:16 PM, Abraham Y. chenayc...@avinta.com wrote: Hi, Tom & Paul: 1) " ... hand waved ... ": Through my line of work, I was trained to behave exactly the opposite. I am surprised at you jumping to the conclusion, even before challenging me about where did I get my viewpoint from. The fact is, it has been clearly documented in our IETF draft for the last couple years (since Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the potential target code fragment and critique. It appears to me that our software member suggested to comment out only one line (1047). Just because it is trivial to make the modification in a single, specific firmware for one particular device sdoes not mean it is trivial to get it done on *billions* of device. Even if each one was as trivial as your example, it would still be ludicrously difficult. Beyond that, I am still not understanding what you are actually trying to propose here. Your refusal to follow simple mailing list etiquette even after numerous requests makes it very difficult to decipher what you are saying. -Randy -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC
Sent using a machine that autocorrects in interesting ways... > On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen wrote: > > Honestly, I am still trying to figure out what is the "required" etiquette, > since what I have received were mostly "complaints" not constructive > "instructions" (i.e., how about a cheat sheet of what to do and what not to?). I suspect there are two important rules. 1) every mailing list has a topic. Post on that topic. 2) a mailing list discussion is a conversation. We all get involved in conversations every day. Act as you would in polite conversation.
Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC
Sent using a machine that autocorrects in interesting ways... > On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen wrote: > > I am baffled by why does it cause problems on this mailing list. Are you aware that NANOG is not an IETF list? What would you guess might be the topic of a list associated with a Network Operator Group? Permit me to comment on what I have seen in this discussion, and what I haven’t seen. I would guess that your objective is primarily to build a constituency for a replacement paradigm for the Internet - instead of connectivity between endpoints, you want it to be connectivity between PABX-like islands. What I have observed is a steady patter of email indicating that everyone except you is wrong. What I have not observed is an emerging consensus in the direction your posted draft suggests. Food fir thought.
Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
On Sun, 27 Mar 2022 at 18:31, Jon Lewis wrote: > Is prepending used for any purpose other than TE? The point I think Joe > was trying to make was prepending once or even a few times has uses. > Prepending more than a few times is unlikely to accomplish anything a few > prepends didn't get done. > I suppose so-called "backup routes" could also be called traffic engineering yet it is different from the use case I described. I understand the "diameter of the internet" to mean the maximum number of unique AS numbers in an AS PATH observed in any route in my DFZ routing table. Say I have two IP transit uplinks and I want one to be strictly backup meaning I want to receive no traffic unless the other is down. I might then prepend at least "the diameter of the internet" and that would be enough. Any more prepends will do nothing. This could probably be proven mathematically for the worst case, although in reality you would not even need that many prepends to get the effect. However using prepends for traffic engineering in the sense prioritizing my peers relatively to each other is completely different. Especially true when some are peers on internet exchanges (not IP transit). Here the diameter of the internet is completely irrelevant. What matters is the number of classes I can make up for my peers. I admit those two numbers might not be all that different, but I feel it is still worth pointing out the error in the logic. The logic is wrong even for the backup case. Say I have an extreme of N x IP transits and I want all of them to be backups in a strict order. Such that all traffic comes in on transit A. If transit A is down, then everything should use B. If A and B are down then 100% to C etc. In that case I would need to prepend "the diameter of the internet" on B and "the diameter of the internet" times two on C etc. Why times two and not + 1? Because when A is down we have B with a number of prepends. C needs to have "the diameter of the internet" more than B to be sure no traffic goes that way when B is active. Prepending 50, 100, 200+ times is kind of a universal "We have no clue > what we're doing and you should reject our routes." > That is likely yes. Regards, Baldur
Re: Let's Focus on Moving Forward Re: V6 still not supported
Hi, Brandon: 1) "So each RAN has no possibility of redundant connections? .. ": There is difference between "via one IPv4 public address" and "wide bandwidth or multiple channels". The former is called "numbering plan". The latter is part of "traffic engineering". The former defines the configuration / architecture of the latter, but not restricts its capability. One simple analogy is that a corporation headquarters publishes only one (representative) telephone number. But, everyone knows that there are multiple physical channels to carry the simultaneous conversations. So, we discuss about network architecture here. Then, the implementation engineering will take care of the details. 2) " It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish. ... ": The EzIP scheme provides an alternative to the current "Internet way" operation model and can operate in parallel while none-interfering to each other. There is no intention for EzIP to replace the current Internet. The hope is to let the two models operate in real time for the consumer to make the informed choice, as in a free market. 3) " You previously described this as like connecting CG-NATs together via a VPN. ... ": I do not believe that I have ever mentioned VPN in any of our literature, nor correspondence. I would appreciate learning where did you find such a connection. 4) " As it's a CG-NAT variant why are you delaying yourself by requiring new address space that will take a long time to become available? ": As it has become evident recently through various posting, the 240/4 netblock has been used "behind-the-scene" by many projects without the explicit permission by ICANN. Since packets with 240/4 addressing get dropped by existing routers, it actually makes the deployment of the new project easier. EzIP can be deployed in the same fashion as well. However, with the Unicast Extension Project became known, we would like to go along with their efforts to make the EzIP process more "Kosher". 5) "... Why not use the already allocated space for CG-NAT? Sure it's only a /10 but that's an already (probably too) large RAN ": The CG-NAT netblock of /10 is only one fourth of the largest private netblock 10/8. So, it is not big enough for the next level of challenge. Making use of the 240/4 netblock allows EzIP to serve a large enough geographical area, so that a true "Regional" Area Network characteristic may be achieved. A RAN can serve a population of upto 39M, even before employing the three conventional private netblocks. So, it is possible to experiment the wish of the "Country" networks idea proposed by ITU about one decade ago. Whether it is better or worse than the current Internet, EzIP provides a separate test bed for such, instead of verbal debates forever. 6) " It also seems unfeasibly optimistic that if the work was done globally to make 240/4 useable that they'd want to dedicate it to the as yet undeployed EzIP. ... ": As have been hinted a couple times already on this forum, the ideal EzIP initial deployment beds are the existing CG-NAT modules. All we need to do is to enable the routers in a CG-NAT module to route 240/4 netblock and retire the 100.64/10 netblock. Since every customer premises can have a static 240/4 address, the DHCP process in the CG-NAT can fade out. The current communication between this CG-NAT with the Internet core remains unchanged. This process can be done gradually, one CG-NAT module at a time. No one outside of each of such tranistin will even notice something has happened. There is no need to do this globally in one shot, at all. 7) "Is 240/4 special to EzIP such that alternative numbers may not be used? " No, nothing is special here. The only reason that 240/4 is attractive is because it is big, continuous as well as being "Reserved for Future use" for so long. It is like a never-never land, fresh enough to do something really grand and for the long term. 8) " That sounds an entirely undesirable goal for the internet. ": As I state above, EzIP offers a configuration for experimenting a (or more) parallel Internet(s). they will not interfere the current Internet, nor one another. So, what is your concern or reservation? Regards, Abe (2022-03-27 16:35) On 2022-03-27 10:49, Brandon Butterworth wrote: On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote: EzIP proposes to deploy 240/4 address based RANs, each tethering off the current Internet via one IPv4 public address. So each RAN has no possibility of redundant connections? Nobody of scale would accept such a limitation. It also looks like an opportunity for telcos/governments to partition their part of the internet and impose whatever censorship they wish. As such, the collection of RANs forms an overlay network layer wrapping
Would someone from Sling.com and Netflix contact me off-list
Would someone from Sling.com and Netflix contact me off-list I am running into issues with several of my home internet users being blocked from your services. Thanks, Anthony Leto Flying Man Studio, LLC AS393941 anth...@fms.io
