RE: A straightforward transition plan (was: Re: V6 still not supported)

[Pascal Thubert (pthubert) via NANOG]

Hello Masataka-san

> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.

Solutions must first avoid broadcast as much as possible, because there's also 
the cost of it. There's a scale where it hurts any network, and repeating them 
even more cannot be the answer.
And then, I agree with you completely, whatever is broadcast (e.g., beacons for 
initial discovery) is repeated and, not expected to be reliable.
This is in essence RFC 8505.
Then you want zerotrust, ND is so easy to attack from inside and even outside. 
This is RFC 8928.

>   Reducing the speed at the physical (PHY) layer for
>   broadcast transmissions can increase the reliability
> 
> longer packets mean more collision (with hidden terminals) probability
> and less reliability.

Agreed. The draft tries to look at all angles. It is certainly not pleading to 
use broadcast. It is pleading to deprecate ND because of its use of broadcast 
even on networks where it plain does not work. In practice today, DAD is a joke 
on any large wireless fabric and still you see all those broadcasts in the air. 
Save the planet! 

> >  So far we failed to get those RFCs implemented on the major stacks
> > for WiFi or Ethernet.
> 
> Ethernet? Even though its broadcast is reliable?

Ethernet is enterprise networks is largely virtualized. We cannot offer fast 
and reliable broadcast services on a worldwide overlay. 

If we filter BUM we end up with so-called "silent nodes" that are effectively 
disconnected. If we try and serve them broadcast storms are a visible penalty 
on the overlay.

Add to that the desire by the device to own more and more addresses. You end up 
in a situation where the devices thinks the own an address and are reachable at 
that address but in fact the network will not serve that address because 1) it 
missed the creation (a snooped DAD?), 2) it has forgotten about it, or 3) the 
max count of addresses that the network maintains per host is passed. Note that 
3) may be reached because the network ignores that the host deprecated one of 
the addresses. 

You want a contract between that the host and the network that the host owns an 
address and is reachable at that address. Like any contract, that must be a 
negotiation. ND is not like that. RFC 8505 is exactly that. 

> It may be more constructive to work for proxy ARP suitable for Wifi,
> which may be enforced by Wifi alliance. An RFC may be published if Wifi
> industry request IETF to do so.

This is effectively done already for ND. 

The draft text in .11me recommends RFC 8929 as the ND proxy. 802.11md had it 
already since the Bangkok meeting but at the time of the freeze, RFC 8929 was 
still a draft and the text was removed at the last minute. RFC 8929 describes 
how RFC 8505 can be used buy the STA to negotiate a contract with the AP so the 
AP does ND proxy. Then the draft discusses how the AP represents the STA over 
the wired backbone, how mobility is handled, etc...

I guess the design can be easily retrofitted to ARP. ND is really designed 
exactly as ARP. The differences were for the show, the real steps that should 
have been made were not. But now with RFC 8505 we have a modern solution. The 
problem is no more on the standard side, it is adoption. People will not move 
if it does not hurt enough. And they can bear a lot.

All the best

Pascal 

> -Original Message-
> From: Masataka Ohta 
> Sent: vendredi 13 janvier 2023 6:36
> To: Pascal Thubert (pthubert) ; nanog@nanog.org
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> Pascal Thubert (pthubert) wrote:
> 
> Hi,
> 
> > For that issue at least there was some effort. Though ATM and FR
> > appear to be long gone, the problem got even worse with pseudo wires /
> > overlays and wireless.
> >
> > It was tackled in the IoT community 10+ years ago and we ended up with
> > RFC 8505 and 8928. This is implemented in LoWPAN devices and deployed
> > by millions. Allowing IPv6 subnets of thousands on constrained radios.
> 
> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.
> 
> > I spent a bit of time explaining the architecture issue (in mild
> > terms) and solutions in
> > https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-
> wireless-12.
> 
> Though you wrote in the draft:
> 
>   Reducing the speed at the physical (PHY) layer for
>   broadcast transmissions can increase 

Re: A straightforward transition plan (was: Re: V6 still not supported)

[Pascal Thubert (pthubert) via NANOG]

Hello Masataka-san

For that issue at least there was some effort.
Though ATM and FR appear to be long gone, the problem got even worse with 
pseudo wires / overlays and wireless.

It was tackled in the IoT community 10+ years ago and we ended up with RFC 8505 
and 8928. This is implemented in LoWPAN devices and deployed by millions. 
Allowing IPv6 subnets of thousands on constrained radios.

I spent a bit of time explaining the architecture issue (in mild terms) and 
solutions in 
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-12.

So far we failed to get those RFCs implemented on the major stacks for WiFi or 
Ethernet.

There’s a new thread at IETF 6MAN just now on adopting just the draft above - 
not even the solution. It is facing the same old opposition from the same few 
and a lot of silence.

Somehow the group can spend years of heated discussions figuring out if you can 
insert a header or how you can build a 64 bits IID, but looking at a 
fundamental architecture issue like the one you point out does not raise much 
interest.

My suggestion is still to fix IPv6 as opposed to drop it, because I don’t see 
that we have another bullet to fire after that one. For that particular issue 
of fixing ND, new comments and support at the 6MAN on the draft above may help.

All the best;

Pascal

Le 12 janv. 2023 à 05:34, Masataka Ohta  a 
écrit :

Randy Bush wrote:

three of the promises of ipng which ipv6 did not deliver
  o compatibility/transition,
  o security, and
  o routing & renumbering

You miss a promise of

  o ND over ATM/NBMA

which caused IPv6 lack a notion of link broadcast.

   Masataka Ohta

RE: IoT - The end of the internet

[Pascal Thubert (pthubert) via NANOG]

Hello Saku

I do not share that view:

1) Thread uses 6LoWPAN so nodes are effectively IPv6 even though it doesn’t 
show in the air.

2) Wi-Sun is not Thread and it is already deployed by millions.

3) even LoRa (1.1.1) is going IPv6, using SCHC.

Regards,

Pascal

> -Original Message-
> From: Saku Ytti 
> Sent: mercredi 10 août 2022 7:14
> To: Pascal Thubert (pthubert) 
> Cc: Mel Beckman ; nanog@nanog.org
> Subject: Re: IoT - The end of the internet
> 
> On Wed, 10 Aug 2022 at 07:54, Pascal Thubert (pthubert) via NANOG
>  wrote:
> 
> > On a more positive note, the IPv6 IoT can be seen as an experiment on
> how we can scale the internet another order of magnitude or 2 without
> taking the power or the spectrum consumption to the parallel levels.
> 
> I think at least the next 20 years of IoT is thread (and wifi for high
> BW)+matter, and IoT devices won't have IP that is addressable even from
> the user LAN, you go via GW, none of which you configure.
> 
> Some bits of if look unnecessarily forced perspective, like the
> addressing scheme, instead of inlining your role in PDU we use this
> cutesy addressing scheme looks like bit forced marketing of IPv6,
> doesn't seem necessary but also not really an important decision either
> way. Overall I think thread+matter are well designed and they make me
> quite optimistic of reasonable IoT outcomes.
> 
> --
>   ++ytti

Re: IoT - The end of the internet

[Pascal Thubert (pthubert) via NANOG]

On a more positive note, the IPv6 IoT can be seen as an experiment on how we 
can scale the internet another order of magnitude or 2 without taking the power 
or the spectrum consumption to the parallel levels.

For that we turned protocols like ND and MLD from broadcast pull to unicast 
push in a way that respects the device sleep cycle. We also introduced routing 
inside the subnet at scale and got rid of the need for common broadcast domains.

With that the Wi-Sun alliance deployed millions of nodes per customer network, 
with thousands to tens of thousands nodes per subnet. All operating in cheap 
constrained nodes, unreliable radio links, and scarce bandwidth.

I hope I’ll see the day when we manage to retrofit that in the mainstream 
stacks; there’s a potential to turn the fringe of the internet a lot greener. 
Sadly the IPv4 ways (like use of L2 broadcast and mapping IP links and subnets 
to lower layer constructs) are entrenched in IPv6, and we are facing a lot of 
resistance.

Stay tuned,

Pascal

> Le 10 août 2022 à 06:29, Mel Beckman  a écrit :
> 
> ROTFL!
> 
> Yes, every time I’ve run into Bob at a conference he always introduces 
> himself this way: “I’m Bob Metcalfe, the inventor of Ethernet.”
> 
> -mel
> 
>>> On Aug 9, 2022, at 9:20 PM, Fred Baker  wrote:
>>> 
>>> 
>>> 
 On Aug 9, 2022, at 8:06 PM, Mel Beckman  wrote:
>>> 
>>> Robert Metcalfe, InfoWorld columnist and the inventor of Ethernet, also in 
>>> 1995:
>>> “I predict the Internet will soon go spectacularly supernova and in 1996 
>>> catastrophically collapse.”
>> 
>> In 1998 I invited Mr Metcalfe to address the IETF on the collapse of the 
>> Internet, which he renewed his prediction of. He declined.
> 

RE: Ready to compromise? was RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

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

Ready to compromise? was RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

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

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

[Pascal Thubert (pthubert) via NANOG]

h 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 mailto:m...@geordish.org>>
Sent: mardi 5 avril 2022 9:45
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Cc: Matthew Petach mailto:mpet...@netflight.com>>; 
Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>; NANOG 
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 
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 mailto:mpet...@netflight.com>>
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Cc: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Nicholas Warren mailto:nwar...@barryelectric.com>>; 
Abraham Y. Chen mailto:ayc...@avinta.com>>; Justin Streiner 
mailto:strein...@gmail.com>>; NANOG 
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 
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

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

[Pascal Thubert (pthubert) via NANOG]

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 
Sent: mardi 5 avril 2022 9:45
To: Pascal Thubert (pthubert) 
Cc: Matthew Petach ; Vasilenko Eduard 
; NANOG 
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 
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 mailto:mpet...@netflight.com>>
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Cc: 

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

[Pascal Thubert (pthubert) via NANOG]

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 
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard 
Cc: Pascal Thubert (pthubert) ; Nicholas Warren 
; Abraham Y. Chen ; Justin 
Streiner ; NANOG 
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 
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-2006

We who do not learn from history are doomed to repeat it...badly.   :(

Matt

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

[Pascal Thubert (pthubert) via NANOG]

.@huawei.com<mailto:vasilenko.edu...@huawei.com>; Justin 
Streiner mailto:strein...@gmail.com<mailto:strein...@gmail.com>; Abraham Y. 
Chen mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot be a 
Default Free Zone?
I agree with your real world issue that some things will have to be planned 
between stake holders, and that it will not be easy.
But you know what the French say about “impossible”.
Or to paraphrase Sir Arthur, now that we have eliminated all the impossible 
transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be managed by 
different players as you point out. And all routable within the same shaft.

Keep safe;

Pascal

From: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>>
Sent: vendredi 1 avril 2022 14:32
To: Pascal Thubert (pthubert) 
<mailto:pthub...@cisco.com<mailto:pthub...@cisco.com>>; Justin Streiner 
<mailto:strein...@gmail.com<mailto:strein...@gmail.com>>; Abraham Y. Chen 
<mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual hierarchy that 
does not map to any administrative border. Who should implement gateways for 
the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is not enough 
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so 
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG 
[mailto:nanog-bounces+vasilenko.eduard<mailto:nanog-bounces%2Bvasilenko.eduard>=huawei@nanog.org<mailto:huawei@nanog.org>]
 On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Friday, April 1, 2022 2:26 PM
To: Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>>; 
Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>>
Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG 
<mailto:nanog-bounces+pthubert<mailto:nanog-bounces%2Bpthubert>=cisco@nanog.org<mailto:cisco@nanog.org>>
 On Behalf Of Justin Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>>
Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
<mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.



Virus-free. 
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link

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

[Pascal Thubert (pthubert) via NANOG]

 on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual hierarchy that 
does not map to any administrative border. Who should implement gateways for 
the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is not enough 
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so 
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG 
[mailto:nanog-bounces+vasilenko.eduard<mailto:nanog-bounces%2Bvasilenko.eduard>=huawei@nanog.org<mailto:huawei@nanog.org>]
 On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Friday, April 1, 2022 2:26 PM
To: Justin Streiner <mailto:strein...@gmail.com<mailto:strein...@gmail.com>>; 
Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>>
Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG 
<mailto:nanog-bounces+pthubert<mailto:nanog-bounces%2Bpthubert>=cisco@nanog.org<mailto:cisco@nanog.org>>
 On Behalf Of Justin Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen <mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>>
Cc: NANOG <mailto:nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
<mailto:ayc...@avinta.com<mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.



Virus-free. 
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link

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

[Pascal Thubert (pthubert) via NANOG]

ce to the Internet, you may look at each 
>>> RAN as an isolated balloon for others. So that each RAN can use up the 
>>> entire 240/4 netblock.
>>> 
>>> Please clarify your configuration.
>>> 
>>> Thanks,
>>> 
>>> 
>>> Abe (2022-04-01 17:44)
>>> 
>>> 
>>> 
>>> 
>>>> On 2022-04-01 10:55, Abraham Y. Chen wrote:
>>>> On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:
>>> Makes sense, Abe, for the next version.
>>> 
>>> Note that the intention is NOT any to ANY. A native IPv6 IoT device 
>>> can only talk to another IPv6 device, where that other device may use 
>>> a YATT address or any other IPv6 address.
>>> But it cannot talk to a YADA node. That’s what I mean by baby steps 
>>> for those who want to.
>>> 
>>> Keep safe;
>>> 
>>> Pascal
>>> 
>>> From: Abraham Y. Chen mailto:ayc...@avinta.com
>>> Sent: vendredi 1 avril 2022 15:49
>>> To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com; Pascal 
>>> Thubert
>>> (pthubert) mailto:pthub...@cisco.com; Justin Streiner 
>>> mailto:strein...@gmail.com
>>> Cc: NANOG mailto:nanog@nanog.org
>>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
>>> 202203261833.AYC
>>> 
>>> Hi, Pascal:
>>> 
>>> What I would appreciate is an IP packet header design/definition 
>>> layout, word-by-word, ideally in bit-map style, of an explicit 
>>> presentation of all IP addresses involved from one IoT in one realm to 
>>> that in the second realm. This will provide a clearer picture of how 
>>> the real world implementation may look like.
>>> 
>>> Thanks,
>>> 
>>> 
>>> Abe (2022-04-01 09:48)
>>> 
>>> 
>>>> On 2022-04-01 08:49, Vasilenko Eduard wrote:
>>> As I understand: “IPv4 Realms” between “Shaft” should be capable to 
>>> have a plain IPv4 header (or else why all of these).
>>> Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
>>> Who should implement this gateway and why? He should be formally 
>>> appointed to such an exercise, right?
>>> Map this 2 level hierarchy to the real world – you may fail with this.
>>> Ed/
>>> From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
>>> Sent: Friday, April 1, 2022 3:41 PM
>>> To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com; Justin 
>>> Streiner mailto:strein...@gmail.com; Abraham Y. Chen 
>>> mailto:ayc...@avinta.com
>>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>>> 202203261833.AYC
>>> 
>>> Hello Eduard:
>>> 
>>> Did you just demonstrate that POPs cannot exist? Or that there cannot 
>>> be a Default Free Zone?
>>> I agree with your real world issue that some things will have to be 
>>> planned between stake holders, and that it will not be easy.
>>> But you know what the French say about “impossible”.
>>> Or to paraphrase Sir Arthur, now that we have eliminated all the 
>>> impossible transition scenarios, whatever remains…
>>> 
>>> There will be YADA prefixes just like there are root DNS. To be 
>>> managed by different players as you point out. And all routable within 
>>> the same shaft.
>>> 
>>> Keep safe;
>>> 
>>> Pascal
>>> 
>>> From: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com>
>>> Sent: vendredi 1 avril 2022 14:32
>>> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin 
>>> Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
>>> <mailto:ayc...@avinta.com>
>>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>>> 202203261833.AYC
>>> 
>>> Hi Pascal,
>>> In general, your idea to create a hierarchy is good.
>>> In practice, it would fail because you have created a virtual 
>>> hierarchy that does not map to any administrative border. Who should 
>>> implement gateways for the “Shaft”? Why?
>>> If you would appoint Carrier as the Shaft responsible then it is not 
>>> enough bits for Shaft.
>>> If you would appoint Governments as the Shaft responsible then would 
>>> be a so big scandal that you would regret the proposal.
>>> Hence, I do not see proper mapping for the hierarchy to make YADA 
>>> successful.
>>> Eduard
>>> From: NANOG 
>>> [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org]
>>> On Behalf Of Pascal Thubert (pthubert) via NANOG
>>> Sent: Friday, April 1, 2022 2:26 PM
>>> To: Justin Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
>>> <mailto:ayc...@avinta.com>
>>> Cc: NANOG <mailto:nanog@nanog.org>
>>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>>> 202203261833.AYC
>>> 
>>> For the sake of it, Justin, I just published 
>>> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
>>> The first section of the draft (YADA) extends IPv4 range in an 
>>> IPv4-only world. For some people that might be enough and I’m totally 
>>> fine with that.
>>> 
>>> Keep safe;
>>> 
>>> Pascal
>>> 
>>> From: NANOG <mailto:nanog-bounces+pthubert=cisco@nanog.org> On 
>>> Behalf Of Justin Streiner
>>> Sent: dimanche 27 mars 2022 18:12
>>> To: Abraham Y. Chen <mailto:ayc...@avinta.com>
>>> Cc: NANOG <mailto:nanog@nanog.org>
>>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
>>> 202203261833.AYC
>>> 
>>> Abe:
>>> 
>>> To your first point about denying that anyone is being stopped from 
>>> working on IPv4, I'm referring to users being able to communicate via 
>>> IPv4.  I have seen no evidence of that.
>>> 
>>> I'm not familiar with the process of submitting ideas to IETF, so I'll 
>>> leave that for others who are more knowledgeable on that to speak up 
>>> if they're so inclined.
>>> 
>>> Thank you
>>> jms
>>> 
>>> On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
>>> <mailto:ayc...@avinta.com>
>>> wrote:
>>> 
>>> 1)"... no one is stopping anyone from working on IPv4 ... ":   
>>> After all these discussions, are you still denying this basic issue? 
>>> For example, there has not been any straightforward way to introduce 
>>> IPv4 enhancement ideas to IETF since at least 2015. If you know the 
>>> way, please make it public. I am sure that many are eager to learn 
>>> about it. Thanks.
>>> 
>>> 
>>> 
>>> Virus-free. https://www.avast.com/sig-
>>> email?utm_medium=email_source=link_campaign=sig-
>>> email_content=emailclient_term=link
>>> 
>>> 
>> 

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

[Pascal Thubert (pthubert) via NANOG]

>> mailto:strein...@gmail.com
>> Cc: NANOG mailto:nanog@nanog.org
>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>> 
>> Hi, Pascal:
>> 
>> What I would appreciate is an IP packet header design/definition 
>> layout, word-by-word, ideally in bit-map style, of an explicit 
>> presentation of all IP addresses involved from one IoT in one realm to 
>> that in the second realm. This will provide a clearer picture of how 
>> the real world implementation may look like.
>> 
>> Thanks,
>> 
>> 
>> Abe (2022-04-01 09:48)
>> 
>> 
>> On 2022-04-01 08:49, Vasilenko Eduard wrote:
>> As I understand: “IPv4 Realms” between “Shaft” should be capable to 
>> have a plain IPv4 header (or else why all of these).
>> Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
>> Who should implement this gateway and why? He should be formally 
>> appointed to such an exercise, right?
>> Map this 2 level hierarchy to the real world – you may fail with this.
>> Ed/
>> From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
>> Sent: Friday, April 1, 2022 3:41 PM
>> To: Vasilenko Eduard mailto:vasilenko.edu...@huawei.com; Justin 
>> Streiner mailto:strein...@gmail.com; Abraham Y. Chen 
>> mailto:ayc...@avinta.com
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>> 
>> Hello Eduard:
>> 
>> Did you just demonstrate that POPs cannot exist? Or that there cannot 
>> be a Default Free Zone?
>> I agree with your real world issue that some things will have to be 
>> planned between stake holders, and that it will not be easy.
>> But you know what the French say about “impossible”.
>> Or to paraphrase Sir Arthur, now that we have eliminated all the 
>> impossible transition scenarios, whatever remains…
>> 
>> There will be YADA prefixes just like there are root DNS. To be 
>> managed by different players as you point out. And all routable within 
>> the same shaft.
>> 
>> Keep safe;
>> 
>> Pascal
>> 
>> From: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com>
>> Sent: vendredi 1 avril 2022 14:32
>> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin 
>> Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
>> <mailto:ayc...@avinta.com>
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>> 
>> Hi Pascal,
>> In general, your idea to create a hierarchy is good.
>> In practice, it would fail because you have created a virtual 
>> hierarchy that does not map to any administrative border. Who should 
>> implement gateways for the “Shaft”? Why?
>> If you would appoint Carrier as the Shaft responsible then it is not 
>> enough bits for Shaft.
>> If you would appoint Governments as the Shaft responsible then would 
>> be a so big scandal that you would regret the proposal.
>> Hence, I do not see proper mapping for the hierarchy to make YADA 
>> successful.
>> Eduard
>> From: NANOG 
>> [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org]
>> On Behalf Of Pascal Thubert (pthubert) via NANOG
>> Sent: Friday, April 1, 2022 2:26 PM
>> To: Justin Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
>> <mailto:ayc...@avinta.com>
>> Cc: NANOG <mailto:nanog@nanog.org>
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>> 
>> For the sake of it, Justin, I just published 
>> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
>> The first section of the draft (YADA) extends IPv4 range in an 
>> IPv4-only world. For some people that might be enough and I’m totally 
>> fine with that.
>> 
>> Keep safe;
>> 
>> Pascal
>> 
>> From: NANOG <mailto:nanog-bounces+pthubert=cisco@nanog.org> On 
>> Behalf Of Justin Streiner
>> Sent: dimanche 27 mars 2022 18:12
>> To: Abraham Y. Chen <mailto:ayc...@avinta.com>
>> Cc: NANOG <mailto:nanog@nanog.org>
>> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>> 
>> Abe:
>> 
>> To your first point about denying that anyone is being stopped from 
>> working on IPv4, I'm referring to users being able to communicate via 
>> IPv4.  I have seen no evidence of that.
>> 
>> I'm not familiar with the process of submitting ideas to IETF, so I'll 
>> leave that for others who are more knowledgeable on that to speak up 
>> if they're so inclined.
>> 
>> Thank you
>> jms
>> 
>> On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
>> <mailto:ayc...@avinta.com>
>> wrote:
>> 
>> 1)"... no one is stopping anyone from working on IPv4 ... ":   
>> After all these discussions, are you still denying this basic issue? 
>> For example, there has not been any straightforward way to introduce 
>> IPv4 enhancement ideas to IETF since at least 2015. If you know the 
>> way, please make it public. I am sure that many are eager to learn 
>> about it. Thanks.
>> 
>> 
>> 
>> Virus-free. https://www.avast.com/sig-
>> email?utm_medium=email_source=link_campaign=sig-
>> email_content=emailclient_term=link
>> 
>> 
> 

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

[Pascal Thubert (pthubert) via NANOG]

yers as you point out. And all routable within the same
> shaft.
> 
> Keep safe;
> 
> Pascal
> 
> From: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com>
> Sent: vendredi 1 avril 2022 14:32
> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin Streiner
> <mailto:strein...@gmail.com>; Abraham Y. Chen <mailto:ayc...@avinta.com>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Hi Pascal,
> In general, your idea to create a hierarchy is good.
> In practice, it would fail because you have created a virtual hierarchy
> that does not map to any administrative border. Who should implement
> gateways for the “Shaft”? Why?
> If you would appoint Carrier as the Shaft responsible then it is not
> enough bits for Shaft.
> If you would appoint Governments as the Shaft responsible then would be a
> so big scandal that you would regret the proposal.
> Hence, I do not see proper mapping for the hierarchy to make YADA
> successful.
> Eduard
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org]
> On Behalf Of Pascal Thubert (pthubert) via NANOG
> Sent: Friday, April 1, 2022 2:26 PM
> To: Justin Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen
> <mailto:ayc...@avinta.com>
> Cc: NANOG <mailto:nanog@nanog.org>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> For the sake of it, Justin, I just published
> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
> The first section of the draft (YADA) extends IPv4 range in an IPv4-only
> world. For some people that might be enough and I’m totally fine with
> that.
> 
> Keep safe;
> 
> Pascal
> 
> From: NANOG <mailto:nanog-bounces+pthubert=cisco@nanog.org> On Behalf
> Of Justin Streiner
> Sent: dimanche 27 mars 2022 18:12
> To: Abraham Y. Chen <mailto:ayc...@avinta.com>
> Cc: NANOG <mailto:nanog@nanog.org>
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Abe:
> 
> To your first point about denying that anyone is being stopped from
> working on IPv4, I'm referring to users being able to communicate via
> IPv4.  I have seen no evidence of that.
> 
> I'm not familiar with the process of submitting ideas to IETF, so I'll
> leave that for others who are more knowledgeable on that to speak up if
> they're so inclined.
> 
> Thank you
> jms
> 
> On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen <mailto:ayc...@avinta.com>
> wrote:
> 
> 1)    "... no one is stopping anyone from working on IPv4
> ...     ":   After all these discussions, are you still denying this basic
> issue? For example, there has not been any straightforward way to
> introduce IPv4 enhancement ideas to IETF since at least 2015. If you know
> the way, please make it public. I am sure that many are eager to learn
> about it. Thanks.
> 
> 
> 
> Virus-free. https://www.avast.com/sig-
> email?utm_medium=email_source=link_campaign=sig-
> email_content=emailclient_term=link
> 
> 

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

[Pascal Thubert (pthubert) via NANOG]

t; different players as you point out. And all routable within the same
> shaft.
> 
> Keep safe;
> 
> Pascal
> 
> From: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com>
> Sent: vendredi 1 avril 2022 14:32
> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin Streiner
> <mailto:strein...@gmail.com>; Abraham Y. Chen <mailto:ayc...@avinta.com>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Hi Pascal,
> In general, your idea to create a hierarchy is good.
> In practice, it would fail because you have created a virtual hierarchy
> that does not map to any administrative border. Who should implement
> gateways for the “Shaft”? Why?
> If you would appoint Carrier as the Shaft responsible then it is not
> enough bits for Shaft.
> If you would appoint Governments as the Shaft responsible then would be a
> so big scandal that you would regret the proposal.
> Hence, I do not see proper mapping for the hierarchy to make YADA
> successful.
> Eduard
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org]
> On Behalf Of Pascal Thubert (pthubert) via NANOG
> Sent: Friday, April 1, 2022 2:26 PM
> To: Justin Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen
> <mailto:ayc...@avinta.com>
> Cc: NANOG <mailto:nanog@nanog.org>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> For the sake of it, Justin, I just published
> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
> The first section of the draft (YADA) extends IPv4 range in an IPv4-only
> world. For some people that might be enough and I’m totally fine with
> that.
> 
> Keep safe;
> 
> Pascal
> 
> From: NANOG <mailto:nanog-bounces+pthubert=cisco@nanog.org> On Behalf
> Of Justin Streiner
> Sent: dimanche 27 mars 2022 18:12
> To: Abraham Y. Chen <mailto:ayc...@avinta.com>
> Cc: NANOG <mailto:nanog@nanog.org>
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> Abe:
> 
> To your first point about denying that anyone is being stopped from
> working on IPv4, I'm referring to users being able to communicate via
> IPv4.  I have seen no evidence of that.
> 
> I'm not familiar with the process of submitting ideas to IETF, so I'll
> leave that for others who are more knowledgeable on that to speak up if
> they're so inclined.
> 
> Thank you
> jms
> 
> On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen <mailto:ayc...@avinta.com>
> wrote:
> 
> 1)    "... no one is stopping anyone from working on IPv4
> ...     ":   After all these discussions, are you still denying this basic
> issue? For example, there has not been any straightforward way to
> introduce IPv4 enhancement ideas to IETF since at least 2015. If you know
> the way, please make it public. I am sure that many are eager to learn
> about it. Thanks.
> 
> 
> 
> Virus-free. https://www.avast.com/sig-
> email?utm_medium=email_source=link_campaign=sig-
> email_content=emailclient_term=link
> 
> 

RE: V4 via V6 and IGP routing protocols

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-san

> it is hopeless.

If you look at it, LS - as OSPF and ISIS use it -  depends on the fact that all 
nodes get the same information and react the same way. Isn't that hopeless too?

Clearly, the above limits LS applicability to stable links and topologies, and 
powered devices. This is discussed at length in 
https://datatracker.ietf.org/doc/html/draft-ietf-roll-protocols-survey. OLSRv2 
pushes the model to its limit, don't drive it any faster.

We have a panel of protocols and it's probably a question of selecting the best 
fit for a use case. And yes, probably for most people in this list, learning a 
stable topology with a link state protocol is the best choice available. To the 
point of this thread, BABEL thinks inside the same box as its DV predecessors, 
so I expect that the reasons for selecting LS inside your network would still 
apply.

RIFT (https://datatracker.ietf.org/doc/draft-ietf-rift-rift/) shows that 
evolution outside that box is possible. RIFT develops anisotropic routing 
concepts (arguably from RPL) and couples DV and LS to get the best of both 
worlds. So it's not definitely either/or LS/DV after all.

But none of the above allow an source router to decide once and for all what it 
will get. Because the routing decision is made again at each hop in a fashion 
that may contradict one of the previous hops. From there, it's either 
micro-loops or freezing, and in both cases, transient interruption of service. 
Isn't that hopeless too?

The real issues of that thinking inside the ususal box are 1) that packets 
should "follow the arrows" along a path which certainly leads to loss when one 
link or node is broken along the arrows, and 2) greediness. All the protocols 
above are greedy, meaning that every hop that a packet made has to be progress 
towards the destination, and this dramatically reduces the opportunity to 
forward packets to destination.

When you drive and the street is blocked, you can U-turn around the block and 
rapidly restore the shortest path. The protocols above will not do that; this 
is why technologies such as LFA were needed on top. But then the redundancy is 
an add-on as opposed to a native feature of the protocol. 

Thinking outside that box would then mean:
- To your end-to-end principle point, let the source decide the packet 
treatment (including path) based on packet needs
- congruence with shortest path when there is no breakage
- neither micro-loop nor freeze when there's a breakage, 
- something like LFA-inside to survive one breakage, and possibly multiple 
ones, along the way

While DV is capable to form Non-ECMP DAGs while inside-the-box LS is not, I 
will agree with you that DV is quite hopeless to achieve the goals above. This 
is why my personal favorite can be classified as an LS protocol done 
differently. 

What it does is:
- use the LSDB as is
- reverse SPF so the destination computes the tree "towards self" as opposed to 
"towards everybody else" - this just means use the incoming metric
- tweak SPF to stitch selected branches in the tree to build "LFA-like" 
alternates, forming arcs that end in other arcs till destination, as opposed to 
arrows to be followed
- add a step where the destination injects the path towards self along that 
path but reversed, using source routing in the control plane and tweaked to 
transport a serialized graph. 

Yet another sleeping beauty on the other side of the PM wall, waiting for the 
kiss of a sizable market. Hint, it's not the ill-fated U-Turn protocol, that 
one had its own issues.

Keep safe;

Pascal



  



> -Original Message-
> From: NANOG  On Behalf Of
> Masataka Ohta
> Sent: dimanche 3 avril 2022 15:46
> To: nanog@nanog.org
> Subject: Re: V4 via V6 and IGP routing protocols
> 
> Dave Taht wrote:
> 
> > Periodically I still do some work on routing protocols. 12? years ago
> > I had kind of given up on ospf and isis, and picked the babel protocol
> > as an IGP for meshy networks because I felt link-state had gone as far
> > as it could and somehow unifying BGP DV with an IGP that was also DV
> > (distance vector) seemed like a path forward.
> 
> As DV depends other routers to choose the best path from several
> candidates updated asynchronously, which means it is against the E2E
> principle and decisions by other routers are delayed a lot to wait all the
> candidates are updated, it is hopeless.
> 
> OTOH, LS only allows routers distribute the current most link states
> instantaneously and let end systems of individual routers compute the best
> path, LS converges quickly.
> 
> BGP is DV because there is no way to describe policies of various domains
> and, even if it were possible, most, if not all, domains do not want to
> publish their policies in full detail.
> 
> > My question for this list is basically, has anyone noticed or fiddled
> > with babel?
> 
> No.
> 
>   Masataka Ohta

RE: V4 via V6 and IGP routing protocols

[Pascal Thubert (pthubert) via NANOG]

Hello Dave:

There's RFC 8950 in the context of BGP. That's a refresher of RFC 5589 which is 
the one we typically refer to internally.

I glanced at homenet too early, and then too late. Too early, it seemed that 
the protocol would be OSPFv3; no discussion. So I left till too late, when the 
choice was between ISIS and BABEL, and the group would not even consider 
arguments.

RPL seemed to do the trick without the need to define anything new, in my book. 
It supports multihoming by defining as many topologies, no need for 
source/destination, radios, IoT, mobility, things you'll find at home. But hey, 
those of us who understand RPL were not there at the right time and there we 
get yet another fragmentation. Not the IETF at its best.

Nothing against BABEL, it's neat. Well written specs, much better than we did 
with RPL. A modernized DV, addressing the same space as RIP or EIGRP - though I 
really like the DUAL piece in EIGRP. More of a core technology than of an 
edge/mobile like RPL, they could be complementary. And then BABEL has a nice 
dynamic community including openWRT developers, that's a huge strength.

Not sure you'll find it in your usual vendor hardware though. 

Keep safe;

Pascal

> -Original Message-
> From: NANOG  On Behalf Of Dave
> Taht
> Sent: lundi 4 avril 2022 2:56
> To: Mark Tinka 
> Cc: NANOG 
> Subject: Re: V4 via V6 and IGP routing protocols
> 
> On Sun, Apr 3, 2022 at 12:04 PM Mark Tinka  wrote:
> >
> >
> >
> > On 4/3/22 13:55, Dave Taht wrote:
> >
> > > Periodically I still do some work on routing protocols. 12? years
> > > ago I had kind of given up on ospf and isis, and picked the babel
> > > protocol as an IGP for meshy networks because I felt link-state had
> > > gone as far as it could and somehow unifying BGP DV with an IGP that
> > > was also DV (distance vector) seemed like a path forward.
> >
> > To scale the IGP, we only carry Loopbacks and interfaces (backbone
> > infrastructure) in the IGP. Many operators have been doing this, for
> > some time now, as a best pratice.
> >
> > Customer routes as well as the DFZ is carried in iBGP.
> >
> > The only issue we have hit with this design is hardware that ships
> > with limited FIB (you're talking 4,000 slots or less). While this can
> > be mitigated with things like 6PE and RFC 3107, there are, now, tons
> > of hardware shipping without this physical restriction. For me, the
> > simpler, the better.
> >
> >
> > > My question for this list is basically, has anyone noticed or
> > > fiddled with babel? It's supported in FRR, bird, and a very small
> > > standalone daemon.
> >
> > Never heard of it as an IGP until now :-).
> 
> We'd somewhat foolishly made it a requirement in ietf homenet.
> 
> it was how hard adding source specific routing to isis turned out to be
> that turned me.
> At the time I needed simple means to get ipv6 working on multiple consumer
> uplinks.
> 
> That later spawned a now mostly dead attempt to unify ipv4 and ipv6
> address distribution called hnet.
> 
> I'm fiddling with the new ipv4 over ipv6 stuff now in trying to
> interconnect several ipv4 networks over multiple p2p links.
> 
> >
> > Googl'ing:
> >
> >  https://en.wikipedia.org/wiki/Babel_(protocol)
> >
> >
> > > To recap that:
> > >
> > > "V4-via-v6 routing is a routing technique that allows routers with
> > > only IPv6 addresses (including link-locals) to forward IPv4 packets.
> > > It doesn't involve encapsulation (tunnelling), it doesn't involve
> > > translation (NAT), it just works.  For details, please see
> >
> > Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry
> > IPv4 NLRI over an IPv6-only network. We never did implement that, as
> > IS-IS integrated both protocols already. But it's been there for a
> > while for OSPFv3.
> >
> > I don't know when (or if) other vendors implemented the same thing for
> > OSPFv3.
> >
> > That said, nearly any OSPF house I'm aware of still runs both OSPFv2
> > and
> > OSPFv3 side-by-side. I guess folk are probably unprepared to use
> > OSPFv3 for IPv4 NLRI.
> 
> I'm sad to hear that those two still have to co-exist. I'd given up on how
> static both routing protocols had become in light of my wireless
> requirements way back then, also memory requirements. Babel had turned out
> to be the only way to get teeny routers to route a few thousand ipv6
> routes as well as ipv4 over wifi mesh networks.
> 
> I figured it had made zero penetration outside of that world despite our
> efforts to get it into frr, bird, etc.
> 
> >
> > Mark.
> 
> 
> 
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> 
> Dave Täht CEO, TekLibre, LLC

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

[Pascal Thubert (pthubert) via NANOG]

ateway in the Shaft should change headers (from IPv4 to IPv6).
Who should implement this gateway and why? He should be formally appointed to 
such an exercise, right?
Map this 2 level hierarchy to the real world – you may fail with this.
Ed/
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
Sent: Friday, April 1, 2022 3:41 PM
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin 
Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
<mailto:ayc...@avinta.com>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot be a 
Default Free Zone?
I agree with your real world issue that some things will have to be planned 
between stake holders, and that it will not be easy.
But you know what the French say about “impossible”.
Or to paraphrase Sir Arthur, now that we have eliminated all the impossible 
transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be managed by 
different players as you point out. And all routable within the same shaft.

Keep safe;

Pascal

From: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Sent: vendredi 1 avril 2022 14:32
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Justin Streiner mailto:strein...@gmail.com>>; Abraham Y. 
Chen mailto:ayc...@avinta.com>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual hierarchy that 
does not map to any administrative border. Who should implement gateways for 
the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is not enough 
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so 
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Friday, April 1, 2022 2:26 PM
To: Justin Streiner mailto:strein...@gmail.com>>; Abraham 
Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG 
mailto:nanog-bounces+pthubert=cisco@nanog.org>>
 On Behalf Of Justin Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.



[Image removed by 
sender.]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>
Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>

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

[Pascal Thubert (pthubert) via NANOG]

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 
Sent: vendredi 1 avril 2022 15:49
To: Vasilenko Eduard ; Pascal Thubert (pthubert) 
; Justin Streiner 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi, Pascal:

What I would appreciate is an IP packet header design/definition layout, 
word-by-word, ideally in bit-map style, of an explicit presentation of all IP 
addresses involved from one IoT in one realm to that in the second realm. This 
will provide a clearer picture of how the real world implementation may look 
like.

Thanks,


Abe (2022-04-01 09:48)


On 2022-04-01 08:49, Vasilenko Eduard wrote:
As I understand: “IPv4 Realms” between “Shaft” should be capable to have a 
plain IPv4 header (or else why all of these).
Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
Who should implement this gateway and why? He should be formally appointed to 
such an exercise, right?
Map this 2 level hierarchy to the real world – you may fail with this.
Ed/
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
Sent: Friday, April 1, 2022 3:41 PM
To: Vasilenko Eduard 
<mailto:vasilenko.edu...@huawei.com>; Justin 
Streiner <mailto:strein...@gmail.com>; Abraham Y. Chen 
<mailto:ayc...@avinta.com>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hello Eduard:

Did you just demonstrate that POPs cannot exist? Or that there cannot be a 
Default Free Zone?
I agree with your real world issue that some things will have to be planned 
between stake holders, and that it will not be easy.
But you know what the French say about “impossible”.
Or to paraphrase Sir Arthur, now that we have eliminated all the impossible 
transition scenarios, whatever remains…

There will be YADA prefixes just like there are root DNS. To be managed by 
different players as you point out. And all routable within the same shaft.

Keep safe;

Pascal

From: Vasilenko Eduard 
mailto:vasilenko.edu...@huawei.com>>
Sent: vendredi 1 avril 2022 14:32
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Justin Streiner mailto:strein...@gmail.com>>; Abraham Y. 
Chen mailto:ayc...@avinta.com>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual hierarchy that 
does not map to any administrative border. Who should implement gateways for 
the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is not enough 
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so 
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org] On 
Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Friday, April 1, 2022 2:26 PM
To: Justin Streiner mailto:strein...@gmail.com>>; Abraham 
Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

For the sake of it, Justin, I just published 
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world. 
For some people that might be enough and I’m totally fine with that.

Keep safe;

Pascal

From: NANOG 
mailto:nanog-bounces+pthubert=cisco@nanog.org>>
 On Behalf Of Justin Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen mailto:ayc...@avinta.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-san

> > - there's no way to know if 2 locations are OK (anycast)
> 
> If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address,
> it is just broken not useful for any purpose and ignored.

One case I have in mind is when one wants to bundle multiple physical 
interfaces as one logical P2MP interface that reaches different routers, e.g., 
for server multihoming. 

There's a single owner and a single address, but it is presented to both 
routers on different physical interfaces and can be routed to any of those. 
Then the routers inject the address in some overlay and may fight unless they 
realize that they work on behalf of the same end point.

Basically I'm talking about a proper L3 abstraction for cases where LAG / 
Etherchannel are used today. K8S needs a unique IP like that.

> Instead, IPv4 style anycast is widely deployed for IPv6.

I guess you mean the one we configure on a server loopback for load balancing? 
Certainly. The end result is the same for the routing (weighted ECMP) so for 
all I know we can use the same signals.

Keep safe;

Pascal

 

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Actually, Owen, now the day has come, I can say I love it.

No one likes tradeoffs. No one wants to compromise.

Ryland just told us we have a near perfect title for a spec that is bound to be 
hated.

Keep safe;

Pascal



From: Owen DeLong 
Sent: mercredi 30 mars 2022 22:33
To: Ryland Kremeier 
Cc: Pascal Thubert (pthubert) ; Philip Homburg 
; nanog@nanog.org; 'jordi.palet' 
(jordi.pa...@consulintel.es) 
Subject: Re: V6 still not supported

I think this message is 4 days early.

Owen



On Mar 28, 2022, at 11:03 , Ryland Kremeier 
mailto:rkreme...@barryelectric.com>> wrote:

[cid:image001.png@01D842A4.69CBE6F0]

Hmm.

-Original Message-
From: NANOG 
mailto:nanog-bounces+rkremeier=barryelectric@nanog.org>>
 On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg 
mailto:pch-nano...@u-1.phicoh.com>>; 
nanog@nanog.org<mailto:nanog@nanog.org>; 'jordi.palet' 
(jordi.pa...@consulintel.es<mailto:jordi.pa...@consulintel.es>) 
mailto:jordi.pa...@consulintel.es>>
Subject: RE: V6 still not supported

Seems that we lost sync.

I would not rephrase so I made it a draft to make it easy to socialize: 
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html


The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I 
agree you need the traditional transition mechanisms, CG-NATs etc.

The plan has 2 phases:

- The first phase called YADA extends the reach of IPv4 using a common IPv4 
space that is like an elevator shaft.


 /--
/ /
   /  ||realm 1  /
  /  /.   /./
 /  / . shaft/ .  (current IPv4 Internet)  /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm 2  /
  /| /. | /./
 / |/ . shaft   |/ .   /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
   |  . |  |
   ||  .
   ||  .
   ..  |
   ..  |
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm N  /
  /| /  | / /
 / |/   shaft   |/ /
/  || /
   / /
  --/

There's more in the draft as to how forwarding happens. But only a few routers 
serving the shaft have to do anything and it's dead simple.
In that phase, we can now have many realms that are parallel to the IPv4 
Internet of today. IPv4 acts as normal in each realm.
The phase upgrades IPv4 host to understand an IP in IP format that allows to 
traverse the shaft. At that time, scale is no more the issue for  IPv4.

- The second phase called YATT does a stateless translation between a v4 in v4 
and a v6 address. No CG-NAT.

+-+---+--+-+
|YATT | Realm | IPv4 | Well-Known  |
|Space|Address|Address   |  IID|
+-+- -+--+-+
   <- YADA
Prefix ->
<   YATT Prefix -->

What it does is allow any node that needs to talk to a legacy device, to 1) 
obtain a YADA address (IPv4 pair), 2) form a YATT address (YADA derived IPv6 
address), and talk to the YADA node, across any of v4 or v6 networks. A 
stateful bump in the stack can NAT the IP pairs into single Ips and back. A 
bump in the stack on the legacy host can NAT the IP pairs into single Ips as 
well.

In that phase, IPv6 can be seen as the sphere that that encompasses the planes 
above, and a lot more. Every node that has a YADA address owns a full IPv6 
prefix automatically. Nodes and networks can migrate to IPv6 only but the nodes 
that need to talk to IPv4 nodes need an YATT address for that.

There will be corner cases, like well-known IPv4 coded in legacy application 
payload. For those arguably we'

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

[Pascal Thubert (pthubert) via NANOG]

There are 2 ways to stop a war:

1) one side it utterly defeated and disaggregated
2) both sides suffered enough and agree to start thinking of the best terms for 
coexistence

1) is not close to happening any time soon

From this, the conclusion is that we have not suffered enough.

On the side, the IETF has its own Tao for consensus and such things.
See section 4.2 of https://www.ietf.org/about/participate/tao/

As a WG chair, I happen to have to figure consensus out. It's a rough and very 
human process. It has to do with feeling of support from the room and the 
mailing list. It has also to do with insuring that all technically valid 
objections found an answer, even if the opponent is a minority.

For work that does not have a home, there's always the Int Area WG.

And for those who think we already reached 2) after only 20 years, there's 
always the discussion on the original thread, and the yada-yatt draft.

Keep safe;

Pascal


> -Original Message-
> From: NANOG  On Behalf Of Joe
> Maimon
> Sent: vendredi 1 avril 2022 5:46
> To: Owen DeLong 
> Cc: NANOG 
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Owen DeLong wrote:
> >
> > Yep… He’s absolutely right… We need to find a way to get the networks
> > that aren’t deploying IPv6 to get off the dime and stop holding the rest of
> the world hostage in the IPv4 backwater.
> >
> > Owen
> >
> >
> 
> You keep championing that approach, essentially unchanged for the past
> 20 years with an impressive record of partial success and much failure and I
> will fully support and applaud your efforts in doing so. I will also hope
> that it doesnt take another 20 to finally succeed, because as you point out,
> you require an extremely high level of participation before its Mission
> Accomplished.
> 
> And its not unreasonable to expect that until that approach succeeds, that
> others' efforts to work on the ongoing problem receive the same support and
> encouragement.
> 
> IPv6 uber-alles adherents had more than enough time to claim it was going to
> solve the problem without any need for anything else and to "request" (quite
> strongly and wrongly so in my opinion) that everyone rally their efforts
> around that.
> 
> Now its time for those adherents to reciprocate.
> 
> And here is a little bit of constructive criticism to the Evangelical
> approach. Essentially, you need to pivot from how their efforts can save the
> world into how their efforts can benefit themselves.
> 
> You want more people to use IPv6? Make it worth their while. Lower the
> barriers the cost the risks and increase the bennies.
> 
> The early adopters, the activists, those who define themselves by their
> altruism you already got.
> 
> Dont be surprised when so many balk at doing things they have no particular
> defined need or interest in doing when the primary beneficiaries arent
> themselves, but the primary cost carriers are.
> 
> Or we can just wait and see how the natural course of events eventually plays
> out. Still looks likely that IPv6 will eventually take over the internet, but
> it sure would be nice if IPv4 did not become completely unusable before that
> manages to occur.
> 
> Joe

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

[Pascal Thubert (pthubert) via NANOG]

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  On Behalf Of Justin 
Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen 
Cc: NANOG 
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Abe:

To your first point about denying that anyone is being stopped from working on 
IPv4, I'm referring to users being able to communicate via IPv4.  I have seen 
no evidence of that.

I'm not familiar with the process of submitting ideas to IETF, so I'll leave 
that for others who are more knowledgeable on that to speak up if they're so 
inclined.

Thank you
jms

On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

He he, why do you think YADA starts with yet another?

The devil is in the details I guess. AA makes A twice longer, that's the easy 
piece. But then, what is the story for the A->AA transition?

The key piece the concept of the shaft, that enables to transit AA between 
levels while seeing plain IPv4 in each realm. It is as necessary for parallel 
planes as RFC 1918 is necessary for the private domains. In fact that could be 
seen as the reverse. The Internet connects multiple private domains using NATs. 
The shaft connects multiple internets using IP-in-IP. But it has to be the 
exact same (assigned) IPv4 footprint at every layer.

But for any of that to happen you need at least a IANA assignment and a Linux 
or two that play ball. We need to think that through before we waste the last 
IPv4 free land, or assign 240.0.0.0/4

Agreed, the publication for the link below day is incredibly timely. Such is 
the request to pay for natural resources with a declining currency. 

Let us assign the YADA prefix and start experiment 2, baby step 1.

Keep safe;

Pascal

> -Original Message-
> From: Rubens Kuhl 
> Sent: vendredi 1 avril 2022 12:32
> To: Pascal Thubert (pthubert) 
> Cc: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> > Are you ready for that, or should we wait another 80 years with dual stack
> and gigantic stateful NATs?
> 
> That's what this network is going to do:
> https://www.aa.net.uk/etc/news/ipv6-end-of-trial/
> 
> There is something odd about the day this was published, though.
> 
> 
> Rubens

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

A very long thread.

Face it: everyone is right, and even technically correct. There's no good and 
evil. We'd know, after 20 years. 

I live in France and my country has a famous 100-years war in its long history 
with England. Do we want to beat this here?

The plain truth:

- IPv4 is here to stay. Some v4-only nodes and functionalities are here to 
stay. Plenty of reasons for that in this thread.
- IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 only 
in that space, numbers only growing


The things everyone agrees upon:
- Dual stack everywhere and forever is the worst of both worlds as it doubles 
every cost, and that will remain long as the war rages
- Stateful NATs the size of the Internet not doable, which in my book says that 
isolation not only unavoidable but already there.

An the illusions:

- any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm 
not talking security but plain functionality. And yes, exceptions if they are 
few can be handled by expensive stateful NATs when the cost is justified
- the Internet is a big homogenous thing. The more it expands, the more we see 
domains forming where specific capabilities are deployed, and because we fail 
to handle that at L3, we mask the functionalities above UDP. 

If we agree on the above then a compromise is possible. Ideally, the compromise 
would:
- maintain the current state of v4 affairs for those who want that
- scale v4 addresses for those who want that
- provide v4 to v6 stateless NATs for this who want that, and
- allow networks to be either of the 2 versions for those who want that. 

SciFi? There's a proposed starting point for that compromise in the yada-yatt 
draft published at IETF v6ops. The key is to use baby steps between locations 
(in the transition plan) where people can be at ease and stay as long as they 
want to, as opposed to enforcing a giant zero-to-hero illusionary step.

Are you ready for that, or should we wait another 80 years with dual stack and 
gigantic stateful NATs?

Pascal

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

> 
> Pascal Thubert (pthubert) wrote:
> 
> > You're perfectly correct. This is exactly what the registration would
> > be for. I'm concerned about its adoption that I do not see coming on
> > Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
> > worse*.
> 
> You can't expect people still working primarily on v6 have much sense of
> engineering.

That includes me

> 
> > * APs today snoop DHCP; DHCP is observable and stateful, with a
> > lifetime that allows to clean up. So snooping it is mostly good enough
> > there. The hassle is the SL in SLAAC which causes broadcasts and is
> > not deterministically observable; this problem is specific to IPv6. We
> > already have the registration to avoid snooping DHCP and SLAAC; yet we
> > do not observe any adoption in mainline APs and STAs.
> 
> As broadcast/multicast packets are first sent to APs as unicast packets with
> ACKs, snooping by APs should be reliable at L2.

Well, up to the N retries. After that the stack is not even aware that the 
multicast was not delivered. 

Oh but that's just the beginning of the story; yes we mostly can form an 
initial state and it mostly appears to work and people are mostly satisfied. 
And then you realize:

- there's no way to know how long the device will you that address
- there's no way to know how many addresses the device will form
- there's no way to know how many addresses the device has already formed and 
which (at least MLD can do that)
- there's no clean way to know is an address is still in use (e.g., without 
reviving it in the host stack)
- there's no way to know which is the most recent location of the address 
(unless you have a fine time distribution and that costs)
- there's no way to know if 2 locations are OK (anycast)
- there's no way to know for sure that the claimer is the owner

Snooping DHCP you expect:
- one address per MAC (that's it's pretty limiting but that protects the 
network)
- A MAC address or least a unique ID to differentiate duplicates (but not 
recognize a thief)
- An upper bound for the state lifetime based on the lease

Certainly a bad guy doing impersonation and DOS can play havoc in such network, 
but at least between good guys we get something we can operate.

I'm not saying that snooping DHCP is fully deterministic but it's orders of 
magnitude better than snooping SLAAC when it comes to forming a state like an 
association than SLAAC. Knowing that you base things like EVPN on such state, 
using SLAAC is building on sand.

Ideally you'd want:
- a negotiated contract for a number of addresses with a lifetime, etc
- a provable ownership so we route to the legitimate owner and can do SAVI
- a sense of mobility so we can route the packets to the latest location
- a sense of anycast vs unicast so we can install routing properly based on that
- the capability to indicate whether the address should be redistributed, a 
sense of weight in ECMP, etc...

We've done just that, and with that, we're effectively providing a 
deterministic state that we can redistribute in routing or ARP/ND proxy.

In the case of EVPN that gives this:
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling

Then again, retrofitting the ND registration for IPv4 addresses is piece of 
cake, but IPv4 is DHCP only and the pain does not really feel; so people may 
not be inclined to make the steps for IPv4. To be seen.

> 
> So, by snooping DAD, which is ugly, ARP table can be constructed.

A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, 
start populating the hot-line before you turn the lights on 

> 
> A problem, however, is that there is no ACK above L2, that is, there is no
> end to end ACK, which means, if something goes wrong above L2, the result can
> be weird.

Yes, and all the other things above. E.g., a DAD coming from the wire that is 
sent over the wireless is not deterministically delivered and a duplicate is 
often missed. I do not need to continue the endless list do I?

Keep safe;

Pascal

> 
>   Masataka Ohta

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

[Pascal Thubert (pthubert) via NANOG]

Hi Eduard

And SDN, and overlays, and... I certainly agree with what you're saying. 

This is why the L3 tech has to keep evolving as a survival trait. It's a 
delicate balance between evolving too quickly and producing the impression on 
unstable tech in the one hand, and stalling in the prehistory that you describe 
on the other, ask a dino when you meet one.

I argue that there are IPv6 RFCs to accommodate the cases I've seen on this 
list, but that the capabilities are largely ignored and -consequently- did not 
necessarily pass the PM barrier. Stalled we are indeed, but not for the lack of 
IETF work.

Keep safe;

Pascal



> -Original Message-
> From: NANOG  On Behalf Of
> Vasilenko Eduard via NANOG
> Sent: jeudi 31 mars 2022 14:36
> To: Joe Maimon ; Tom Beecher 
> Cc: NANOG 
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994
> that:
> 
> - Wireless would become so popular (WiFi is from 1997) and wireless would
> emulate multicast so badly (hi SLAAC)
> - Hardware forwarding (PFE) would be invented (1997) that would have a big
> additional cost to implement Enhanced Headers
> - Encryption would never have a small enough cost to make it mandatory
> - Router would be available in every smallest thing that makes distributed
> address acquisition redundant (hi SLAAC)
> 
> We should be fair - it was not possible to guess.
> 
> Ed/
> -Original Message-
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 3:01 AM
> To: Tom Beecher 
> Cc: NANOG 
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Tom Beecher wrote:
> >
> > If the IETF has really been unable to achieve consensus on properly
> > supporting the currently still dominant internet protocol, that is
> > seriously problematic and a huge process failure.
> >
> >
> > That is not an accurate statement.
> >
> > The IETF has achieved consensus on this topic. It's explained here by
> > Brian Carpenter.
> >
> > https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> > yAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as
> amongst stakeholders and IPv6 specific related stakes are not relevant to
> IPv4. If you consider the reverse to be true as well, I think my version of
> consensus would achieve a much wider and diverse consensus than the the
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it
> as though it maintains its own reality field.
> 
> >
> > He expressly states with many +1s that if something IPv4 related needs
> > to get worked on , it will be worked on,
> 
> IPv4 still needs address exhaustion solutions.
> 
> > but the consensus solution to V4 address exhaustion was IPng that
> > became IPv6, so that is considered a solved problem.
> 
> IPv6 is not a solution. Its a replacement that does not have the same
> problem. Which could be a solution to the problem, but only if the
> replacement happens on schedule. However, so long as the replacement hasnt
> happened, we still are dealing with the problem.
> 
> The IETF made a stupendously bad bet that IPv6 would happen in time.
> That is the kind of bet that you better be right about. They were a
> decade+ wrong. That they have the audacity and temerity to continue
> doubling down on that would be funny if it wasnt so outrageous, wrong and
> harmful.
> 
> Let us re-examine the premise. When did it become acceptable to quash work on
> one protocol because of the existence of another one that is preferred by the
> quashers?
> 
> Or in other words, the way you are framing things makes it seem as if the
> IETF has with intent and malice chosen to extend or at the very least ignore
> exhaustion issues for actual internet users so as to rig the system for their
> preferred outcome.
> 
> >
> > Some folks don't LIKE the solution, as is their right to do.
> 
> I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2
> resolution, not addressing policy, not the chaos of choice of inadequate
> interoperability approaches, not the denial of features desired by users, not
> the pmtud, not the fragmentation, and many other warts. I dont even like the
> notation schemes. They require multiple vision passes.
> 
> I do like the extra bits. Just not the way they are being frittered.
> 
> The real crux of the matter is that it did not work. Address exhaustion has
> not been alleviated. For many years now and who knows how much longer.
> 
> > But the problem of V4 address exhaustion is NOT the same thing as "I
> > don't like the solution that they chose."
> 
> The problem of V4 address exhaustion is NOT the same thing as 

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Fun, I had a parallel experience with NEMO that I implemented in IOS. 

But I mostly read the fate of MIP and NEMO as a lack of ask. Which is similar 
to the lack of desire today for the uplifts we made to IPv6 as a whole, and ND 
in particular.

Anyway, RPL has a lot to do with what we learned there, including the abstract 
objective function that yields the metrics you are talking about, typically 
including things like ETX/ETX^2, RSSI and LQI.

So yes, things that make sense eventually emerge.

Keep safe.

Pascal

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 14:10
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/31/22 7:44 AM, William Allen Simpson wrote:
> > [heavy sigh]
> >
> > All of these things were well understood circa 1992-93.
> >
> > That's why the original Neighbor Discovery was entirely link state.
> >
> > ND link state announcements handled the hidden terminal problem.
> 
> Also, it almost goes without saying that the original ND tried to handle the
> near-far problem.  For example, where I'm talking to a far away AP streaming
> to the TV in front of me.
> 
> At my home, I've had to wire the TV.  Streaming to the AP, then the AP
> sending the same traffic over the same wireless band to the TV caused lots of
> drops and jitter.
> 
> The near-far problem can be detected and solved.  That's the reason for the
> Metric field.
> 
> Furthermore, one of the messages in this thread mentioned trying to backport
> v6 features to v4.
> 
> We've already been down that road.  IPsec and MobileIP were developed for v6.
> After quitting the v6 project(s), I'd backported both of them to v4.  Like
> v6, then they were assigned to others who ruined them.
> Committee-itis at its worst.

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Don't sigh! You envisioned it and we built it, William.

We have IPv6 mesh networks with thousands on nodes per mesh deployed around 
you. The standard is called WI-SUN. WI-SUN totals millions of nodes deployed in 
North America; so what you described cannot not only be envisioned as you did, 
it can be built and deployed at scale, even on low power far reach wireless.

The core L3 components for Wi-SUN are RFC 8505 which is your link state ND 
thingy, RFC 6550 that does the routing over what OSPF called P2MP and which 
really means non-transitive, and RFC 9010 that redistribute the former in the 
latter. We are now working on registering multicast, anycast and prefixes in 
the same model.

It's just that the wired world (including operators) are mostly unaware of 
these capabilities. Whether they are even interested is not a given either. 
Louis the XVth said "après moi le déluge". I read pretty much the same thing on 
the list in the recent days as a migration strategy. 

Certainly, complaining from a comfort zone is a lot easier than acting out to 
solve the problem. "La critique est aisée mais l'art est difficile" is another 
good one.

I claim that bashing at the IETF for IPv6 as it was 20 years ago is unfair and 
that a little refresh / resync is in order. If what we produced since in an 
attempt to solve the issues you describe can help, then ask for it, amend it, 
say something, so something.

Today, decoupling the L1/2 (physical) network from the L3 abstractions of 
subnet and link is totally doable. This yields a world of possibilities for 
deployments. For all those (or the very few) who care, there's 
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-06

Keep safe;

Pascal

PS : When I say that DHCP mostly does the trick is not that I like it, but that 
customers (think EVPN) are reasonably happy with the result, while SLAAC is a 
lot worse for pretty much the whole collection of its design points, and cherry 
on the cake, the onlink model.

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 13:44
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:
> > * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime
> that allows to clean up. So snooping it is mostly good enough there. The
> hassle is the SL in SLAAC which causes broadcasts and is not
> deterministically observable; this problem is specific to IPv6. We already
> have the registration to avoid snooping DHCP and SLAAC; yet we do not observe
> any adoption in mainline APs and STAs.
> >
> 
> [heavy sigh]
> 
> All of these things were well understood circa 1992-93.
> 
> That's why the original Neighbor Discovery was entirely link state.
> 
> ND link state announcements handled the hidden terminal problem.
> (That is, where node A can hear node B, node B can hear node C, and node C
> can hear node A, but A cannot hear C.)  ND LSAs are/were flexible enough to
> handle both AP (cell) and mesh (AMPR) networks.
> 
> Thus, it was not reliant on central Access Points.  We envisioned mesh
> networks were the future.  Each node should handle its own discovery and
> routing.
> 
> SLAAC is bloat.
> 
> RIPv6 is bloat.
> 
> DHCPv6 is bloat.
> 
> Those are reasons operators have been complaining about IPv6.

RE: A straightforward transition plan (was: Re: V6 still not supported)

[Pascal Thubert (pthubert) via NANOG]

Hi Mark and all:

Indeed, we have a plethora of IPv4 encapsulation and 4-to-6 techniques. 

I read somewhere down the threads that we (at IETF) made a "stupendously" bad 
bet thinking that IPv6 would be generalized quickly thanks to those techniques.

Being partially guilty of that (e.g., but not limited to, USPTO 7,443,880 filed 
in 2004 that became 464XLAT), I can see that the 4-to-6 step involving CG NATs 
and all was a too big step to be taken. It's not a step, it's a 100m jump. 

Looking at it from a distance, I came to challenge that it is even a 
requirement to the transition plan. If we look at it, a stack that is not 
capable of IPv6 is now a legacy stack. It's ultimate goal is probably to 
connect a legacy IPv4 client application to a legacy IPv4 server and it will 
not need anything more in its whole life. For that use case, both app and 
server can live forever as they are, as far as the plan is concerned, provided 
that we continue to give them a 464XLAT or a DSlite tunnel, which is not that 
hard if the numbers are counted.

If we accept that connecting that legacy device with any future IPv6-only 
application is effectively a non-goal, then we open the thought process to a 
migration that takes several baby steps, each step easy to make, as opposed to 
the large one that proved unfeasible in 20 years. 

Instead, what we really want for this plan is to design feasible baby steps, 
each representing connectivity between a level of evolution and the next, BUT 
NOT attempting to provide connectivity between the first level (legacy IPv4 
only app) and the ultimate level (IPv6-only networks and servers). Something 
like  1<->2<->..<->N as opposed to 1<->N which proved unfeasible.

My view of the steps we'd need to make:

- extend the size of public IPv4 addressable realms. I read the ask in many 
threads in this list
- extend that to some IPv6-only end-points leveraging the above
- extend that to generic IPv6

With design constraints that make this deployable:
 
- allow IPv4-only network domains
- allow IPv6-only network domains  
- use stateless NATs only
- allow the NAT to be anywhere from bump in the stack to X-only realm borders

Does this seem desirable to you?

If so, yes, we can make that happen. Then we'll see how the IPvx domains play 
GO together, based on real usefulness vs cost.

Pascal



> -Original Message-
> From: NANOG  On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG 
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> 
> 
> > On 26 Mar 2022, at 21:51, Philip Homburg 
> wrote:
> >
> >>> If there is a magical transition technology that allows an IPv6-only
> >>> host t
> >> o
> >>> talk to an IPv4-only host, then let's deploy it.
> >>
> >> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
> >> protocol and see what happens!  (with more coming every year...)
> >
> > The problem with these is that they are not full solutions. That's why
> > we get new ones every year: everybody picks the subset of the problem
> > they want solve.
> >
> > To go over the ones you listed:
> > - 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4
> > infrastructure. Very useful when there was not a lot of IPv6 native.
> > Not a good approach for organisations that lack IPv4 addresses. Also
> > not a good approach if you want to switch off IPv4 at some point.
> > - DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an
> > IPv6-only backbone. Downstream from the CPE is dual stack. For this
> > reason those protocols do not see much use outside ISP networks. Got a
> > great transition technology because hosts will keep IPv4 until the
> > last IPv4 on the internet is gone. It is a bit of an IETF failure that
> > we have so many ways to connect a CPE to IPv4aaS.
> > - NAT64/DNS64. This is the closest to an actual transition technology.
> > Unfortunately it is completely flawed in too many ways.
> > - 464XLAT fixes many issues with NAT64/DNS64. The downside is again
> > that hosts have to have an IPv4 stack until forever and in addition to
> > that a complex IPv4-to-IPv6 translation module. That fails the
> > requirement that an IPv6 stack should have roughly the same complexity
> > as IPv4 and talk to IPv4-only.
> >
> > Basically, there is no solution to the transition problem. There are
> > lots of partial solutions, each with their own advantages and
> disadvantages.
> >
> > If we could go back in time, then developing NAT64 along with IPv6 and
> > making sure the translation really works including edge cases like
> > IPv4 literals, DNS A records, NAT traversal, etc. would have made a
> > difference.
> >
> > I don't know if such translation gateways were considered, I can't
> > recall much discussion about them. By the time the IPv6 socket API was
> > created it was already too late to get things like IPv4 literals right.
> 
> DS-Lite was designed to be implemented in the node.  You can run 

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-san

> An ARP table entry can be created when an IP address is assigned during
> registration process and destroyed if the registration is invalidated.
> 
> Or, do I misunderstand anything?

You're perfectly correct. This is exactly what the registration would be for. 
I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, 
even for v6 (SLAAC) where the problem is a lot worse*.

The IoT world already adopted the registration model, though. Millions of nodes 
on 802.15.4 radios are deployed to prove it works. We even redistribute RFC 
8505 in routing protocols that carry host routes in IoT networks (RPL), which 
is how we avoid your lookup issue on a wide low power mesh network.

Extending the registration to IPv4 is easy, we could even use mapped addresses 
and be done. But what magic will trigger attention / adoption when adoption is 
not showing in IPv6?

Keep safe;

Pascal


* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that 
allows to clean up. So snooping it is mostly good enough there. The hassle is 
the SL in SLAAC which causes broadcasts and is not deterministically 
observable; this problem is specific to IPv6. We already have the registration 
to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in 
mainline APs and STAs. 







> -Original Message-
> From: Masataka Ohta 
> Sent: mardi 29 mars 2022 10:57
> To: Pascal Thubert (pthubert) ; nanog@nanog.org
> Subject: Re: IPv6 "bloat" history
> 
> Pascal Thubert (pthubert) wrote:
> 
> > I tried exactly what you suggested for IPv6 with RFC 8505 and 8929.
> > But to few people in mainstream networks realize what you just said.
> 
> I found, theoretically by reading 802.11 specification, broadcast/multicast
> reliability problem and reported to
> IPv6 WG about 20 years ago. So, I'm pleased to know that some people
> recognize it as a real problem and worked on it. Thank you.
> 
> > It started long long ago with the idea to use inverse ARP for the
> > registration, I guess it is still doable but I am not optimistic about
> > adoption considering that v6 is a lot worse with more addresses and
> > DAD.
> 
> Aren't IP addresses are assigned from APs? Then, the APs can construct ARP
> table without actually running ARP or inverse ARP, I'm afraid.
> 
> > We are editing the piece on proxy ARP at this very moment at .11me.
> > APs are indeed supposed to proxy both v4 and v6. What is less clear is
> > how they form a deterministic state for that.
> 
> An ARP table entry can be created when an IP address is assigned during
> registration process and destroyed if the registration is invalidated.
> 
> Or, do I misunderstand anything?
> 
>   Masataka Ohta

Re: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-San

I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few 
people in mainstream networks realize what you just said.

It started long long ago with the idea to use inverse ARP for the registration, 
I guess it is still doable but I am not optimistic about adoption considering 
that v6 is a lot worse with more addresses and DAD.

We are editing the piece on proxy ARP at this very moment at .11me. APs are 
indeed supposed to proxy both v4 and v6. What is less clear is how they form a 
deterministic state for that.

Regards,

Pascal

> Le 28 mars 2022 à 15:55, Masataka Ohta  a 
> écrit :
> 
> William Allen Simpson wrote:
> 
> > After so many times reinventing the wheel, IP uber alles is a
> > better goal.  Speaking as somebody familiar with the effort.
> 
> I'm afraid you misunderstand my point.
> 
>> John Gilmore recently gave a good history of the ARP origin.
> 
> ARP is perfectly good for CSMA/CD but not so good
> for CSMA/CA where broadcast/multicast is unreliable.
> 
> So, with wifi, we should rely on repeated beacon from
> base stations for AR of the base stations and rely on
> unicast from clients to register them to base stations,
> which should act as proxy for communications between
> clients, which is a totally different protocol from ARP.
> 
> Without such recognition today, wifi users should be
> suffering from some inefficiencies when link is congested,
> which is often the case.
> 
> Other link technology should also require AR mechanism
> of its own.
> 
> As such, performing AR with IP is not so meaningful.
> Worse, even DHCP, which assumes reliable broadcast,
> does not work so efficiently over congested wifi.
> 
>Masataka Ohta

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Seems that we lost sync.

I would not rephrase so I made it a draft to make it easy to socialize: 
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html 


The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I 
agree you need the traditional transition mechanisms, CG-NATs etc.

The plan has 2 phases:

- The first phase called YADA extends the reach of IPv4 using a common IPv4 
space that is like an elevator shaft. 


 /--
/ /
   /  ||realm 1  /
  /  /.   /./
 /  / . shaft/ .  (current IPv4 Internet)  /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm 2  /
  /| /. | /./
 / |/ . shaft   |/ .   /
/  ||  .  /
   /   .  . .  . /
  --/
   |  . |  |
   |  . |  |
   ||  .
   ||  .
   ..  |
   ..  |
   |  . |  |
 /-||--|
/  |  . |  |  /
   /   |  |-|--|realm N  /
  /| /  | / /
 / |/   shaft   |/ /
/  || /
   / /
  --/

There's more in the draft as to how forwarding happens. But only a few routers 
serving the shaft have to do anything and it's dead simple.
 
In that phase, we can now have many realms that are parallel to the IPv4 
Internet of today. IPv4 acts as normal in each realm.
The phase upgrades IPv4 host to understand an IP in IP format that allows to 
traverse the shaft. At that time, scale is no more the issue for  IPv4.   

- The second phase called YATT does a stateless translation between a v4 in v4 
and a v6 address. No CG-NAT.

 +-+---+--+-+
 |YATT | Realm | IPv4 | Well-Known  |
 |Space|Address|Address   |  IID|
 +-+- -+--+-+
   <- YADA
Prefix ->
 <   YATT Prefix -->

What it does is allow any node that needs to talk to a legacy device, to 1) 
obtain a YADA address (IPv4 pair), 2) form a YATT address (YADA derived IPv6 
address), and talk to the YADA node, across any of v4 or v6 networks. A 
stateful bump in the stack can NAT the IP pairs into single Ips and back. A 
bump in the stack on the legacy host can NAT the IP pairs into single Ips as 
well.

In that phase, IPv6 can be seen as the sphere that that encompasses the planes 
above, and a lot more. Every node that has a YADA address owns a full IPv6 
prefix automatically. Nodes and networks can migrate to IPv6 only but the nodes 
that need to talk to IPv4 nodes need an YATT address for that.

There will be corner cases, like well-known IPv4 coded in legacy application 
payload. For those arguably we'll need a stateful CG-NAT that knows the mapping 
in advance. But maybe those are not many, and will mostly stay within their 
realm. 

Am I being any clearer now?

Keep safe;

Pascal


> -Original Message-
> From: NANOG  On Behalf Of
> Philip Homburg
> Sent: samedi 26 mars 2022 12:24
> To: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> >The only far ressemblance with 6to4 is the thing that was actually nice
> >in the  design, the automatic word in automatic tunnel. Which for the
> >rest of us mean s stateless. Compared to CGNATs that is huge.
> 
> Any form of communication with the current IPv4 internet requires some
> sort of CGNAT. We no longer have enough IPv4 addresses to give each
> customer an unique one. So some ISPs are forced to map multiple
> customers to a single IPv4 address. Which results in CGNAT. Technically,
> A+P (address plus port) mapping is a bit different, but for the customer
> that doesn't make a lot of difference. And A+P has serious scalability
> problems.
> 
> >Beyond that the proposal is not a tunnel and more akin to a nat64 since
> >it all ows v6 

Re: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Hello Phil

The only far ressemblance with 6to4 is the thing that was actually nice in the 
design, the automatic word in automatic tunnel. Which for the rest of us means 
stateless. Compared to CGNATs that is huge.

Beyond that the proposal is not a tunnel and more akin to a nat64 since it 
allows v6 nodes to talk to v4 nodes. The network can be pure v4 or pure v6 if 
the method is implemented as a bump in the stack at the wrong end.

Your response is also missing the capability to extend the IPv4 network a 
million times. Or drop it completely while maintaining IPv4 applications.

6to4 was meant for early v6 to interconnect islands. A solution for a problem 
that never really existed. Solutions without a problem aren’t usually popular.

Apparently here there’s a real world problem to be solved. Sophisms are of no 
help.


Regards,

Pascal

> Le 25 mars 2022 à 19:40, Philip Homburg  a écrit :
> 
> 
>> 
>> A host in the Internet that wants to talk to a host in China would require 
>> an 
>> update to parse new DNS double-A (realm, address) records to encapsulate the 
>> p
>> acket IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that 
>> ser
>> ves the shaft at level 1 attracts 240.0.0.0/8 within realm 1 and routes up 
>> the
>> elevator for more specific (host) routes within that prefix. The router that 
>> serves the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the 
>> s
>> aid packet it would swap the inner and outer destination and the packet 
>> would 
>> reach the Chinese address with classical routing within realm 2. 
>> 
>> Routers serving the shaft need an update, but then, only those do. Obviously 
>> t
>> he host in China can only reply if its stack is updated to understand the 
>> form
>> at. But all the other hosts and routers in China can be classical IPv4 as we 
>> k
>> now them long as their traffic stays in China. To migrate to IPv6 what you 
>> can
>> do is map the elevator shaft prefix in, say, 400::/3 (sadly cannot use F00/3 
>> that would map 240 neatly but is already assigned). 
>> 
>> The current internet would own 400:1::/32, China would own 400:2::/32, 
>> etc... 
>> You encode the double-A of the host in the prefix, reserve a well known 
>> suffix
>> for IPv4 mapped double-A, and you have an IPv6 address that can be mapped bot
>> h ways statelessly. When migrating to v6, each IPv4 node that owns a public 
>> IP
>> v4 address in one realm gets a full IPv6 /64 for free.
>> "
> 
> Somehow this sounds a lot like 6to4: packets get routed to special devices
> in the network and ISPs have little control over this. Not a popular
> architecture.
> 
> Or another way to look at it is the resemblance with the ill fated 
> 'Provider-Based Global Unicast Addresses' (RFC 1884, Section 2.4.7). This
> was not very popular either.
> 

Re: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Hello John

You’ve got something dead wrong about the history of IPR, there’s certainly no 
idea of monopoly. 

What we do when there’s market interest is write an RFC and RAND the rights. 
There is 25 years of IETF history to prove that. 

Another angle is that the change is in the host stack for the most part and we 
have no play in it. Without freedom for open source implementation the idea can 
not succeed.

You may wonder why we go through the hassle and cost?  The history of MPLS 
would certainly enlighten you on that. This is not a world where you can live 
without defensive weapons.

No one yet answered me on the technical aspects. That kind of baffles me.

Keep safe;

Pascal

> Le 25 mars 2022 à 03:17, John Gilmore  a écrit :
> 
> Pascal Thubert \(pthubert\) via NANOG  wrote:
>> I'm personally fond of the IP-in-IP variation that filed in 20+ years
>> ago as US patent 7,356,031.
> 
> No wonder -- you are listed as the co-inventor!
> 
> Just the fact that it is patented (and the patent is still unexpired)
> would make it a disfavored candidate for an Internet transition technology.
> 
> It was not nice of y'all to try to get a monopoly over nesting headers
> for making an overlay network that tunnels things to distant routers.
> You have to certify that your work is original in order to even apply
> for a patent.  So, nobody had ever thought of that before y'all did?  Really?
> 
>John
>

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

OK so you really did not read my post, even now. The tech I described was pure 
v4. It would pass your gateway.
The only we can talk is that we listen to each other... Quoting the text so you 
do not need to look it up:

"
My frustration is that indeed (as a dev guy) we have been trying hard to serve 
users our best. We proposed a number of things in the IPv4 evolution direction 
that I see being asked on this list. For larger IPv4 space and smooth 
migration, I'm personally fond of the IP-in-IP variation that filed in 20+ 
years ago as US patent 7,356,031. 

Basically we reserve a /8, say, since it is so popular at this time, 
240.0.0./8, and make it the "elevator shaft" between IPv4 realms. Say the 
current IPv4 Internet is realm 1, that Internet would have IP address 
240.0.0.1/8 in the shaft, and would continue operating as is, without a change 
in hosts and routers for traffic staying inside the current Internet. Now say 
China builds realm 2; that Internet would have IP address 240.0.0.2/8 in the 
shaft. 

A host in the Internet that wants to talk to a host in China would require an 
update to parse new DNS double-A (realm, address) records to encapsulate the 
packet IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that 
serves the shaft at level 1 attracts 240.0.0.0/8 within realm 1 and routes up 
the elevator for more specific (host) routes within that prefix. The router 
that serves the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon 
the said packet it would swap the inner and outer destination and the packet 
would reach the Chinese address with classical routing within realm 2. 

Routers serving the shaft need an update, but then, only those do. Obviously 
the host in China can only reply if its stack is updated to understand the 
format. But all the other hosts and routers in China can be classical IPv4 as 
we know them long as their traffic stays in China. To migrate to IPv6 what you 
can do is map the elevator shaft prefix in, say, 400::/3 (sadly cannot use 
F00/3 that would map 240 neatly but is already assigned). 

The current internet would own 400:1::/32, China would own 400:2::/32, etc... 
You encode the double-A of the host in the prefix, reserve a well known suffix 
for IPv4 mapped double-A, and you have an IPv6 address that can be mapped both 
ways statelessly. When migrating to v6, each IPv4 node that owns a public IPv4 
address in one realm gets a full IPv6 /64 for free.
"

Now what?

Pascal


> -Original Message-
> From: NANOG  On Behalf Of Mark
> Delany
> Sent: jeudi 24 mars 2022 12:45
> To: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> On 24Mar22, Pascal Thubert (pthubert) allegedly wrote:
> > Hello Mark:
> >
> > > Any such "transition plan" whether "working" or "straightforward" is
> > > logically impossible. Why anyone thinks such a mythical plan might
> > > yet be formulated some 20+ years after deploying any of ipv6, ipv4++
> > > or ipv6-lite is absurd.
> >
> > This is dishonest
> 
> My point is that if there was a real transition plan it would have been
> invented and executed by now and we'd all be on ipv6. Yet the reality is that
> here we are some 20 years later with no plan and no ubiquitous ipv6. How is
> that observation dishonest?
> 
> > considering that I just proved on this very thread that such ideas
> > existed
> 
> I don't know why you're conflating an idea with a plan - they are about as
> far away from each other as is possible. Frankly no one cares about ideas,
> they're a dime a dozen.
> 
> A plan is an actionable, compelling and logical set of steps towards an end
> result. Do you have such a thing for moving everyone on the planet to ipv6?
> 
> Here's a simple test of whether you have a plan or not. I'm connected via my
> legacy ipv4 ISP router completely oblivous to ipv6. How does your plan
> incentivise me to upgrade my router to support ipv6?
> 
> When you have an answer to that, you might have a glimmer of a plan.
> 
> 
> Mark.

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Hello Mark:

> Any such "transition plan" whether "working" or "straightforward" is
> logically impossible. Why anyone thinks such a mythical plan might yet be
> formulated some 20+ years after deploying any of ipv6, ipv4++ or ipv6-lite is
> absurd.

This is dishonest, considering that I just proved on this very thread that such 
ideas existed and were published. Unless you prove me that the method I pointed 
at does not work. It was published exactly 20+ years ago. It does both the 
tricks of maintaining the IPv4 Internet as is and stateless IPversion 
translation for smooth transition. 

I've seen multiple other variations of using IP in IP at the time; none of 
these ideas emerged, proving more of a lack of desire than a lack of existence. 

> 
> The logic goes: we support legacy "do nothing" ipv4 deployments forever. We
> also expect those same deployments to invest significant effort, cost and
> risk to move off their perfectly functioning network for no self-serving
> benefit.
> 
> There be unicorns and denial of human nature.

There is tussle in the real world, as so well explained in a David Clark's 
paper already linked in this thread. The technology evolution tussle could be 
the next section in the paper. Those who desire it, like Africa for lack IP 
addresses or like Operational Technology for lack of capabilities, vs. those 
who face a cost and no benefit, IOW, as you say, human nature, with those in 
need vs. those in a comfort zone. Like the paper says, the tussles in the 
internet reflect the real world. 

I see that tussle, rather than the tech or the claimed lack thereof, as a major 
reason for the stagnation, rather than the lack of capabilities to adapt the 
technologies, be it v4 or v6. But putting that blame on the technology lacks 
honesty. 

Another example: SLAAC (to Eduard's point today on this same thread). I agree 
that SLAAC is an unfortunate design with the eyes of 2020. But Address Auto 
Configuration was redesigned 10+ years ago to enable a deterministic knowledge 
by the network and provide equivalent to better control than DHCP. This would 
serve the needs that I have seen on this list. My view is that, if there was a 
desire to deploy any of that it would be done. 

Keep safe;

Pascal

RE: V6 still not supported Re: 202203231017.AYC

[Pascal Thubert (pthubert) via NANOG]

s for experimenting new protocols.

I.There probably are a few more parallelisms that we can identify, as 
we discuss more.

I look forward to your thoughts and critiques.

Regards,


Abe (2022-03-23 11:59 EDT)



On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote:

I see the same thing from the other side, being a S/W developer for switching 
and routing boxes since the early 90's. The PM barrier is a high wall indeed. 
And yet some techs succeed to pass it. What I'm arguing is that we can pass 
that wall if we work together with the same objective.



I've been monitoring this list for a while, very insightful, very happy with 
what I learn in the process. But here I feel compelled to react. I read that 
IPv6 did not succeed in 25 years. But unless I miss something, complaining did 
not succeed either, did it?



My frustration is that indeed (as a dev guy) we have been trying hard to serve 
users our best. We proposed a number of things in the IPv4 evolution direction 
that I see being asked on this list. For larger IPv4 space and smooth 
migration, I'm personally fond of the IP-in-IP variation that filed in 20+ 
years ago as US patent 7,356,031. Basically we reserve a /8, say, since it is 
so popular at this time, 240.0.0./8, and make it the "elevator shaft" between 
IPv4 realms. Say the current IPv4 Internet is realm 1, that Internet would have 
IP address 240.0.0.1/8 in the shaft, and would continue operating as is, 
without a change in hosts and routers for traffic staying inside the current 
Internet. Now say China builds realm 2; that Internet would have IP address 
240.0.0.2/8 in the shaft. A host in the Internet that wants to talk to a host 
in China would require an update to parse new DNS double-A (realm, address) 
records to encapsulate the packet IP-in-IP, outer src= 240.0.0.1 outer 
dest=240.0.0.2. The router that serves the shaft at level 1 attracts 
240.0.0.0/8 within realm 1 and routes up the elevator for more specific (host) 
routes within that prefix. The router that serves the shaft at level 2 attracts 
240.0.0.2/32 inside the shaft; upon the said packet it would swap the inner and 
outer destination and the packet would reach the Chinese address with classical 
routing within realm 2. Routers serving the shaft need an update, but then, 
only those do. Obviously the host in China can only reply if its stack is 
updated to understand the format. But all the other hosts and routers in China 
can be classical IPv4 as we know them long as their traffic stays in China. To 
migrate to IPv6 what you can do is map the elevator shaft prefix in, say, 
400::/3 (sadly cannot use F00/3 that would map 240 neatly but is already 
assigned). The current internet would own 400:1::/32, China would own 
400:2::/32, etc... You encode the double-A of the host in the prefix, reserve a 
well known suffix for IPv4 mapped double-A, and you have an IPv6 address that 
can be mapped both ways statelessly. When migrating to v6, each IPv4 node that 
owns a public IPv4 address in one realm gets a full IPv6 /64 for free.



This kind of ideas have existed for long but apparently did not meet their 
public.



So we tried evolving IPv6 instead. And we did. I've witnessed deep evolution in 
networking technology with, e.g., IoT and SRv6. I've seen both being despised 
on this list and I'm not asking for more fuel on that fire. I just want to use 
these techs as a proof that evolution is indeed possible, that it happens in 
the context of IPv6, and that done in your direction it could make some folks 
happier than the current state of affairs. On the side, since I see the name, 
please consider that Cisco ships both techs above, so it is indeed capable of 
risk taking, the PM wall can indeed be passed, as long as there's enough 
pressure from both side.



For those interested, I'd be happy to chat on how IPv6 ND has evolved (on 
paper) but is stuck behind the PM wall as well.



Keep safe;



Pascal



Message-

From: NANOG 
<mailto:nanog-bounces+pthubert=cisco@nanog.org>
 On Behalf Of

Michael Thomas

Sent: mardi 22 mars 2022 22:37

To: nanog@nanog.org<mailto:nanog@nanog.org>

Subject: Re: V6 still not supported





On 3/22/22 5:45 AM, Randy Bush wrote:

john,



fwiw your story matches what is left of my memory.  one nuance



That’s not to say that there wasn’t "IETF politics” involved, but

rather that such politics were expressed as enormous pressure to

“make a decision”

my take was that cidr had done a lot to relieve the immediate

technical pressure for the short term; but there was a deep fear that

the industry press was stirring a major poolpah about the end of the

internet due to

ipv4 exhaustion.  i.e. a seriously flawed technical compromise was

pushed on us in reaction to a perception of bad press.



i have learned that, when i am under great pressure to DO SOMETHING,

it's time to step back, go make a cup of tea, and think.  the ietf did

not.  a

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

I see the same thing from the other side, being a S/W developer for switching 
and routing boxes since the early 90's. The PM barrier is a high wall indeed. 
And yet some techs succeed to pass it. What I'm arguing is that we can pass 
that wall if we work together with the same objective. 

I've been monitoring this list for a while, very insightful, very happy with 
what I learn in the process. But here I feel compelled to react. I read that 
IPv6 did not succeed in 25 years. But unless I miss something, complaining did 
not succeed either, did it?

My frustration is that indeed (as a dev guy) we have been trying hard to serve 
users our best. We proposed a number of things in the IPv4 evolution direction 
that I see being asked on this list. For larger IPv4 space and smooth 
migration, I'm personally fond of the IP-in-IP variation that filed in 20+ 
years ago as US patent 7,356,031. Basically we reserve a /8, say, since it is 
so popular at this time, 240.0.0./8, and make it the "elevator shaft" between 
IPv4 realms. Say the current IPv4 Internet is realm 1, that Internet would have 
IP address 240.0.0.1/8 in the shaft, and would continue operating as is, 
without a change in hosts and routers for traffic staying inside the current 
Internet. Now say China builds realm 2; that Internet would have IP address 
240.0.0.2/8 in the shaft. A host in the Internet that wants to talk to a host 
in China would require an update to parse new DNS double-A (realm, address) 
records to encapsulate the packet IP-in-IP, outer src= 240.0.0.1 outer 
dest=240.0.0.2. The router that serves the shaft at level 1 attracts 
240.0.0.0/8 within realm 1 and routes up the elevator for more specific (host) 
routes within that prefix. The router that serves the shaft at level 2 attracts 
240.0.0.2/32 inside the shaft; upon the said packet it would swap the inner and 
outer destination and the packet would reach the Chinese address with classical 
routing within realm 2. Routers serving the shaft need an update, but then, 
only those do. Obviously the host in China can only reply if its stack is 
updated to understand the format. But all the other hosts and routers in China 
can be classical IPv4 as we know them long as their traffic stays in China. To 
migrate to IPv6 what you can do is map the elevator shaft prefix in, say, 
400::/3 (sadly cannot use F00/3 that would map 240 neatly but is already 
assigned). The current internet would own 400:1::/32, China would own 
400:2::/32, etc... You encode the double-A of the host in the prefix, reserve a 
well known suffix for IPv4 mapped double-A, and you have an IPv6 address that 
can be mapped both ways statelessly. When migrating to v6, each IPv4 node that 
owns a public IPv4 address in one realm gets a full IPv6 /64 for free.

This kind of ideas have existed for long but apparently did not meet their 
public. 

So we tried evolving IPv6 instead. And we did. I've witnessed deep evolution in 
networking technology with, e.g., IoT and SRv6. I've seen both being despised 
on this list and I'm not asking for more fuel on that fire. I just want to use 
these techs as a proof that evolution is indeed possible, that it happens in 
the context of IPv6, and that done in your direction it could make some folks 
happier than the current state of affairs. On the side, since I see the name, 
please consider that Cisco ships both techs above, so it is indeed capable of 
risk taking, the PM wall can indeed be passed, as long as there's enough 
pressure from both side.

For those interested, I'd be happy to chat on how IPv6 ND has evolved (on 
paper) but is stuck behind the PM wall as well.

Keep safe;

Pascal

Message-
> From: NANOG  On Behalf Of
> Michael Thomas
> Sent: mardi 22 mars 2022 22:37
> To: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> 
> On 3/22/22 5:45 AM, Randy Bush wrote:
> > john,
> >
> > fwiw your story matches what is left of my memory.  one nuance
> >
> >> That’s not to say that there wasn’t "IETF politics” involved, but
> >> rather that such politics were expressed as enormous pressure to
> >> “make a decision”
> > my take was that cidr had done a lot to relieve the immediate
> > technical pressure for the short term; but there was a deep fear that
> > the industry press was stirring a major poolpah about the end of the
> > internet due to
> > ipv4 exhaustion.  i.e. a seriously flawed technical compromise was
> > pushed on us in reaction to a perception of bad press.
> >
> > i have learned that, when i am under great pressure to DO SOMETHING,
> > it's time to step back, go make a cup of tea, and think.  the ietf did
> > not.  and here we are, a quarter of a century later, still trying to
> > clean up the mess.
> >
> So are you saying that an ipng that came out in, say, 2000 which was
> according to you was vastly superior having taken the time to get it
> right would have had any better chance of being adopted? My experience
> with Cisco product managers at the 

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Complaining is fun and healthy.

But I was unclear, not asking about v4 vs. v6, but about caring for / 
contributing to evolution of network protocols, or not. 

Some evolution has happened in the IPv6 world, more could happen, so it gets 
better. Or throw the baby?

Keep safe;

Pascal
> -Original Message-
> From: Randy Bush 
> Sent: mardi 22 mars 2022 16:38
> To: Pascal Thubert (pthubert) 
> Cc: North American Network Operators' Group 
> Subject: Re: V6 still not supported
> 
> > Which side are you on?
> 
> hint: this is an operators' list.  we are forced to be on all 'sides'.
> this pain gives us the privilege of whining a lot.
> 
> randy

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Hi:

IPv4 is 40 years  old. IPv6 is 25 years old. In Internet time, both are old 
timers. 

Since then, networks have evolved dramatically, with new physical media like 
wireless that hates broadcasts, and new logical constructs like overlays in 
cloud and SD WAN which require new IP abstractions and more control.

Question is whether we keep complaining for the next 25 years that choices made 
25 years ago were inadequate, or work on evolving stuff to meet needs. 

There are groups at the IETF that standardized IPv6 evolutions for those 
networks. We now have means to decouple the IP abstractions of Link and Subnet 
from the underlaying L2/L1 constructs and provide a deterministic state about 
the end points to the network. The equivalent for IPv4 did not really happen.

The rest of the world will follow the evolution because there's not enough IPv4 
for Africa or Asia anyway. I see the analogy with the industrial revolution, 
England stuck to coal and steam when the world that had nothing moved on.

Which side are you on?

Pascal

> -Original Message-
> From: NANOG  On Behalf Of
> Daniel Karrenberg
> Sent: mardi 22 mars 2022 16:02
> To: Randy Bush 
> Cc: nanog@nanog.org
> Subject: V6 still not supported
> 
> Full match with my recollection about the cause for this sub optimal
> outcome. Happens to the best of us.
> 
> One has to remember that at the time we did not consider it a forgone
> conclusion that the products of the IETF woukd be the foundation of the
> Net.
> 
> Daniel (age 63, memory not totally unreliable yet)
> 
> ---
> Sent from a handheld device.
> 
> > On 22. Mar 2022, at 13:46, Randy Bush  wrote:
> >
> > john,
> >
> > fwiw your story matches what is left of my memory.  one nuance
> >
> >> That’s not to say that there wasn’t "IETF politics” involved, but
> >> rather that such politics were expressed as enormous pressure to
> >> “make a decision”
> >
> > my take was that cidr had done a lot to relieve the immediate
> > technical pressure for the short term; but there was a deep fear that
> > the industry press was stirring a major poolpah about the end of the
> > internet due to
> > ipv4 exhaustion.  i.e. a seriously flawed technical compromise was
> > pushed on us in reaction to a perception of bad press.
> >
> > i have learned that, when i am under great pressure to DO SOMETHING,
> > it's time to step back, go make a cup of tea, and think.  the ietf did
> > not.  and here we are, a quarter of a century later, still trying to
> > clean up the mess.
> >
> > randy

RE: V6 still not supported

[Pascal Thubert (pthubert) via NANOG]

Hello Saku:
 
> > This is intended to replace ARP, ICMP Router Advertisement, ICMP
> > Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the
> [IPv6]
> > environment. There are also elements of the OSI ES-IS and IS-IS
> Hello.
> >
> > We were forward looking to deployments of thousands of systems per
> > link, rather than the 30 maximum under then current ethernet
> > standards.  We needed fewer announcements, less chatty traffic, and
> more specific traffic designation.
> 
> Please bear with me, after negativity some sobering remarks follow.
> 
> And the solution is broken, it assumes snooping packets and creating
> near arbitrary amounts of multicast groups and forwarding multicast on
> L2 device is cheaper than flooding. It is not, and everyone keeps MLD
> off in L2 to simplify and reduce cost.
> So in reality the multicast L2 resolution is not used, and useless
> complexity. 

True. The issue is not with "IPv6" but specifically with SLAAC. As long one 
uses DHCP, IPv4 and v6 have similar properties WRT to BUM.

Now, hosts having multiple addresses and renewing them when they wish could be 
a real bonus, if it was not done the Woodstock way; IOW if there was a minimum 
control from the network operator. *The hassle in SLAAC is the SL*.

This is why the IETF introduced RFC 8505 / 8928. This combines the stateful 
behavior of DHCP and the benefits of autoconfiguration. No more multicast DAD 
or address lookup. No IGMP.


> In addition to this problem of changing broadcast to
> multicast, the ND can use GUA|LL<->GUA|LL any combination, which makes
> almost every input ACL broken, because operators simply are not aware of
> this. Very common problem for us is, we change vendor on our end, and
> customer IPv6 breaks, customer did 0 changes, so of course they blame
> us, and we have difficult task to educate them 'look this is how ND
> works, your ACL is broken, because it assumes special case is generic
> case, and the special case has changed' because different vendors choose
> different GUA|LL <-> GUA|LL for ND, it can be wrong and work until the
> far end does some change. The right solution is not to filter by ADDR,
> but to filter by hop-limit, but it's too complex for operators to
> understand.
> 

True. The "on-link" model is a very bad fit for any managed network. Don't use 
it outside home . Probably turn off redirect when you do that, too.

> /MOST/ IPv6 'improvements' are like this, they solve problems that
> either didn't exist or make the existing problem worse. Like extension
> headers. Like creating large on-link networks, adding a lot more attack
> vectors.

True too. The RFC 8505 / 8928 combo creates P2P IP link abstractions regardless 
of the L2 broadcast domain / L2 segments. This is how you can avoid BUM and set 
up a deterministic state for wireless (proxy ARP) and overlays (LISP, EVPN...) 
services. IOW the prefixes are always "not onlink".
 

> Ok IPv6 is kinda shit, but it's the only thing we have and we can make
> it work with some effort and some cost. And the effort and cost of
> making IPv6 work is less than making IPV4+IPV6 work, and we really
> really need the larger address space, it trumps all other deltas by a
> wide margin. So yes I have an ugly child, but it's the only child I
> have, and with my genes, a beautiful child isn't on the cards, so I'll
> raise this ugly child as best I can.
> I no longer care how bad IPv6 is, that's crying over spilt milk, it
> doesn't matter. I care about the cost of doing both IPV4+IPV6.
> 

The child has grown up, at least on paper. But very little of IETF efforts in 
the last 15 years has made it to products. Apart of SRv6 and IoT, which is 
where RFC 8505 started. 

I assume that user feedback is needed for vendors to implement, and users are 
not necessarily aware of the specs that were developed, so many of them. 

Would you care to extract RFC 8505 / 8928 from the background noise?

Keep safe;

Pascal

Re: EVPN P2MP Implementation

[Pascal Thubert (pthubert) via NANOG]

Hello Joel

Far from widely available but:

- we updated IPv6 ND for P2MP with RFC8505
- address ownership can be protected with RFC 8928
- early work is available for eVPN with 
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00

All this is IPv6 only and not shipping yet. The rest is a matter of ask…

Regards,

Pascal

Le 14 juil. 2021 à 14:44, aj  a écrit :


Hi All,

Could anyone please share any ideas on how P2MP can be achieved using EVPN ?
--
Many Thanks,
Joel...

how many bits of entropy do we need for load balancing?

[Pascal Thubert (pthubert) via NANOG]

Dear all:

How many bits of entropy do we need for (ECMP) load balancing in the core?
This question has kept coming up regularly in many discussions and drafts at 
the IETF.

The IPv6 flow label is 20 bits but hardware implementations do their balancing 
only on a subset of that, e.g. 12 or 16 bits.

There are drafts for MPLS, BIER etc.. that provide their own entropy bit fields 
of various sizes.
I traced to a 6MAN discussion at IETF 78 a claim that 10 or 11 bits were enough.

Did someone do the actual exercise? It would be neat to align the IETF specs in 
the making to whatever truth may be established in the core.

Keep safe,

Pascal

Re: understanding IPv6

[Pascal Thubert (pthubert) via NANOG]

Hello Baldur;

There’s the hack that can be helpful and then there’s the proper solution.

As for hacks, indeed snooping can help a lot. As it goes we went for ND and 
DHCP snooping rather than MLD and there are many reasons for that, reliability, 
Desire to know the address not just the snma group, how easily is to query from 
a L2 device such as an AP or a switch etc... you may look for IETF SAVI docs to 
see how that is done.

But then there are cases where the hack falls short. Snooping on wireless may 
miss packets, a silent node (e.g., wake on lan) may not show. The snooped  
state is mostly ok but not as good as a state that is installed And maintained 
by a protocol that is meant for it, including support for mobility and lifetime.

Not so surprising after all is it?

Pascal

Le 7 juin 2020 à 21:34, Baldur Norddahl  a écrit :


What I do not understand about this proposal is why we do not just fix wireless 
multicast? For example the AP could unicast multicast frames to subscribed STA 
and combined with MLD snooping we are done. Would be backwards compatible too, 
compared to a whole new protocol which will take decades to gain traction.

Regards,

Baldur


On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern 
mailto:j...@joelhalpern.com>> wrote:
Just to clarify context, at this stage this is just Pascal's interesting
idea for how to make ND work better on wireless.  No IETF working group
has adopted this.  Various people seem to be interested, but it will be
some time before we know if his approach gets traction.

The biggest difference between this and earlier changes along this line
is that the wireless broadcast problem provides motivation for the
change, where earlier efforts were more ~wouldn't it just be simpler if...~

Yours,
Joel Halpern

On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:
> What I'm amazed at is the concept of multi-link subnet and the change in
> IP model being proposed.
>
> See, for example, section 4 of
> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05
>
> Has anyone felt the same about the change being proposed? This swept
> away 25 years of thinking about IP subnets and IP links for me.
>
> Etienne
>
> On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin 
> mailto:lists.na...@monmotha.net>
> >> wrote:
>
> On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:
>  > There are very interesting and unobvious moments on IPv4 vs IPv6,
> for
>  > example related to battery lifetime in embedded electronics. In
> ipv4,
>  > many devices are forced to send "keepalives" so that the NAT
> entry does
>  > not disappear, with IPv6 it is not required and bidirectional
>  > communications possible at any time. And in fact, it has a huge
> impact
>  > on the cost and battery life of IoT devices.
>  > When I developed some IoT devices for clients, it turned out that if
>  > "IPv6-only" is possible, this significantly reduces the cost of the
>  > solution and simplify setup.
>
> This is difficult to understate.  "People" are continually amazed
> when I
> show them that I can leave TCP sessions up for days at a time (with
> properly configured endpoints) with absolutely zero keepalive traffic
> being exchanged.
>
> As amusingly useful as this may be, it pales in comparison to the
> ability to do the same on deeply embedded devices running off small
> primary cell batteries.  I've got an industrial sensor network product
> where the device poll interval is upwards of 10 minutes, and even then
> it only turns on its receiver.  The transmitter only gets lit up about
> once a day for a "yes I'm still here" notification unless it has
> something else to say.
>
> In the end, we made it work across IPv4 by inserting an application
> level gateway.  We just couldn't get reliable, transparent IPv6
> full-prefix connectivity from any of the cellular telematics providers
> at the time.  I don't know if this has changed.  For our application,
> this was fine, but for mixed vendor "IoT" devices, it would probably
> not
> work out well.
> --
> Brandon Martin
>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: understanding IPv6

[Pascal Thubert (pthubert) via NANOG]

Hello Joel:

The draft is supposed to be factual not divagations; if I went too far 
somewhere I need to fix the draft. As you said it is early personal submission.

Multi links subnets are not a figment of my mind. We have millions of routers 
deployed that way, using RPL as the subnet routing protocol. Admittedly this is 
IoT but this is true nevertheless.

Keep safe,

Pascal

> Le 7 juin 2020 à 21:00, Joel Halpern  a écrit :
> 
> Just to clarify context, at this stage this is just Pascal's interesting 
> idea for how to make ND work better on wireless.  No IETF working group has 
> adopted this.  Various people seem to be interested, but it will be some time 
> before we know if his approach gets traction.
> 
> The biggest difference between this and earlier changes along this line is 
> that the wireless broadcast problem provides motivation for the change, where 
> earlier efforts were more ~wouldn't it just be simpler if...~
> 
> Yours,
> Joel Halpern
> 
>> On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:
>> What I'm amazed at is the concept of multi-link subnet and the change in IP 
>> model being proposed.
>> See, for example, section 4 of 
>> https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05
>> Has anyone felt the same about the change being proposed? This swept away 25 
>> years of thinking about IP subnets and IP links for me.
>> Etienne
>> On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin > > wrote:
>>On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:
>> > There are very interesting and unobvious moments on IPv4 vs IPv6,
>>for
>> > example related to battery lifetime in embedded electronics. In
>>ipv4,
>> > many devices are forced to send "keepalives" so that the NAT
>>entry does
>> > not disappear, with IPv6 it is not required and bidirectional
>> > communications possible at any time. And in fact, it has a huge
>>impact
>> > on the cost and battery life of IoT devices.
>> > When I developed some IoT devices for clients, it turned out that if
>> > "IPv6-only" is possible, this significantly reduces the cost of the
>> > solution and simplify setup.
>>This is difficult to understate.  "People" are continually amazed
>>when I
>>show them that I can leave TCP sessions up for days at a time (with
>>properly configured endpoints) with absolutely zero keepalive traffic
>>being exchanged.
>>As amusingly useful as this may be, it pales in comparison to the
>>ability to do the same on deeply embedded devices running off small
>>primary cell batteries.  I've got an industrial sensor network product
>>where the device poll interval is upwards of 10 minutes, and even then
>>it only turns on its receiver.  The transmitter only gets lit up about
>>once a day for a "yes I'm still here" notification unless it has
>>something else to say.
>>In the end, we made it work across IPv4 by inserting an application
>>level gateway.  We just couldn't get reliable, transparent IPv6
>>full-prefix connectivity from any of the cellular telematics providers
>>at the time.  I don't know if this has changed.  For our application,
>>this was fine, but for mixed vendor "IoT" devices, it would probably
>>not
>>work out well.
>>-- Brandon Martin
>> -- 
>> Ing. Etienne-Victor Depasquale
>> Assistant Lecturer
>> Department of Communications & Computer Engineering
>> Faculty of Information & Communication Technology
>> University of Malta
>> Web. https://www.um.edu.mt/profile/etiennedepasquale
> 

FW: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)

[Pascal Thubert (pthubert) via NANOG]

I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref 
to RFC 5942 in section 4.4 that discusses the use of on-link flag.

Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT 
network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP 
models. It takes quite a bit more than resetting the on-link flag to enable 
IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I 
tried to express too concisely.

Keep safe,
Pascal

PS For NBMA, RFC 4861 clearly says

 non-broadcast multiple access (NBMA)
- Redirect, Neighbor Unreachability Detection and
  next-hop determination should be implemented as
  described in this document.  Address resolution,
  and the mechanism for delivering Router
  Solicitations and Advertisements on NBMA links are
  not specified in this document.  Note that if
  hosts support manual configuration of a list of
  default routers, hosts can dynamically acquire the
  link-layer addresses for their neighbors from
  Redirect messages.


From: Wes Beebee (wbeebee) 
mailto:wbeebee=40cisco@dmarc.ietf.org>>
Sent: lundi 1 juin 2020 16:00
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Etienne-Victor Depasquale mailto:ed...@ieee.org>>
Cc: NANOG mailto:nanog@nanog.org>>; 
i...@ietf.org
Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)

RFC 5942 outlines how NBMA works with Neighbor Discovery.

Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 
million+ subscribers without any problems.


  *   Wes

From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of 
"Pascal Thubert (pthubert)" 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Date: Sunday, May 31, 2020 at 8:29 AM
To: Etienne-Victor Depasquale mailto:ed...@ieee.org>>
Cc: NANOG mailto:nanog@nanog.org>>, 
"i...@ietf.org" mailto:i...@ietf.org>>
Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)

Cool, that’s the whole point.

With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t 
be MLSN.

We have changed that in IoT and we are now trying  to generalize to all types 
of links.
There’s a tentative to get the aforementioned draft adopted at 6MAN. If you 
found it useful please voice support !

Take care,

Pascal

Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale 
mailto:ed...@ieee.org>> a écrit :
Pascal, thank you, the draft at  
https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/  is 
very informative.

You hit the nail on the head with your suggestion of confusion between the 
congruence of link and subnet.

However, I followed one of the references (RFC4903) in your draft and
it does not help that it (RFC4903) points to RFC4291's assertion that:
"Currently IPv6 continues the IPv4 model that a subnet prefix is associated 
with one link"

RFC4903 further states that:
 "clearly, the notion of a multi-link subnet would be a change to the existing 
IP model.".

I confess: your assertion in the draft that:
"In Route-Over Multi-link subnets (MLSN) [RFC4903],
routers federate the links between nodes
that belong to the subnet, the subnet is not on-link and it extends
beyond any of the federated links"

is news to me.

Best regards,

Etienne





On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Hello Etienne Victor

Maybe you’re confusing link and a subnet?

This is discussed at length here:
https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/

RPL can route inside a subnet using host routes. This is how a multi link 
subnet can be made to work...

Please let me know if the draft above helped and whether it is clear enough. 
The best way for that discussion would be to cc 6MAN.

Keep safe,

Pascal

Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale 
mailto:ed...@ieee.org>> a écrit :
Thank you Carsten, and thank you Pacal. Your replies are valuable and packed 
with insight.

I'll wrap up with how I interpret RPL's behaviour in terms of IP hops.

On one hand, RFC6775 defines a route-over topology as follows:
"A topology where hosts are connected to the 6LBR through the use of 
intermediate layer-3 (IP) routing.
Here, hosts are typically multiple IP hops away from a 6LBR.
The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts."
If RPL is route-over by definition, then RFC6775 would imply that there are 
typically multiple IP hops between a leaf and the border router.

On the other hand, there at least two contradictions (which I justify after 
stating them):
(a) RFC6550 states that "RPL also introduces the capability to bind a subnet 
together with a common prefix and to route within that subnet."
(b)