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 <aychen@avinta.com> *Sent:* vendredi 1 avril 2022 15:49 *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> *Cc:* NANOG <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:pthubert@cisco.com <mailto:pthubert@cisco.com>] *Sent:* Friday, April 1, 2022 3:41 PM *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com> <mailto:streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com> <mailto:aychen@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 <vasilenko.eduard@huawei.com> *Sent:* vendredi 1 avril 2022 14:32 *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com>; Abraham Y. Chen <aychen@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.com@nanog.org <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On Behalf Of *Pascal Thubert (pthubert) via NANOG *Sent:* Friday, April 1, 2022 2:26 PM *To:* Justin Streiner <streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com> *Cc:* NANOG <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 <nanog-bounces+pthubert=cisco.com@nanog.org> *On Behalf Of *Justin Streiner *Sent:* dimanche 27 mars 2022 18:12 *To:* Abraham Y. Chen <aychen@avinta.com> *Cc:* NANOG <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 <aychen@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.
Image removed by sender. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
That does not need to be long, Abe. There’s no minimal interval between version. I already published 01… And I do not have a special address format beyond what’s in the draft already. It’s only IPv4 and IPv6. No new address format. Just assigned ranges, and well known IIDs. To your point: the addresses in each realm are the full IPv4 that we know and they cannot talk directly between realms. They are indeed isolated. Nodes in different floors can only communicate through the shaft. Think of a human and a stairwell. The physical space reserved for the stair well at each level is the same. What people do with the rest of the space is their own. All addresses and AS numbers are reusable. I do not see you image of a sphere. My image of a sphere is IPv6, that contains all the IPv4 “planes”, the shaft, and all the air in between. You design uses the internet as shaft if you like. In that we differ. YADA leaves the internet as is, and allows to build other internets that cannot leak in one another. But participating nodes can communicate through the shaft. If end nodes do not participate, then a stateful Nat is still needed. For most homes that means an upgrade of the stateful NAT in the gateway so the public side has a YATT format, and DNS snooping to provide a A record inside. Same for PLATs. For most servers, that means an update in the load balancer, and a NAT if there was none, to allow to speak to other realms. Whatever happened in the current IPv4 can still do. Some levels can be created IPv6 only from the start, providing YATT addresses to those who need to communicate with the other levels. Keep safe; Pascal From: Abraham Y. Chen <aychen@avinta.com> Sent: vendredi 1 avril 2022 23:45 To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <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 <aychen@avinta.com><mailto:aychen@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard <vasilenko.eduard@huawei.com><mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) <pthubert@cisco.com><mailto:pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com><mailto:streinerj@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 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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com><mailto:vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com><mailto:streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com><mailto:aychen@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 <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.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 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 <nanog-bounces+pthubert=cisco.com@nanog.org<mailto:nanog-bounces+pthubert=cisco.com@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.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 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 <aychen@avinta.com<mailto:aychen@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. [Image removed by sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
Hi, Pascal: 0) As the good old saying stated: "A picture is worth one thousand words." Let's take advantage of such a teaching. 1) Focusing at just the text before and after Figure 1 of your below draft, I found: https://datatracker.ietf.org/doc/html/draft-thubert-v6ops-yada-yatt-01 A. " In the analogy of a building, */the ground floor would be the Interne/*t, and each additional floor would be */another IPv4 realm/*. ... analog to */the full IPv4/**/addressing /*that is available in each realm. ": Unless there is certain hidden refinement that I could not decipher, the combination of the three phrases highlighted above by me seems to refer to the entire IPv4 netblock, addresses and practices, etc., all inclusive. (By the way, the phrase "ground floor" appears to contradict the "(current IPv4 Internet)" label in the figure that is on the top floor (realm 1) of a building. Unless, you are presenting an underground building? But, we can regard this as a minor typo.) B. " ... A single /24 IPv4 prefix assigned allows for*/> 250 times the capacity of the Internet as we know it /*... ": Are you visualizing that your YADA / YATT draft proposes creating >250 layers of cyberspace, each with the same capacity of the current Internet? If so, it will be fantastic. Then, how can you physically deploying that many layers, each fully covering the entire globe, yet without stepping on one another's toes (the identical IP addresses packed >250 deep)? That is, I failed to imagine what kind of mechanism that you have for isolating the layers, such as populating people accordingly. Please clarify. Regards, Abe (2022-04-02 12:22 EDT) On 2022-04-02 04:56, Pascal Thubert (pthubert) wrote:
That does not need to be long, Abe.
There’s no minimal interval between version. I already published 01… And I do not have a special address format beyond what’s in the draft already. It’s only IPv4 and IPv6. No new address format. Just assigned ranges, and well known IIDs.
To your point: the addresses in each realm are the full IPv4 that we know and they cannot talk directly between realms. They are indeed isolated. Nodes in different floors can only communicate through the shaft. Think of a human and a stairwell. The physical space reserved for the stair well at each level is the same. What people do with the rest of the space is their own. All addresses and AS numbers are reusable.
I do not see you image of a sphere. My image of a sphere is IPv6, that contains all the IPv4 “planes”, the shaft, and all the air in between.
You design uses the internet as shaft if you like. In that we differ. YADA leaves the internet as is, and allows to build other internets that cannot leak in one another. But participating nodes can communicate through the shaft.
If end nodes do not participate, then a stateful Nat is still needed. For most homes that means an upgrade of the stateful NAT in the gateway so the public side has a YATT format, and DNS snooping to provide a A record inside. Same for PLATs. For most servers, that means an update in the load balancer, and a NAT if there was none, to allow to speak to other realms. Whatever happened in the current IPv4 can still do. Some levels can be created IPv6 only from the start, providing YATT addresses to those who need to communicate with the other levels.
Keep safe;
Pascal
*From:* Abraham Y. Chen <aychen@avinta.com> *Sent:* vendredi 1 avril 2022 23:45 *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com> *Cc:* NANOG <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 <aychen@avinta.com> <mailto:aychen@avinta.com> *Sent:* vendredi 1 avril 2022 15:49 *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> <mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) <pthubert@cisco.com> <mailto:pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> <mailto:streinerj@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
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:pthubert@cisco.com <mailto:pthubert@cisco.com>] *Sent:* Friday, April 1, 2022 3:41 PM *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com> <mailto:streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com> <mailto:aychen@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 <vasilenko.eduard@huawei.com> *Sent:* vendredi 1 avril 2022 14:32 *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com>; Abraham Y. Chen <aychen@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.com@nanog.org <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On Behalf Of *Pascal Thubert (pthubert) via NANOG *Sent:* Friday, April 1, 2022 2:26 PM *To:* Justin Streiner <streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com> *Cc:* NANOG <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 <nanog-bounces+pthubert=cisco.com@nanog.org> *On Behalf Of *Justin Streiner *Sent:* dimanche 27 mars 2022 18:12 *To:* Abraham Y. Chen <aychen@avinta.com> *Cc:* NANOG <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 <aychen@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.
Image removed by sender. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <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 <aychen@avinta.com><mailto:aychen@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard <vasilenko.eduard@huawei.com><mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) <pthubert@cisco.com><mailto:pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com><mailto:streinerj@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 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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com><mailto:vasilenko.eduard@huawei.com>; Justin Streiner <streinerj@gmail.com><mailto:streinerj@gmail.com>; Abraham Y. Chen <aychen@avinta.com><mailto:aychen@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 <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.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 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 <nanog-bounces+pthubert=cisco.com@nanog.org<mailto:nanog-bounces+pthubert=cisco.com@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.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 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 <aychen@avinta.com<mailto:aychen@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. [Image removed by sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
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) 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 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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
Hi Nicholas, In fact, your explanation is much better than the draft explanation. Could I propose a small modification? Every AS announces 240.0.0.0 + AS# that they already have then there is no need for "shafts from ARIN" - AS# is already distributed and unique. Eduard -----Original Message----- From: Nicholas Warren [mailto:nwarren@barryelectric.com] Sent: Monday, April 4, 2022 5:33 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC 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) 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 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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
Hello Eduard As (badly) written, all ASes and IP addresses that exist today in the internet could be either reused or moved in any parallel realm. Now that the ASN space is 32 bits, there would not be room for non-ASN based shaft routers. I fail to see the value in conflating. IBM could move 9.0.0.0 to another realm, and then grow outside of 9.0.0.0 to whatever they need inside. The YADA format would not be much worse than the socks they used at the time I was there. That's the way I prefer it, but happy to see the little bird fly from the nest and become what it likes. Keep safe; Pascal
-----Original Message----- From: Vasilenko Eduard <vasilenko.eduard@huawei.com> Sent: lundi 4 avril 2022 16:52 To: Nicholas Warren <nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Hi Nicholas, In fact, your explanation is much better than the draft explanation. Could I propose a small modification? Every AS announces 240.0.0.0 + AS# that they already have then there is no need for "shafts from ARIN" - AS# is already distributed and unique. Eduard -----Original Message----- From: Nicholas Warren [mailto:nwarren@barryelectric.com] Sent: Monday, April 4, 2022 5:33 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
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) 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 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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
Hi Pascal, The world has moved to 32bit AS# not far in the past. For sure, AS# would not cross 28bits. I do not understand why you need something different from AS# to point to the Realm. The one who would need a new realm - could go to RIR and ask for AS. Realm would be calculated automatically as 240.0.0.0+AS#. I fail to see why you continue talking about IBM property. Why do you need it? Why do you believe IBM would grant it to the community? Eduard -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Monday, April 4, 2022 7:27 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Nicholas Warren <nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hello Eduard As (badly) written, all ASes and IP addresses that exist today in the internet could be either reused or moved in any parallel realm. Now that the ASN space is 32 bits, there would not be room for non-ASN based shaft routers. I fail to see the value in conflating. IBM could move 9.0.0.0 to another realm, and then grow outside of 9.0.0.0 to whatever they need inside. The YADA format would not be much worse than the socks they used at the time I was there. That's the way I prefer it, but happy to see the little bird fly from the nest and become what it likes. Keep safe; Pascal
-----Original Message----- From: Vasilenko Eduard <vasilenko.eduard@huawei.com> Sent: lundi 4 avril 2022 16:52 To: Nicholas Warren <nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Hi Nicholas, In fact, your explanation is much better than the draft explanation. Could I propose a small modification? Every AS announces 240.0.0.0 + AS# that they already have then there is no need for "shafts from ARIN" - AS# is already distributed and unique. Eduard -----Original Message----- From: Nicholas Warren [mailto:nwarren@barryelectric.com] Sent: Monday, April 4, 2022 5:33 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
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) 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 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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
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:pthubert@cisco.com] Sent: Monday, April 4, 2022 7:20 PM To: Nicholas Warren <nwarren@barryelectric.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
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.eduard@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:pthubert@cisco.com] Sent: Monday, April 4, 2022 7:20 PM To: Nicholas Warren <nwarren@barryelectric.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
Hello Eduard In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop ack and used as router ID on the IGP inside the shaft… 240 addresses are the only ones advertised by the IGP. No prefix, Regards, Pascal
Le 4 avr. 2022 à 19:41, Pascal Thubert (pthubert) <pthubert@cisco.com> a écrit :
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.eduard@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:pthubert@cisco.com] Sent: Monday, April 4, 2022 7:20 PM To: Nicholas Warren <nwarren@barryelectric.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
Then change it. It may still be programmed on loopbacks, but treat it as anycast. -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Monday, April 4, 2022 8:50 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Cc: Nicholas Warren <nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@gmail.com>; NANOG <nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hello Eduard In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop ack and used as router ID on the IGP inside the shaft… 240 addresses are the only ones advertised by the IGP. No prefix, Regards, Pascal
Le 4 avr. 2022 à 19:41, Pascal Thubert (pthubert) <pthubert@cisco.com> a écrit :
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.eduard@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:pthubert@cisco.com] Sent: Monday, April 4, 2022 7:20 PM To: Nicholas Warren <nwarren@barryelectric.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto:streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto:streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto:aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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
On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG <nanog@nanog.org> wrote:
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.
Please forgive me as I work this out in my head for a moment. If I'm a global network with a single ASN on every populated continent on the planet, this means I would have a single Realm address; for the sake of the example, let's suppose I'm ASN 42, so my Realm address is 240.0.0.42. I have 200+ BGP speaking routers at exchange points all over the planet where I exchange traffic with other networks. In this new model, every border router I have would all use the same 240.0.0.42 address in the Shaft, and other Realms would simply hand traffic to the nearest border router of mine, essentially following a simple Anycast model where the nearest instance of the Realm address is the one that traffic is handed to, with no way to do traffic engineering from continent to continent? Or is there some mechanism whereby different instances of 240.0.0.42 can announce different policies into the Shaft to direct traffic more appropriately that I'm not understanding from the discussion? Because if it's one big exercise in enforced Hot Potato Routing with a single global announcement of your reachability... ...that's gonna fail big-time the first time there's a major undersea quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific connectivity off, and suddenly you've got the same Realm address being advertised in the US as in Asia, but with no underlying connectivity between them. https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20... We who do not learn from history are doomed to repeat it...badly. :( Matt
Hello Matthew At the moment the draft has a general architecture, and it will take the right minds and experience to turn a model into a live network. Considering what the people in this list have already built, it’s no gigantic leap to figure they can build that too. Most of the building blocks that are implicit or TBD in the draft exist already. About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The draft is not like that, all existing ASN and IP addresses can be reused in every new realm, and there does not need to be any mapping. If people find a need or a reason to add constraints, that’s beyond me at this time, and against the natural philosophy of minimizing interdependences to maintain design freedom in each realm. The draft has one and one only dependency, that surface of the shaft is common to all realms. To your point, and unrelated to ASNs, the shaft can be physically distributed. Each physical place would announce 240.0.0.0/6, and the nearest alive would attract the traffic. See it as as many IXPs. In the current draft, there’s only one shaft that links all realms. And there’s a single realm number for each realm that is advertised in every physical instances of the shaft. All that is a simplification to highlight the design. As the shaft lives on, a realm may be multihomed, the shaft might be subnetted to interconnect only specific realms, or to be advertised differently in different geographies. And then the subnets will need to be injected in the realms. The way around a breakage can be DNS, or BGP. All this is possible, you’ve already done it, and it’s really your play. We build the car, you drive it. Happy that you start figuring out how you prefer it to happen. While we figure out protocols to renumber more efficiently, fix source address selection, extend the NATs, you name it. There’s work for all and at every phase. But at this stage of the discussion, I favor the 10 miles view to get a shared basic understanding. On the side, I’d be happy to learn how you solved a situation like the one below, if there’s any article / doc? Keep safe; Pascal From: Matthew Petach <mpetach@netflight.com> Sent: mardi 5 avril 2022 0:29 To: Vasilenko Eduard <vasilenko.eduard@huawei.com> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Nicholas Warren <nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@gmail.com>; NANOG <nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: 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. Please forgive me as I work this out in my head for a moment. If I'm a global network with a single ASN on every populated continent on the planet, this means I would have a single Realm address; for the sake of the example, let's suppose I'm ASN 42, so my Realm address is 240.0.0.42. I have 200+ BGP speaking routers at exchange points all over the planet where I exchange traffic with other networks. In this new model, every border router I have would all use the same 240.0.0.42 address in the Shaft, and other Realms would simply hand traffic to the nearest border router of mine, essentially following a simple Anycast model where the nearest instance of the Realm address is the one that traffic is handed to, with no way to do traffic engineering from continent to continent? Or is there some mechanism whereby different instances of 240.0.0.42 can announce different policies into the Shaft to direct traffic more appropriately that I'm not understanding from the discussion? Because if it's one big exercise in enforced Hot Potato Routing with a single global announcement of your reachability... ...that's gonna fail big-time the first time there's a major undersea quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific connectivity off, and suddenly you've got the same Realm address being advertised in the US as in Asia, but with no underlying connectivity between them. https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20... We who do not learn from history are doomed to repeat it...badly. :( Matt
Considering this requires updating every single IP stack that wants to utilise this, what are the benefits of it other than just moving to IPv6? Regards, Dave On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG < nanog@nanog.org> wrote:
Hello Matthew
At the moment the draft has a general architecture, and it will take the right minds and experience to turn a model into a live network. Considering what the people in this list have already built, it’s no gigantic leap to figure they can build that too. Most of the building blocks that are implicit or TBD in the draft exist already.
About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The draft is not like that, all existing ASN and IP addresses can be reused in every new realm, and there does not need to be any mapping. If people find a need or a reason to add constraints, that’s beyond me at this time, and against the natural philosophy of minimizing interdependences to maintain design freedom in each realm. The draft has one and one only dependency, that surface of the shaft is common to all realms.
To your point, and unrelated to ASNs, the shaft can be physically distributed. Each physical place would announce 240.0.0.0/6, and the nearest alive would attract the traffic. See it as as many IXPs. In the current draft, there’s only one shaft that links all realms. And there’s a single realm number for each realm that is advertised in every physical instances of the shaft. All that is a simplification to highlight the design.
As the shaft lives on, a realm may be multihomed, the shaft might be subnetted to interconnect only specific realms, or to be advertised differently in different geographies. And then the subnets will need to be injected in the realms. The way around a breakage can be DNS, or BGP.
All this is possible, you’ve already done it, and it’s really your play. We build the car, you drive it. Happy that you start figuring out how you prefer it to happen. While we figure out protocols to renumber more efficiently, fix source address selection, extend the NATs, you name it. There’s work for all and at every phase. But at this stage of the discussion, I favor the 10 miles view to get a shared basic understanding.
On the side, I’d be happy to learn how you solved a situation like the one below, if there’s any article / doc?
Keep safe;
Pascal
*From:* Matthew Petach <mpetach@netflight.com> *Sent:* mardi 5 avril 2022 0:29 *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Nicholas Warren < nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@gmail.com>; NANOG <nanog@nanog.org> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG < nanog@nanog.org> wrote:
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.
Please forgive me as I work this out in my head for a moment.
If I'm a global network with a single ASN on every populated continent
on the planet, this means I would have a single Realm address; for
the sake of the example, let's suppose I'm ASN 42, so my Realm
address is 240.0.0.42. I have 200+ BGP speaking routers at
exchange points all over the planet where I exchange traffic with
other networks.
In this new model, every border router I have would all use the
same 240.0.0.42 address in the Shaft, and other Realms would
simply hand traffic to the nearest border router of mine, essentially
following a simple Anycast model where the nearest instance of the
Realm address is the one that traffic is handed to, with no way to do
traffic engineering from continent to continent?
Or is there some mechanism whereby different instances of 240.0.0.42
can announce different policies into the Shaft to direct traffic more
appropriately that I'm not understanding from the discussion?
Because if it's one big exercise in enforced Hot Potato Routing with
a single global announcement of your reachability...
...that's gonna fail big-time the first time there's a major undersea
quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific
connectivity off, and suddenly you've got the same Realm address
being advertised in the US as in Asia, but with no underlying connectivity
between them.
https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20...
We who do not learn from history are doomed to repeat it...badly. :(
Matt
Hello Dave: The problem we have not solved is with the (host, gateway, ISP network) that will not move; and I’m hearing in this list that there’s one big reason: because the step (the leap really) is too wide. And I also read a consensus that dual stack and large NATs are not the long term solution people want. The primary goal here is to avoid dual stack forever, and not having enormous CG-NATs either. The proposal is to replace the leap that few can achieve by a series of baby steps that most can, and will to a point. To your example: say that you’re willing to migrate your host stack to IPv6-only. But then your ISP or your home gateway does not have it. Stuck. If you form a YATT address, the stateless translation will discover that there’s no v6 and turn the YATT packet into YADA. With that you can talk to any YADA and YATT node in the universe, though you can neither reach all IPv6 nodes nor all IPv4 nodes. That’s where the baby steps land. The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is feasibility. With YADA, the change is smaller in the upper stack and the applications. Say you have VMs that are IPv4 only, that you do not control the stack at all but just the hosting system. The hosting system can serve as/intercept DNS, NAT the YADA double-A destination to a single-A with an address from the pool, leaving the VM stack unchanged. An upgraded home gateway could do that too for the whole private network. YADA and YATT are equivalent, they are the IPv4 and IPv6 formulations of the same thing; what goes on the wire is whatever matches what the ISP network offers. Each AS or realm can decide to be one version only. The stateless NAT at the border can be wire speed, there’s state nor no complexity involved in that translation. When you’re already IPv6 you need none of that. IPv6 is the sphere than encompasses all the planes (realms) and the shaft. Plus all the air in between. But the IPv6 host could be so nice as to support YATT, which effectively is an effort on its part, but gives it a /64 for free, automatically. That’s a bonus that could become handy. Keep safe; Pascal From: Dave Bell <me@geordish.org> Sent: mardi 5 avril 2022 9:45 To: Pascal Thubert (pthubert) <pthubert@cisco.com> Cc: Matthew Petach <mpetach@netflight.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; NANOG <nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Considering this requires updating every single IP stack that wants to utilise this, what are the benefits of it other than just moving to IPv6? Regards, Dave On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: Hello Matthew At the moment the draft has a general architecture, and it will take the right minds and experience to turn a model into a live network. Considering what the people in this list have already built, it’s no gigantic leap to figure they can build that too. Most of the building blocks that are implicit or TBD in the draft exist already. About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The draft is not like that, all existing ASN and IP addresses can be reused in every new realm, and there does not need to be any mapping. If people find a need or a reason to add constraints, that’s beyond me at this time, and against the natural philosophy of minimizing interdependences to maintain design freedom in each realm. The draft has one and one only dependency, that surface of the shaft is common to all realms. To your point, and unrelated to ASNs, the shaft can be physically distributed. Each physical place would announce 240.0.0.0/6<http://240.0.0.0/6>, and the nearest alive would attract the traffic. See it as as many IXPs. In the current draft, there’s only one shaft that links all realms. And there’s a single realm number for each realm that is advertised in every physical instances of the shaft. All that is a simplification to highlight the design. As the shaft lives on, a realm may be multihomed, the shaft might be subnetted to interconnect only specific realms, or to be advertised differently in different geographies. And then the subnets will need to be injected in the realms. The way around a breakage can be DNS, or BGP. All this is possible, you’ve already done it, and it’s really your play. We build the car, you drive it. Happy that you start figuring out how you prefer it to happen. While we figure out protocols to renumber more efficiently, fix source address selection, extend the NATs, you name it. There’s work for all and at every phase. But at this stage of the discussion, I favor the 10 miles view to get a shared basic understanding. On the side, I’d be happy to learn how you solved a situation like the one below, if there’s any article / doc? Keep safe; Pascal From: Matthew Petach <mpetach@netflight.com<mailto:mpetach@netflight.com>> Sent: mardi 5 avril 2022 0:29 To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Nicholas Warren <nwarren@barryelectric.com<mailto:nwarren@barryelectric.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: 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. Please forgive me as I work this out in my head for a moment. If I'm a global network with a single ASN on every populated continent on the planet, this means I would have a single Realm address; for the sake of the example, let's suppose I'm ASN 42, so my Realm address is 240.0.0.42. I have 200+ BGP speaking routers at exchange points all over the planet where I exchange traffic with other networks. In this new model, every border router I have would all use the same 240.0.0.42 address in the Shaft, and other Realms would simply hand traffic to the nearest border router of mine, essentially following a simple Anycast model where the nearest instance of the Realm address is the one that traffic is handed to, with no way to do traffic engineering from continent to continent? Or is there some mechanism whereby different instances of 240.0.0.42 can announce different policies into the Shaft to direct traffic more appropriately that I'm not understanding from the discussion? Because if it's one big exercise in enforced Hot Potato Routing with a single global announcement of your reachability... ...that's gonna fail big-time the first time there's a major undersea quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific connectivity off, and suddenly you've got the same Realm address being advertised in the US as in Asia, but with no underlying connectivity between them. https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20... We who do not learn from history are doomed to repeat it...badly. :( Matt
From what I'm reading, it seems like you're implying that the bulk of the ISP network does not need to change to implement this new IP protocol. If
Hi Pascal, that is the case, then you are incorrect. Without the router that the customer connects to being aware of this new protocol, then you are opening yourself up to address forgery on a massive scale. The ISPs next hop needs to be able to inspect both the regular source address, and the encapsulated source address to ensure that the customer is sending legitimate traffic (uRPF). In my world the BNG is the most complicated part of the network. The CPE I'm sending out to my customers now presumably needs its NAT implementation altering? It now does translation on the inner IP header rather than the regular what is now outer. So to summarize, to implement this I need to do the following: * Install some CG-NAT device (You can argue its not CG-NAT because its stateless - It will have a lot of traffic going through it, so its carrier grade, and its translating from one type of IP to another, so its network address translation.) * Upgrade my BNGs to cope with the new address format for uRPF purposes * Upgrade/replace all my CPE * Have the network stack on my customers OS upgraded Not to mention all the testing required to ensure that it all will work smoothly. That is a lot of work, and I still don't see the benefit over just moving to IPv6. Regards, Dave On Tue, 5 Apr 2022 at 10:30, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hello Dave:
The problem we have not solved is with the (host, gateway, ISP network) that will not move; and I’m hearing in this list that there’s one big reason: because the step (the leap really) is too wide. And I also read a consensus that dual stack and large NATs are not the long term solution people want.
The primary goal here is to avoid dual stack forever, and not having enormous CG-NATs either. The proposal is to replace the leap that few can achieve by a series of baby steps that most can, and will to a point.
To your example: say that you’re willing to migrate your host stack to IPv6-only. But then your ISP or your home gateway does not have it. Stuck. If you form a YATT address, the stateless translation will discover that there’s no v6 and turn the YATT packet into YADA. With that you can talk to any YADA and YATT node in the universe, though you can neither reach all IPv6 nodes nor all IPv4 nodes. That’s where the baby steps land.
The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is feasibility. With YADA, the change is smaller in the upper stack and the applications. Say you have VMs that are IPv4 only, that you do not control the stack at all but just the hosting system. The hosting system can serve as/intercept DNS, NAT the YADA double-A destination to a single-A with an address from the pool, leaving the VM stack unchanged. An upgraded home gateway could do that too for the whole private network.
YADA and YATT are equivalent, they are the IPv4 and IPv6 formulations of the same thing; what goes on the wire is whatever matches what the ISP network offers. Each AS or realm can decide to be one version only. The stateless NAT at the border can be wire speed, there’s state nor no complexity involved in that translation.
When you’re already IPv6 you need none of that. IPv6 is the sphere than encompasses all the planes (realms) and the shaft. Plus all the air in between. But the IPv6 host could be so nice as to support YATT, which effectively is an effort on its part, but gives it a /64 for free, automatically. That’s a bonus that could become handy.
Keep safe;
Pascal
*From:* Dave Bell <me@geordish.org> *Sent:* mardi 5 avril 2022 9:45 *To:* Pascal Thubert (pthubert) <pthubert@cisco.com> *Cc:* Matthew Petach <mpetach@netflight.com>; Vasilenko Eduard < vasilenko.eduard@huawei.com>; NANOG <nanog@nanog.org> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Considering this requires updating every single IP stack that wants to utilise this, what are the benefits of it other than just moving to IPv6?
Regards,
Dave
On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG < nanog@nanog.org> wrote:
Hello Matthew
At the moment the draft has a general architecture, and it will take the right minds and experience to turn a model into a live network. Considering what the people in this list have already built, it’s no gigantic leap to figure they can build that too. Most of the building blocks that are implicit or TBD in the draft exist already.
About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The draft is not like that, all existing ASN and IP addresses can be reused in every new realm, and there does not need to be any mapping. If people find a need or a reason to add constraints, that’s beyond me at this time, and against the natural philosophy of minimizing interdependences to maintain design freedom in each realm. The draft has one and one only dependency, that surface of the shaft is common to all realms.
To your point, and unrelated to ASNs, the shaft can be physically distributed. Each physical place would announce 240.0.0.0/6, and the nearest alive would attract the traffic. See it as as many IXPs. In the current draft, there’s only one shaft that links all realms. And there’s a single realm number for each realm that is advertised in every physical instances of the shaft. All that is a simplification to highlight the design.
As the shaft lives on, a realm may be multihomed, the shaft might be subnetted to interconnect only specific realms, or to be advertised differently in different geographies. And then the subnets will need to be injected in the realms. The way around a breakage can be DNS, or BGP.
All this is possible, you’ve already done it, and it’s really your play. We build the car, you drive it. Happy that you start figuring out how you prefer it to happen. While we figure out protocols to renumber more efficiently, fix source address selection, extend the NATs, you name it. There’s work for all and at every phase. But at this stage of the discussion, I favor the 10 miles view to get a shared basic understanding.
On the side, I’d be happy to learn how you solved a situation like the one below, if there’s any article / doc?
Keep safe;
Pascal
*From:* Matthew Petach <mpetach@netflight.com> *Sent:* mardi 5 avril 2022 0:29 *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Nicholas Warren < nwarren@barryelectric.com>; Abraham Y. Chen <aychen@avinta.com>; Justin Streiner <streinerj@gmail.com>; NANOG <nanog@nanog.org> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG < nanog@nanog.org> wrote:
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.
Please forgive me as I work this out in my head for a moment.
If I'm a global network with a single ASN on every populated continent
on the planet, this means I would have a single Realm address; for
the sake of the example, let's suppose I'm ASN 42, so my Realm
address is 240.0.0.42. I have 200+ BGP speaking routers at
exchange points all over the planet where I exchange traffic with
other networks.
In this new model, every border router I have would all use the
same 240.0.0.42 address in the Shaft, and other Realms would
simply hand traffic to the nearest border router of mine, essentially
following a simple Anycast model where the nearest instance of the
Realm address is the one that traffic is handed to, with no way to do
traffic engineering from continent to continent?
Or is there some mechanism whereby different instances of 240.0.0.42
can announce different policies into the Shaft to direct traffic more
appropriately that I'm not understanding from the discussion?
Because if it's one big exercise in enforced Hot Potato Routing with
a single global announcement of your reachability...
...that's gonna fail big-time the first time there's a major undersea
quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific
connectivity off, and suddenly you've got the same Realm address
being advertised in the US as in Asia, but with no underlying connectivity
between them.
https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20...
We who do not learn from history are doomed to repeat it...badly. :(
Matt
Hello Dave: If you have a v4 only network and are willing to migrate to v6 that’s certainly neat and the YATT traffic will just be another v6 traffic that your BCP 38 rules will process. Still you’ll find IPv4 only customers, and you’ll end up with both v4 and v6, and CG NATs, etc. This is what we need to compare with, not IPv6 only. YADA applies to those who would not want dual stack and CG NAT, at least as the main rule. Those who would prefer to see end point transition for the most part to something easier to digest if not full v6. To your points: - yes the NAT is not stateful and that makes all the difference in the world. It becomes a network operation like an MPLS tunnel encapsulation that your router does BAU day in day out - I’ll trust you on your filters but filters for IPv4 only does probably do something for IP in IP, be it for the case where it’s v6 inside. Not saying it’s free, it’s a one-time opex. But not seeing that it’s the same cost as dual stack and CG NATs either, which are both opex and capex. - Upgrade/replace all my CPE + Have the network stack on my customers OS upgraded That’s where the kneejerk rejection shows the most. For the one thing if the customer OS is upgraded then why would you update the CPE? Then not all devices need this, many are hapopy with the current state of affairs? And the other way around if the CPE is upgraded, do we need to update the users devices? So presented as you did it’s plain dishonest. That’s why I found the YADA pun so funny actually. Unless we’re uncharacteristically efficient on this one, the CPE software will be upgraded a number of times before this thing takes off, and the CPE themselves might be replaced for the most part. The way I see it, adoption can happen from one customer alone. And yes, that would add to the list of ways to bypass BCP 38. So yes, it would be neat that you install rules that understand IP in IP if you do not already have them, with something for YADA in addition, and yes, that’s not free. But compared to CG NAT and dual stack? Well, I’d be happy to help people have that choice. Keep safe; Pascal From: Dave Bell <me@geordish.org> Sent: mardi 5 avril 2022 13:03 To: Pascal Thubert (pthubert) <pthubert@cisco.com> Cc: Dave Bell <me@geordish.org>; Matthew Petach <mpetach@netflight.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; NANOG <nanog@nanog.org> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Hi Pascal, From what I'm reading, it seems like you're implying that the bulk of the ISP network does not need to change to implement this new IP protocol. If that is the case, then you are incorrect. Without the router that the customer connects to being aware of this new protocol, then you are opening yourself up to address forgery on a massive scale. The ISPs next hop needs to be able to inspect both the regular source address, and the encapsulated source address to ensure that the customer is sending legitimate traffic (uRPF). In my world the BNG is the most complicated part of the network. The CPE I'm sending out to my customers now presumably needs its NAT implementation altering? It now does translation on the inner IP header rather than the regular what is now outer. So to summarize, to implement this I need to do the following: * Install some CG-NAT device (You can argue its not CG-NAT because its stateless - It will have a lot of traffic going through it, so its carrier grade, and its translating from one type of IP to another, so its network address translation.) * Upgrade my BNGs to cope with the new address format for uRPF purposes * Upgrade/replace all my CPE * Have the network stack on my customers OS upgraded Not to mention all the testing required to ensure that it all will work smoothly. That is a lot of work, and I still don't see the benefit over just moving to IPv6. Regards, Dave On Tue, 5 Apr 2022 at 10:30, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Dave: The problem we have not solved is with the (host, gateway, ISP network) that will not move; and I’m hearing in this list that there’s one big reason: because the step (the leap really) is too wide. And I also read a consensus that dual stack and large NATs are not the long term solution people want. The primary goal here is to avoid dual stack forever, and not having enormous CG-NATs either. The proposal is to replace the leap that few can achieve by a series of baby steps that most can, and will to a point. To your example: say that you’re willing to migrate your host stack to IPv6-only. But then your ISP or your home gateway does not have it. Stuck. If you form a YATT address, the stateless translation will discover that there’s no v6 and turn the YATT packet into YADA. With that you can talk to any YADA and YATT node in the universe, though you can neither reach all IPv6 nodes nor all IPv4 nodes. That’s where the baby steps land. The motivation to go YADA from IPv4 (as opposed to IPv6 altogether) is feasibility. With YADA, the change is smaller in the upper stack and the applications. Say you have VMs that are IPv4 only, that you do not control the stack at all but just the hosting system. The hosting system can serve as/intercept DNS, NAT the YADA double-A destination to a single-A with an address from the pool, leaving the VM stack unchanged. An upgraded home gateway could do that too for the whole private network. YADA and YATT are equivalent, they are the IPv4 and IPv6 formulations of the same thing; what goes on the wire is whatever matches what the ISP network offers. Each AS or realm can decide to be one version only. The stateless NAT at the border can be wire speed, there’s state nor no complexity involved in that translation. When you’re already IPv6 you need none of that. IPv6 is the sphere than encompasses all the planes (realms) and the shaft. Plus all the air in between. But the IPv6 host could be so nice as to support YATT, which effectively is an effort on its part, but gives it a /64 for free, automatically. That’s a bonus that could become handy. Keep safe; Pascal From: Dave Bell <me@geordish.org<mailto:me@geordish.org>> Sent: mardi 5 avril 2022 9:45 To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> Cc: Matthew Petach <mpetach@netflight.com<mailto:mpetach@netflight.com>>; Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Considering this requires updating every single IP stack that wants to utilise this, what are the benefits of it other than just moving to IPv6? Regards, Dave On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: Hello Matthew At the moment the draft has a general architecture, and it will take the right minds and experience to turn a model into a live network. Considering what the people in this list have already built, it’s no gigantic leap to figure they can build that too. Most of the building blocks that are implicit or TBD in the draft exist already. About linking ASN to realms, that’s Eduard’s view, I’ll let him answer. The draft is not like that, all existing ASN and IP addresses can be reused in every new realm, and there does not need to be any mapping. If people find a need or a reason to add constraints, that’s beyond me at this time, and against the natural philosophy of minimizing interdependences to maintain design freedom in each realm. The draft has one and one only dependency, that surface of the shaft is common to all realms. To your point, and unrelated to ASNs, the shaft can be physically distributed. Each physical place would announce 240.0.0.0/6<http://240.0.0.0/6>, and the nearest alive would attract the traffic. See it as as many IXPs. In the current draft, there’s only one shaft that links all realms. And there’s a single realm number for each realm that is advertised in every physical instances of the shaft. All that is a simplification to highlight the design. As the shaft lives on, a realm may be multihomed, the shaft might be subnetted to interconnect only specific realms, or to be advertised differently in different geographies. And then the subnets will need to be injected in the realms. The way around a breakage can be DNS, or BGP. All this is possible, you’ve already done it, and it’s really your play. We build the car, you drive it. Happy that you start figuring out how you prefer it to happen. While we figure out protocols to renumber more efficiently, fix source address selection, extend the NATs, you name it. There’s work for all and at every phase. But at this stage of the discussion, I favor the 10 miles view to get a shared basic understanding. On the side, I’d be happy to learn how you solved a situation like the one below, if there’s any article / doc? Keep safe; Pascal From: Matthew Petach <mpetach@netflight.com<mailto:mpetach@netflight.com>> Sent: mardi 5 avril 2022 0:29 To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Nicholas Warren <nwarren@barryelectric.com<mailto:nwarren@barryelectric.com>>; Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@gmail.com>>; NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: 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. Please forgive me as I work this out in my head for a moment. If I'm a global network with a single ASN on every populated continent on the planet, this means I would have a single Realm address; for the sake of the example, let's suppose I'm ASN 42, so my Realm address is 240.0.0.42. I have 200+ BGP speaking routers at exchange points all over the planet where I exchange traffic with other networks. In this new model, every border router I have would all use the same 240.0.0.42 address in the Shaft, and other Realms would simply hand traffic to the nearest border router of mine, essentially following a simple Anycast model where the nearest instance of the Realm address is the one that traffic is handed to, with no way to do traffic engineering from continent to continent? Or is there some mechanism whereby different instances of 240.0.0.42 can announce different policies into the Shaft to direct traffic more appropriately that I'm not understanding from the discussion? Because if it's one big exercise in enforced Hot Potato Routing with a single global announcement of your reachability... ...that's gonna fail big-time the first time there's a major undersea quake in the Strait of Taiwan, which cuts 7/8ths of the trans-pacific connectivity off, and suddenly you've got the same Realm address being advertised in the US as in Asia, but with no underlying connectivity between them. https://www.submarinenetworks.com/news/cables-cut-after-taiwan-earthquake-20... We who do not learn from history are doomed to repeat it...badly. :( Matt
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 <nwarren@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) 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 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.com@nanog.org> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) < pthubert@cisco.com>; Justin Streiner <streinerj@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:aychen@avinta.com] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com>; Justin Streiner <mailto: streinerj@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:aychen@avinta.com Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Pascal Thubert (pthubert) mailto:pthubert@cisco.com; Justin Streiner mailto: streinerj@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:pthubert@cisco.com] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com; Justin Streiner mailto:streinerj@gmail.com; Abraham Y. Chen mailto:aychen@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.eduard@huawei.com> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>; Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto: aychen@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.com@nanog.org] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com>; Abraham Y. Chen <mailto: aychen@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.com@nanog.org> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@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:aychen@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.
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:me@geordish.org] Sent: Monday, April 4, 2022 9:21 PM To: Nicholas Warren <nwarren@barryelectric.com> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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 <nwarren@barryelectric.com<mailto:nwarren@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.com@nanog.org<mailto:barryelectric.com@nanog.org>> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>>; Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com>] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@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:pthubert@cisco.com<mailto:pthubert@cisco.com>] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>; Abraham Y. Chen mailto:aychen@avinta.com<mailto:aychen@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.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:huawei.com@nanog.org>] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:cisco.com@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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:aychen@avinta.com<mailto:aychen@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
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.eduard@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:me@geordish.org] Sent: Monday, April 4, 2022 9:21 PM To: Nicholas Warren <nwarren@barryelectric.com> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Abraham Y. Chen <aychen@avinta.com>; Pascal Thubert (pthubert) <pthubert@cisco.com>; Justin Streiner <streinerj@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 <nwarren@barryelectric.com<mailto:nwarren@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.com@nanog.org<mailto:barryelectric.com@nanog.org>> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>>; Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com>] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@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:pthubert@cisco.com<mailto:pthubert@cisco.com>] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>; Abraham Y. Chen mailto:aychen@avinta.com<mailto:aychen@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.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:huawei.com@nanog.org>] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:cisco.com@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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:aychen@avinta.com<mailto:aychen@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
Isn’t load balancing one of the neat things you do with loopbacks? Certainly the router that serves the shaft is virtual and distributed. The shaft itself can/should be physically distributed in multiple IXPs. For now let us agree on the simple view. Things like load balancing and physical distribution around the planet will be arranged in their own time. Regards, Pascal Le 4 avr. 2022 à 20:21, Dave Bell <me@geordish.org> a écrit : 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 <nwarren@barryelectric.com<mailto:nwarren@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.com@nanog.org<mailto:barryelectric.com@nanog.org>> On Behalf Of Vasilenko Eduard via NANOG Sent: Monday, April 4, 2022 3:28 AM To: Abraham Y. Chen <aychen@avinta.com<mailto:aychen@avinta.com>>; Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com>] Sent: Saturday, April 2, 2022 12:45 AM To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Vasilenko Eduard <mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@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:aychen@avinta.com<mailto:aychen@avinta.com> Sent: vendredi 1 avril 2022 15:49 To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Pascal Thubert (pthubert) mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@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:pthubert@cisco.com<mailto:pthubert@cisco.com>] Sent: Friday, April 1, 2022 3:41 PM To: Vasilenko Eduard mailto:vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>; Justin Streiner mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>; Abraham Y. Chen mailto:aychen@avinta.com<mailto:aychen@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.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> Sent: vendredi 1 avril 2022 14:32 To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com<mailto:pthubert@cisco.com>>; Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:huawei.com@nanog.org>] On Behalf Of Pascal Thubert (pthubert) via NANOG Sent: Friday, April 1, 2022 2:26 PM To: Justin Streiner <mailto:streinerj@gmail.com<mailto:streinerj@gmail.com>>; Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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.com@nanog.org<mailto:cisco.com@nanog.org>> On Behalf Of Justin Streiner Sent: dimanche 27 mars 2022 18:12 To: Abraham Y. Chen <mailto:aychen@avinta.com<mailto:aychen@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:aychen@avinta.com<mailto:aychen@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
participants (6)
-
Abraham Y. Chen -
Dave Bell -
Matthew Petach -
Nicholas Warren -
Pascal Thubert (pthubert) -
Vasilenko Eduard