EzIP vs. YADA & YATT Re: Ready to compromise? was RE: V6 still not supported
ing use of the Options mechanism under RFC791, so that IP header can stay basic. C. The EzIP scheme is less capable than YADA, but much more concise and well-defined: a. Instead of multiple realms, each capable of full IPv4 addresses, EzIP works within only one set of IPv4 address pool. b. EzIP starts from only realm 1 which occupies a subset of IPv4 addresses (the full IPv4 pool minus 240/4 netblock). c. Realm 2 thru realm N are called RAN (Regional Area Network), each reusing a full IPv4 subset of the 240/4 netblock. They are physically isolated from one another by restricted use within respective geographical boundaries. d. Instead of a big elevator shaft threading trough all N floors of the realms, Each RAN is individually tethered as a kite from realm 1 (the current Internet core) via just one (or more if needed) IPv4 address. e. After enough RANs are deployed, their boundaries begin to touch one another. So that, direct paths between the RANS may be established. Thus, an overlay of new networks is formed covering the entire globe for becoming a parallel cyberspace to the current Internet core (realm 1). The two can operate independently and interact only at arm's length via the umbilical cords, when needed. D. Unlike YADA & YATT, EzIP has not specifically considered its application to IPv6. Although, the feasibility of expanding a finite sized address pool such as IPv4, demonstrates that EzIP is equally capable of expanding the IPv6 that still has a lot of unassigned addresses. Please comment. Regards, Abe (2022-04-21 17:37 EDT) On 2022-04-20 03:20, Pascal Thubert (pthubert) wrote: Dear Abe: Yes, this is plain IP in IP. For a router does not know about YADA, this looks like the most basic form of tunnel you can get. Which is where the inner/outer terminology comes from. All very classical. We could do an over-UDP variation if people want it. I used a condensed format to focus the reader on the addresses that get swapped; also the visualization clarifies that there cannot be options between the outer header and the inner headers. The only routers that need to understand the fact that this is more than a plain tunnel are the routers that connect the realm to the shaft, because they have to check that the realm address is correct and do the address swap between inner and outer. The first version of the draft impacted routers for BCP 38 procedures, this is now changed. The routers inside a realm can keep operating unmodified, and there's no need to deploy new policies for ingress filtering. Keep safe; Pascal -----Original Message----- From: Abraham Y. Chen Sent: vendredi 15 avril 2022 0:47 To: Pascal Thubert (pthubert) Cc:nanog@nanog.org Subject: Re: Ready to compromise? was RE: V6 still not supported Dear Pascal: 1) I had a quick look at the below updated draft. I presume Figure 2 is intended to address my request. Since each IPv4 address has 4 bytes, what are the 12 bytes allocated for IPv4 header fields (outer) and (inner), each? Aren't they the standard first 12 bytes of packet identifier in an IPv4 header? If so, why not show it straightforward as defined by RFC791? 2) If my above assumption is correct, you are essentially prefixing the packet identifying portion (inner) of an IPv4 header with another one (the "outer"), without making use of the existing Options words like my EzIP proposal. How could any existing routers handle a packet with this new header format, without any design related upgrade? If you do expect upgrade, it would appear to me as too much to ask. Am I missing something? Regards, Abe (2022-04-14 18:46) On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote: Dear all Following advice from thus list, I updated the YADA I-Draft (latest ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG- NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many tha
Re: Ready to compromise? was RE: V6 still not supported
apable of full IPv4 addresses, EzIP works within only one set of IPv4 address pool. b. EzIP starts from only realm 1 which occupies a subset of IPv4 addresses (the full IPv4 pool minus 240/4 netblock). c. Realm 2 thru realm N are called RAN (Regional Area Network), each reusing a full IPv4 subset of the 240/4 netblock. They are physically isolated from one another by restricted use within respective geographical boundaries. d. Instead of a big elevator shaft threading trough all N floors of the realms, Each RAN is individually tethered as a kite from realm 1 (the current Internet core) via just one (or more if needed) IPv4 address. e. After enough RANs are deployed, their boundaries begin to touch one another. So that, direct paths between the RANS may be established. Thus, an overlay of new networks is formed covering the entire globe for becoming a parallel cyberspace to the current Internet core (realm 1). The two can operate independently and interact only at arm's length via the umbilical cords, when needed. D. Unlike YADA & YATT, EzIP has not specifically considered its application to IPv6. Although, the feasibility of expanding a finite sized address pool such as IPv4, demonstrates that EzIP is equally capable of expanding the IPv6 that still has a lot of unassigned addresses. Please comment. Regards, Abe (2022-04-21 17:37 EDT) On 2022-04-20 03:20, Pascal Thubert (pthubert) wrote: Dear Abe: Yes, this is plain IP in IP. For a router does not know about YADA, this looks like the most basic form of tunnel you can get. Which is where the inner/outer terminology comes from. All very classical. We could do an over-UDP variation if people want it. I used a condensed format to focus the reader on the addresses that get swapped; also the visualization clarifies that there cannot be options between the outer header and the inner headers. The only routers that need to understand the fact that this is more than a plain tunnel are the routers that connect the realm to the shaft, because they have to check that the realm address is correct and do the address swap between inner and outer. The first version of the draft impacted routers for BCP 38 procedures, this is now changed. The routers inside a realm can keep operating unmodified, and there's no need to deploy new policies for ingress filtering. Keep safe; Pascal -----Original Message----- From: Abraham Y. Chen Sent: vendredi 15 avril 2022 0:47 To: Pascal Thubert (pthubert) Cc:nanog@nanog.org Subject: Re: Ready to compromise? was RE: V6 still not supported Dear Pascal: 1) I had a quick look at the below updated draft. I presume Figure 2 is intended to address my request. Since each IPv4 address has 4 bytes, what are the 12 bytes allocated for IPv4 header fields (outer) and (inner), each? Aren't they the standard first 12 bytes of packet identifier in an IPv4 header? If so, why not show it straightforward as defined by RFC791? 2) If my above assumption is correct, you are essentially prefixing the packet identifying portion (inner) of an IPv4 header with another one (the "outer"), without making use of the existing Options words like my EzIP proposal. How could any existing routers handle a packet with this new header format, without any design related upgrade? If you do expect upgrade, it would appear to me as too much to ask. Am I missing something? Regards, Abe (2022-04-14 18:46) On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote: Dear all Following advice from thus list, I updated the YADA I-Draft (latest ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG- NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many thanks in advance; Pascal -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
RE: Ready to compromise? was RE: V6 still not supported
Dear Abe: Yes, this is plain IP in IP. For a router does not know about YADA, this looks like the most basic form of tunnel you can get. Which is where the inner/outer terminology comes from. All very classical. We could do an over-UDP variation if people want it. I used a condensed format to focus the reader on the addresses that get swapped; also the visualization clarifies that there cannot be options between the outer header and the inner headers. The only routers that need to understand the fact that this is more than a plain tunnel are the routers that connect the realm to the shaft, because they have to check that the realm address is correct and do the address swap between inner and outer. The first version of the draft impacted routers for BCP 38 procedures, this is now changed. The routers inside a realm can keep operating unmodified, and there's no need to deploy new policies for ingress filtering. Keep safe; Pascal > -Original Message- > From: Abraham Y. Chen > Sent: vendredi 15 avril 2022 0:47 > To: Pascal Thubert (pthubert) > Cc: nanog@nanog.org > Subject: Re: Ready to compromise? was RE: V6 still not supported > > Dear Pascal: > > 1) I had a quick look at the below updated draft. I presume Figure 2 is > intended to address my request. Since each IPv4 address has 4 bytes, what > are the 12 bytes allocated for IPv4 header fields (outer) and (inner), > each? Aren't they the standard first 12 bytes of packet identifier in an > IPv4 header? If so, why not show it straightforward as defined by RFC791? > > 2) If my above assumption is correct, you are essentially prefixing the > packet identifying portion (inner) of an IPv4 header with another one (the > "outer"), without making use of the existing Options words like my EzIP > proposal. How could any existing routers handle a packet with this new > header format, without any design related upgrade? If you do expect > upgrade, it would appear to me as too much to ask. Am I missing something? > > > Regards, > > > Abe (2022-04-14 18:46) > > > > On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote: > > Dear all > > > > Following advice from thus list, I updated the YADA I-Draft (latest > ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, > more to come soon if feedback is heard) and proposed it to the v6ops WG at > the IETF. > > > > For memory, the main goal here is to find a compromise as opposed to yet > another transition solution, though it can be used as a side effect to > move along the ladder. The compromise does not change IPv4 or IPv6, tries > not to take side for one or the other, and add features to both sides > which, if implemented, reduce the chasm that leads to dual stack and CG- > NATs. > > > > There's value for the movers, lots more public address space for the > IPv4-only stack/networks and free prefixes per node and new deployment > opportunities for the IPv6-only ones. > > > > One major update from the original text accounts for Dave's comment in > this list on BCP 38 enforcement, I believe it's solved now. I also added > format layouts to Abe Chen's question, and text on the naïve version vs. > all the elasticity that exists there and in IP in general to allow real > world deployments. > > > > Comments welcome, here and/or at v6ops for those who participate there. > > > > Many thanks in advance; > > > > Pascal > > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus
Re: Ready to compromise? was RE: V6 still not supported
Dear Pascal: 1) I had a quick look at the below updated draft. I presume Figure 2 is intended to address my request. Since each IPv4 address has 4 bytes, what are the 12 bytes allocated for IPv4 header fields (outer) and (inner), each? Aren't they the standard first 12 bytes of packet identifier in an IPv4 header? If so, why not show it straightforward as defined by RFC791? 2) If my above assumption is correct, you are essentially prefixing the packet identifying portion (inner) of an IPv4 header with another one (the "outer"), without making use of the existing Options words like my EzIP proposal. How could any existing routers handle a packet with this new header format, without any design related upgrade? If you do expect upgrade, it would appear to me as too much to ask. Am I missing something? Regards, Abe (2022-04-14 18:46) On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote: Dear all Following advice from thus list, I updated the YADA I-Draft (latest ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG-NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many thanks in advance; Pascal -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Ready to compromise? was RE: V6 still not supported
Dear all Following advice from thus list, I updated the YADA I-Draft (latest is https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG-NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many thanks in advance; Pascal
