Very right; the stateless operation is simpler than say tunneling in MPLS. Very easy to program in asic.
The key points that make this feasible : - not trying the infeasible: any v4 to any v6 is a non goal. - legacy v4 host to legacy v4 application can still work the same long as they are deployed in the same realm. Say your bank deploys a realm as an isolation measure. Say it has legacy client server applications. It’s quite logical for the bank to deploy them in the same realm. Effectively they will not be reachable from other realms unless a nat is voluntarily installed. - A great many hosts are deployed in private networks. They could be connected to the YADA world by changing their existing nat only. This is why we need a second prefix from which the nat builds an A record from the AA to present as a replacement for the AA inside. Keep safe, Pascal Le 4 avr. 2022 à 21:14, Vasilenko Eduard <vasilenko.edu...@huawei.com> a écrit : Well, if something is stateless then it is not CGNAT, it is just a router that may be called a gateway. It is a very similar thing that we have on the border between any domains when having a different data plane: - DC (VxLAN) and Backbone (MPLS) - Backbone and Metro (both MPLS) For sure, it is better to avoid gateways because it is typically (not always) an additional hop that costs money. But the router is 3x less expensive than CGNAT. Hence, I would like to point out that the problem is 3x smaller. Ed/ From: Dave Bell [mailto:m...@geordish.org] Sent: Monday, April 4, 2022 9:21 PM To: Nicholas Warren <nwar...@barryelectric.com> Cc: Vasilenko Eduard <vasilenko.edu...@huawei.com>; Abraham Y. Chen <ayc...@avinta.com>; Pascal Thubert (pthubert) <pthub...@cisco.com>; Justin Streiner <strein...@gmail.com>; NANOG <nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC This seems pretty unworkable. We would now all need to maintain large CG-NAT boxes in the network to decasulate the traffic from a source to the subscriber. It does seem like it would be fairly stateless, it is not improving things. Assuming the end host is sending traffic with the magic header already affixed, we now need to update literally every IP stack in existence if it wants to take part. I need to update all my customer facing routers to have some fancy feature to look deep into the packet to check they are not circumventing BCP38. This all seems like a lot of work just to not deploy IPv6. Regards, Dave On Mon, 4 Apr 2022 at 15:37, Nicholas Warren <nwar...@barryelectric.com<mailto:nwar...@barryelectric.com>> wrote: The vocabulary is distracting... In practice this extends IPv4 addresses by 32 bits, making them 64 bits in total. They are referring to the top 32 bits (240.0.0.0/6<http://240.0.0.0/6>) as a “shaft.” The bottom 32 bits make up the "realm." Here is the way my teeny tiny brain understands it: 1. We get our shafts from ARIN. I get 240.0.0.1; you get 240.0.0.2. 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 that is our shaft. 3. We setup our networks to use the bottom 32 bits however we see fit in our network. (for the example, I assign my client 1.2.3.4 and you assign your client 4.3.2.1) 4. Somehow, we get DNS to hand out 64 bit addresses, probably through a AAAA and just ignoring the last 64 bits. 5. My client, assigned the address 1.2.3.4 in my realm, queries your client's address "shaft:240.0.0.2; realm 4.3.2.1" from DNS. 6. My client then sends your client a packet (IPv4 source: 240.0.0.1; IPv4 destination: 240.0.0.2; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: 4.3.2.1) 7. 240.0.0.0/6<http://240.0.0.0/6> is routable on plain old normal internet routers, so nothing needs to be changed. (lol) 8a. Your router receives the packet, and your router does special things with its shaft. (IPv4 source: 240.0.0.1; IPv4 destination: _4.3.2.1_; Next Header: 4 (IPv4); IPv4 source: 1.2.3.4; IPv4 destination: _240.0.0.2_) 8b. Alternatively, every router in your network could determine next hop by investigating the second header when the destination is your shaft. 9. Your client receives the packet and can either handle this case in a special way or translate it to a v6 address for higher level applications. No, as a matter of fact, I don't know I'm talking about. Hopefully one of the authors can correct my walkthrough of how it works 😊 Shaft and realm are fun words. I see why they picked them. - Nich From: NANOG <nanog-bounces+nwarren=barryelectric....@nanog.org<mailto:barryelectric....@nanog.org>> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <ayc...@avinta.com<mailto:ayc...@avinta.com>>; Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>>; Justin Streiner <strein...@gmail.com<mailto:strein...@gmail.com>> Cc: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC 2) When you extend each floor to use the whole IPv4 address pool, however, you are essential talking about covering the entire surface of the earth. Then, there is no isolated buildings with isolated floors to deploy your model anymore. There is only one spherical layer of physical earth surface for you to use as a realm, which is the current IPv4 deployment. How could you still have multiple full IPv4 address sets deployed, yet not seeing their identical twins, triplets, etc.? Are you proposing multiple spherical layers of "realms", one on top of the other? It is the same as what I was trying to explain to Pascal. How to map the 2-level hierarchy of the draft (“Shaft”:”Realm”) to the real world? I am sure that it is possible to do this if assume that the real world has 2 levels of hierarchy where the high level is “BGP AS”. “BGP AS” is the name that everybody understands, No need for a new name “Shaft”. Ed/ From: Abraham Y. Chen [mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>>; Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>>; Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>> Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hi, Pascal: 1) " ... for the next version. ... ": I am not sure that I can wait for so long, because I am asking for the basics. The reason that I asked for an IP packet header example of your proposal is to visualize what do you mean by the model of "realms and shafts in a multi-level building". The presentation in the draft sounds okay, because the floors are physically isolated from one another. And, even the building is isolated from other buildings. This is pretty much how PBX numbering plan worked. 2) When you extend each floor to use the whole IPv4 address pool, however, you are essential talking about covering the entire surface of the earth. Then, there is no isolated buildings with isolated floors to deploy your model anymore. There is only one spherical layer of physical earth surface for you to use as a realm, which is the current IPv4 deployment. How could you still have multiple full IPv4 address sets deployed, yet not seeing their identical twins, triplets, etc.? Are you proposing multiple spherical layers of "realms", one on top of the other? 2) When I cited the DotConnectAfrica graphic logo as a visual model for the EzIP deployment over current IPv4, I was pretty specific that each RAN was tethered from the current Internet core via one IPv4 address. We were very careful about isolating the netblocks in terms of which one does what. In other words, even though the collection of RANs form a parallel cyberspace to the Internet, you may look at each RAN as an isolated balloon for others. So that each RAN can use up the entire 240/4 netblock. Please clarify your configuration. Thanks, Abe (2022-04-01 17:44) On 2022-04-01 10:55, Abraham Y. Chen wrote: On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote: Makes sense, Abe, for the next version. Note that the intention is NOT any to ANY. A native IPv6 IoT device can only talk to another IPv6 device, where that other device may use a YATT address or any other IPv6 address. But it cannot talk to a YADA node. That’s what I mean by baby steps for those who want to. Keep safe; Pascal From: Abraham Y. Chen mailto:ayc...@avinta.com<mailto:ayc...@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>; Pascal Thubert (pthubert) mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>; Justin Streiner mailto:strein...@gmail.com<mailto:strein...@gmail.com> Cc: NANOG mailto:nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hi, Pascal: What I would appreciate is an IP packet header design/definition layout, word-by-word, ideally in bit-map style, of an explicit presentation of all IP addresses involved from one IoT in one realm to that in the second realm. This will provide a clearer picture of how the real world implementation may look like. Thanks, Abe (2022-04-01 09:48) On 2022-04-01 08:49, Vasilenko Eduard wrote: As I understand: “IPv4 Realms” between “Shaft” should be capable to have a plain IPv4 header (or else why all of these). Then Gateway in the Shaft should change headers (from IPv4 to IPv6). Who should implement this gateway and why? He should be formally appointed to such an exercise, right? Map this 2 level hierarchy to the real world – you may fail with this. Ed/ From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>; Justin Streiner mailto:strein...@gmail.com<mailto:strein...@gmail.com>; Abraham Y. Chen mailto:ayc...@avinta.com<mailto:ayc...@avinta.com> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hello Eduard: Did you just demonstrate that POPs cannot exist? Or that there cannot be a Default Free Zone? I agree with your real world issue that some things will have to be planned between stake holders, and that it will not be easy. But you know what the French say about “impossible”. Or to paraphrase Sir Arthur, now that we have eliminated all the impossible transition scenarios, whatever remains… There will be YADA prefixes just like there are root DNS. To be managed by different players as you point out. And all routable within the same shaft. Keep safe; Pascal From: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>>; Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>>; Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hi Pascal, In general, your idea to create a hierarchy is good. In practice, it would fail because you have created a virtual hierarchy that does not map to any administrative border. Who should implement gateways for the “Shaft”? Why? If you would appoint Carrier as the Shaft responsible then it is not enough bits for Shaft. If you would appoint Governments as the Shaft responsible then would be a so big scandal that you would regret the proposal. Hence, I do not see proper mapping for the hierarchy to make YADA successful. Eduard From: NANOG [mailto:nanog-bounces+vasilenko.eduard<mailto:nanog-bounces%2Bvasilenko.eduard>=huawei....@nanog.org<mailto:huawei....@nanog.org>] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>>; Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC For the sake of it, Justin, I just published https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/. The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. For some people that might be enough and I’m totally fine with that. Keep safe; Pascal From: NANOG <mailto:nanog-bounces+pthubert<mailto:nanog-bounces%2Bpthubert>=cisco....@nanog.org<mailto:cisco....@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>> Subject: 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 <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> 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. Virus-free. https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link
