Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Pascal Thubert (pthubert) pthubert at cisco.com
Mon Apr 4 17:50:04 UTC 2022


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 at 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 at 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 at cisco.com] 
>> Sent: Monday, April 4, 2022 7:20 PM
>> To: Nicholas Warren <nwarren at barryelectric.com>; Vasilenko Eduard <vasilenko.eduard at huawei.com>; Abraham Y. Chen <aychen at avinta.com>; Justin Streiner <streinerj at gmail.com>
>> Cc: NANOG <nanog at 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 at nanog.org> On 
>>> Behalf Of Vasilenko Eduard via NANOG
>>> Sent: Monday, April 4, 2022 3:28 AM
>>> To: Abraham Y. Chen <aychen at avinta.com>; Pascal Thubert (pthubert) 
>>> <pthubert at cisco.com>; Justin Streiner <streinerj at gmail.com>
>>> Cc: NANOG <nanog at 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 at avinta.com]
>>> Sent: Saturday, April 2, 2022 12:45 AM
>>> To: Pascal Thubert (pthubert) <mailto:pthubert at cisco.com>; Vasilenko 
>>> Eduard <mailto:vasilenko.eduard at huawei.com>; Justin Streiner 
>>> <mailto:streinerj at gmail.com>
>>> Cc: NANOG <mailto:nanog at 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 at avinta.com
>>> Sent: vendredi 1 avril 2022 15:49
>>> To: Vasilenko Eduard mailto:vasilenko.eduard at huawei.com; Pascal 
>>> Thubert
>>> (pthubert) mailto:pthubert at cisco.com; Justin Streiner 
>>> mailto:streinerj at gmail.com
>>> Cc: NANOG mailto:nanog at 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 at cisco.com]
>>> Sent: Friday, April 1, 2022 3:41 PM
>>> To: Vasilenko Eduard mailto:vasilenko.eduard at huawei.com; Justin 
>>> Streiner mailto:streinerj at gmail.com; Abraham Y. Chen 
>>> mailto:aychen at 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 at huawei.com>
>>> Sent: vendredi 1 avril 2022 14:32
>>> To: Pascal Thubert (pthubert) <mailto:pthubert at cisco.com>; Justin 
>>> Streiner <mailto:streinerj at gmail.com>; Abraham Y. Chen 
>>> <mailto:aychen at 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 at nanog.org]
>>> On Behalf Of Pascal Thubert (pthubert) via NANOG
>>> Sent: Friday, April 1, 2022 2:26 PM
>>> To: Justin Streiner <mailto:streinerj at gmail.com>; Abraham Y. Chen 
>>> <mailto:aychen at avinta.com>
>>> Cc: NANOG <mailto:nanog at 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 at nanog.org> On 
>>> Behalf Of Justin Streiner
>>> Sent: dimanche 27 mars 2022 18:12
>>> To: Abraham Y. Chen <mailto:aychen at avinta.com>
>>> Cc: NANOG <mailto:nanog at 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 at 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
>>> 
>>> 
>> 


More information about the NANOG mailing list