About IBM I meant that they already live in a wall garden that is limited in size to one /8.
They could move it to another realm without renumbering, and now they would have 200 times more addresses for whatever else they need. They could still own their /8 in the main internet and repurpose it as they wish… Regards, Pascal > Le 4 avr. 2022 à 19:36, Vasilenko Eduard <vasilenko.edu...@huawei.com> a > écrit : > > 240.0.01.1 address is appointed not to the router. It is appointed to Realm. > It is up to the realm owner (ISP to Enterprise) what particular router (or > routers) would do translation between realms. > > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] > Sent: Monday, April 4, 2022 7:20 PM > To: Nicholas Warren <nwar...@barryelectric.com>; Vasilenko Eduard > <vasilenko.edu...@huawei.com>; Abraham Y. Chen <ayc...@avinta.com>; Justin > Streiner <strein...@gmail.com> > Cc: NANOG <nanog@nanog.org> > Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: > 202203261833.AYC > > Hello Nicholas > > Sorry for the distraction with the names; I did not forge realm, found it in > the art. OTOH I created shaft because of elevator shaft, could have used > staircase. > > >> 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) 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. > > On address per realm, yes. The we create an IXP where my 240.0.0.1 discovers > your 240.0.0.2. > Depending on the size of the shaft, we can have an IGP, probably not BGP > though. Because The 240.0.01.1 address could litelally be the router ID and > there would be nothing else advertised inside the shaft. > > >> 2. We announce our shiny new shafts in BGP. Yes, we announce the /32 >> that is our shaft. > > Inside your realm you inject 240.0.0.0/6. You roulm router(s) attract all > traffic to the shaft. Traffic that remains inside the realm is routed > normally, no IP in IP. Traffic towards another realm has the outer 240.0.0.2 > destination. > > > >> 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. > > Or a new AA, yes > > 4? > > >> 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. > > Yes > > > >> 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 is routable on plain old normal >> internet routers, so nothing needs to be changed. (lol) > > Hopefully the routers are less subject to 240 hiccups than the hosts. I'm not > aware of code in our boxes that does anything special about it but then the > code base is large. > Now, 240 is just because F000/6 is free in IPv6 so you can literally place > the 2 IPv4 in one IPv6 /64. Otherwise there will be some nastly little > natting there too. > > 7? > >> 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. > > 8b is not suggested, because in your example I could be the Internet. > > >> 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. > > The socket be updated to could understand the AA and play ball. Or > statelesslessly NAT to IPv6, yes. This uses a well known IID that the IPv6 > stack would autoconf it automatically when handed out a prefix in the F000/6 > range. Note that it's a also /64 per host, which many have been asking for a > while. > > >> 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 😊 > > You were mostly there. Just that routing inside the shaft is probably a > single IGP with no prefix attached, just links and router IDs. > >> >> Shaft and realm are fun words. I see why they picked them. >> > > Cool 😊 > > Keep safe; > > Pascal > > >> - Nich >> >> From: NANOG <nanog-bounces+nwarren=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>; Pascal Thubert (pthubert) >> <pthub...@cisco.com>; Justin Streiner <strein...@gmail.com> >> Cc: NANOG <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] >> Sent: Saturday, April 2, 2022 12:45 AM >> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Vasilenko >> Eduard <mailto:vasilenko.edu...@huawei.com>; Justin Streiner >> <mailto:strein...@gmail.com> >> Cc: NANOG <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 >> Sent: vendredi 1 avril 2022 15:49 >> To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com; Pascal >> Thubert >> (pthubert) mailto:pthub...@cisco.com; Justin Streiner >> mailto:strein...@gmail.com >> Cc: NANOG 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] >> Sent: Friday, April 1, 2022 3:41 PM >> To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com; Justin >> Streiner mailto:strein...@gmail.com; Abraham Y. Chen >> 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> >> Sent: vendredi 1 avril 2022 14:32 >> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin >> Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen >> <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=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>; Abraham Y. Chen >> <mailto:ayc...@avinta.com> >> Cc: NANOG <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=cisco....@nanog.org> On >> Behalf Of Justin Streiner >> Sent: dimanche 27 mars 2022 18:12 >> To: Abraham Y. Chen <mailto:ayc...@avinta.com> >> Cc: NANOG <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> >> 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 >> >> >
