Re: Let's Focus on Moving Forward Re: V6 still not supported

[Owen DeLong via NANOG]

> On Mar 26, 2022, at 06:35 , Abraham Y. Chen  wrote:
> 
> Hi, Owen:
> 
> 0)Re: Ur. Pt. 2):This topic is such a tongue-twister. Let's put it 
> aside for now, until I can properly convey the EzIP concept and scheme to you.
> 
> 00)Re: Ur. Pt. 4):Okay, I was concerned about how to decipher this 
> cryptic exchange. So let's put it aside as well.
> 
> 1)Re: Ur. Pt. 1):Yes, you are correct that the EzIP network 
> architecture looks like that of CG-NAT. In fact, it is exactly the same. This 
> is actually the beauty of the EzIP solution. That is, without touching the 
> hardware, by implementing the EzIP technique (disabling the program code that 
> has been disabling the use of the 240/4 netblock), an existing CG-NAT module 
> becomes a RAN! As to universal peer-to-peer, where is any of such today? On 
> the other hand, upon fully implemented the EzIP proposal (the second phase: 
> making use of the Option Word in RFC791), an IoT in one RAN can directly 
> reach a second IoT in another RAN world-wide. So that the original promise of 
> the Internet will be finally fulfilled and for the long haul.

The fact that we gave up universal peer to peer in the name of survival until 
we could deploy a protocol with enough addresses doesn’t mean that giving it up 
is a good long term solution.

To me, the goal is to get away from address scarcity as quickly as possible. 
IPv6 does that. EzIP doesn’t. I have no desire to support prolonging the misery 
that has existed since NAT became popular. I view it as a disability to the 
internet and IPv6 eliminates that disability. EzIP arguably makes it even 
worse. So, what you call beauty is, IMHO, damage.

> 2)Re: Ur. Pt. 3):Similarly, you probably only recognized the part 
> that EzIP proposes to classify the 240/4 netblock as the fourth private 
> address in RFC1918, but overlooked that such capacity will enable a RAN to 
> cover a geographic area as big as Tokyo Metro, or 75% of smaller countries 
> around the world, even before utilizing the conventional three private 
> netblocks. This puts 240/4 into a different league from the other three 
> conventional private netblocks, although all four have basically the same 
> technical characteristics. Now, visualizing each RAN is tethered from the 
> existing Internet core by one umbilical cord (one IPv4 address), it appears 
> like a private network. So that each RAN can provide Internet services by 
> utilizing existing technologies, while avoiding those undesired. Combining 
> these RANs around the world, an overlay layer of routers (SPRs) can operate 
> in parallel to the current Internet. Under such a configuration, the latter 
> no long is involved with daily local activities, but only carries inter-RAN 
> traffic, very much like the division between national and international 
> telephone networks. This creates quite a different operation landscape. 
> Please have a look at slide # 11 of the below whitepaper for a rough 
> breakdown of the available addresses under the EzIP scheme. Furthermore, if 
> used diligently, (treating IP address as "natural resources" instead of 
> "personal properties"), the assignable "EzIP addresses" can last quite awhile.

I didn’t overlook it, I routed around it as damage in the truest of internet 
traditions. Geographical-based addressing hierarchies have been proposed 
before. They have a long history of failing in the face of actual topology and 
actual operational concerns. This doesn’t look significantly different to me. 
It’s yet another entirely bad idea which serves only to prolong the IPv4 misery 
while diverting resources from useful work to enable the deprecation of IPv4 as 
the lingua franca of the internet backbone.

> 
> https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf 
>   
> 
> 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
> baseline that we need to sort out, first. That is, we must keep in mind that 
> the Internet community strongly promotes "personal freedom". Assuming that by 
> stopping others from working on IPv4 will shift their energy to IPv6 is 
> totally contradicting such a principle. A project attracts contributors by 
> its own merits, not by relying on artificial barriers to the competitions. 
> Based on my best understanding, IPv6 failed right after the decision of "not 
> emphasizing the backward compatibility with IPv4". It broke one of the golden 
> rules in the system engineering discipline. After nearly three decades, still 
> evading such fact, but defusing IPv6 issues by various tactics is the real 
> impedance to progress, not only to IPv4 but also to IPv6.

I’m not stopping anyone from anything. I’m stating that I believe resources 
would be better spent deploying IPv6 than being wasted on this project. Anyone 
who disagrees with me is, of course, free to waste their resources however they 
see fit.

In 

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

[Ryland Kremeier]

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



Hmm.



-Original Message-
From: NANOG  On Behalf Of 
Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg ; nanog@nanog.org; 'jordi.palet' 
(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'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 
> mailto:nanog-bounces+pthubert=cisco@nanog.org>>
>  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 

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 no

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

[Joe Maimon]

Philip Homburg wrote:
It should be clear that an IPv4-only host only speaks IPv4. This means 
that communication with an IPv4-only host has to be IPv4.


This did not have to be true, had there been an extension/option 
standardized at the same time as IPv6 for IPv4 packets to be gateway'd 
into IPv6 transparently and efficiently (thru any dual stacked 
host/router), than at this point we would have likely been looking at 4 
classes of nodes


- IPv4 only, legacy, requires translation to communicate directly with ipv6

- IPv4 only, extended, just needs a gateway to communicate directly with 
IPv6


- Dual Stack

- IPv6 only

Such additional functionality, could have been organically updated into 
most major OS's without any required network topology changes.


Joe

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Masataka Ohta]

Joshua Mallad wrote:


I am growing extremely frustrated by the lack of available internet address
space.


Then, let's have NAT with 32bit port numbers.


How many times are you going to extend and hack away at IPv4,


Perhaps, only once, which means NAT.

Anyway, it is a lot less than hacks to try to have IPv6 with IPv4.

Masataka Ohta

Re: V6 still not supported

[Masataka Ohta]

Philip Homburg wrote:


Any form of communication with the current IPv4 internet requires some
sort of CGNAT.


Any form of communication with the current IPv4/IPv6 mixed internet,
except for dual stack, also requires some sort of NAT.


Technically, A+P (address
plus port) mapping is a bit different, but for the customer that doesn't
make a lot of difference.


A+P is equivalent to end to end NAT, though end to end NAT
only needs plain IP routers behind gateways, whereas A+P
requires routers with A+P routing capability for large
(but not very large) number of hosts. As networks behind
the gateways are local and not so large, it can not be a
practical problem.


And A+P has serious scalability problems.


No, not at all.

Masataka Ohta

Re: IPv6 "bloat" history

[Masataka Ohta]

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: A straightforward transition plan (was: Re: V6 still not supported)

[Ca By]

On Mon, Mar 28, 2022 at 6:22 AM Philip Homburg 
wrote:

> >If by ?straightforward transition plan? one means a clear and rational
> set of
> >options that allows networks to plan their own migration from IPv4-only
> to IPv
> >6, while maintaining connectivity to IPv4-only hosts and with a level of
> effor
> >t reasonable comparable to just running IPv4, then I would disagree, as
> such a
> >n "IPng transition plan? was achievable, expected, and we collectively
> failed
> >to deliver on it (as noted below)
>
> I'm a bit confused about the achievable part.
>
> Obviously, the adoption of IPv6 without a clear transition plan was a
> process
> failure. However, it is not clear to me that waiting a few years would
> have brought something much better. And waiting more than a decade would
> mean that today there would not be a mature IPv6.
>
> Transition to IPv6 so far seems to have consisted of 3 phases:
> 1) Lots of tunnels due lack of a wide spread IPv6 backbone.
> 2) Early adopters being happy that they can run IPv6 native, usually as
>dual stack.
> 3) Lots of people looking into IPv6-only.
>
> I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
> worked. Obviously, deploying IPv6 using tunnels is a lot more complex
> than deploying native IPv4 without NAT.
> From a technical perspective 2) just works. From an operational perspective
> it is about twice as expensive as IPv4-only. So 2) is popular with people
> who really want IPv6.
>
> The big issue is 3). If we look at the current internet, there are parties
> who lack IPv4 addresses and want to switch to IPv6. Obviously, they
> want to be IPv6-only. The lack of IPv4 address makes dual stack even
> harder.
> On the other hand, there are parties who have enough IPv4 addresses and
> have no reason to switch to IPv6.
>
> So we are clearly in the situation of 'migration from IPv4-only to IPv6,
> while maintaining connectivity to IPv4-only hosts'
>
> It should be clear that an IPv4-only host only speaks IPv4. This means that
> communication with an IPv4-only host has to be IPv4. So either the
> IPv6-only host or something in the network has to speak IPv4. If the
> IPv6 host speaks IPv4 then we get dual stack, which has been rejected
> as a broken solution. Technically, it is also possible to tunnel IPv4
> packets, then the host is in some sense dual stack, but most of the network
> is not. However, automatic tunnel configuration is hard, and tunnels
> tend to be fragile.
>
> So the only option is a device in the network that translates between
> IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
> a technical point of view it is a disaster.




I think what you mean to say is you don’t like NAT64.

You may also be trying to say you disapprove of how history unfolded.

Fair.

But it may be worth acknowledge that some small and some very large (100M
mobiles, growing FWA broadband business) have happily operated NAT64 for
coming on 10 years  with no problems or regrets.

Yes, we would like the internet to be on a single unified and high scale
address family, but we all play the hand we are dealt.



>
> Looking back, we can say that the only feature of IPv6 that makes people
> invest in IPv6 is the bigger address space. So it is safe to say that
> most of the internet would have waited to invest in IPv6 until we were
> (almost) out of IPv4 addresses. So by its very nature this transation
> between IPv6 and IPv4 would have NAT component.
>
> In my opinion, It is clear that during the time IPv6 was developed, any
> solution involving NAT would have been rejected.
>
> So I'm confused, what transition technology was achievable (also in the
> political sense) but not delivered?
>
> If there is a magical transition technology that allows an IPv6-only host
> to
> talk to an IPv4-only host, then let's deploy it.
>

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

[JORDI PALET MARTINEZ via NANOG]

I don't think we can say that NAT64 is a disaster. I will say so if we want to 
keep IPv4 only hosts in the "6" side, of course it doesn't work. However, 
that's why we moved further with 464XLAT. And the demonstration is that most of 
the operators are using it.

I think in your picture you're missing 2 phases:
4) IPv6-only with IPv4aaS (we have 5 technologies, see RFC8585 for a summary of 
what is needed in the CPEs), when there is still a significant amount of IPv4 
traffic in the customer LANs.
5) IPv6-only with IPv4aaS when IPv4 traffic is residual in most of the 
customers LANs. How fast we move to this phase depends on more and more 
devices, and apps using IPv6.

The advantage is:
a) The job is done in the CPE (no need for a more powerful one, etc.), 
customers are not aware of it. Part of the job is done in the operators 
networks, of course, but it is comparable and much cheaper, in terms of OpEx 
and CapEx, to alternatives such as dual-stack or NAT444/CGN.
b) When moving to 5 above, the operators can measure the reduction on the usage 
of the NAT64 (in the case of 464XLAT), and even in the usage of IPv4 public 
addresses, so they can transfer them, so laggers can use them for their own 
transition. On the side of the customers, there is nothing to do. You may 
remove IPv4, but actually is not costing you "anything" to keep it.
 

Regards,
Jordi
@jordipalet
 
 

El 28/3/22, 15:23, "NANOG en nombre de Philip Homburg" 
 escribió:

>If by ?straightforward transition plan? one means a clear and rational set 
of 
>options that allows networks to plan their own migration from IPv4-only to 
IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of 
effor
>t reasonable comparable to just running IPv4, then I would disagree, as 
such a
>n "IPng transition plan? was achievable, expected, and we collectively 
failed 
>to deliver on it (as noted below) 

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a 
process
failure. However, it is not clear to me that waiting a few years would 
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT. 
From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6. 

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation 
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.



**
IPv4 is over
Are you ready for the new Internet ?
http://www.thei

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Joshua Mallad]

I usually keep quiet on this list, but this topic is relevant to me as a
smaller (non-BGP level) network operator who would really love to see more
IPv6 deployment.
I don't have experience deploying internet technologies at the highest
level, so I can't say I fully understand the difficulties surrounding it.
What I can say, however, is that
I am growing extremely frustrated by the lack of available internet address
space.

>From my perspective, IPv6 is the obvious way forward, and honestly, I see a
whole lot of whining any time it is brought up. You guys seem to be so
averse to actually doing your jobs sometimes. Yes, problems may arise when
introducing a new technology. You may have to actually fix some things that
break. The benefit is that we finally get enough address space for everyone
to do what they want with.

How many times are you going to extend and hack away at IPv4, claiming its
easier than just setting up IPv6? It is so silly. Watching this circus is
getting boring. Upgrade your infrastructure. Many devices that can't be
patched to support this "ezip" nonsense don't support IPv6 either, so I see
the "legacy devices" argument as moot either way.

Re: [EXTERNAL] Re: ISP data collection from home routers

[Michael Froomkin - U . Miami School of Law]

On Thu, 24 Mar 2022, Mu wrote:

[...]

While I agree that many consumers don't place much value on their own data,
resulting in them not particularly caring about that data, in my experience it
often stems from ignorance of what can be done with that data (if they even know
that the data is being collected in the first place). Once the implications of
sharing specific data is known, my anecdata has shown that the average person 
will
make some adjustments to their data-sharing habits. At the very least, an 
informed
decision can be made.

However, when it comes to intricate technical data from their home routers being
hoarded, we can't really expect the average consumer to form an informed 
decision
on the data being shared, can we? I don't think the default should be "collect 
as
much as we can because they probably won't care" in the absence of an informed
consumer.

Regards,

Mu

[...]

I discuss the relation between (sometimes unseen) data collection 
valuation and the decision to allow it at pages 1728-1745 (Part II 
sections B-D) of Regulating Mass Surveillance as Privacy Pollution: 
Learning from Environmental Impact Statements, 2015 U. Ill. L. Rev. 1713 
(2015), availabe from https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400736


-Michael

--
A. Michael Froomkin https://law.tm 305-284-4285 ssrn: bit.ly/1XlTJLz
Laurie Silvers & Mitchell Rubenstein Distinguished Professor of Law
Editor, Jotwell: The Journal of Things We Like (Lots),  jotwell.com
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
It's hot here

Re: V6 still not supported

[Philip Homburg]

>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 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.

You mostly ignored the routing problems I brought up. With NAT64 each ISP
is in full control over all routing. Your problem has routing aspects
that are not under control of the ISP. 

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

Extending IPv4 is fine (except for the installed base of IPv6). It is not fine
if the extension leads to problem in other areas, like routing.

There are other problems to consider. For example, IPv6 can be added 
transparently to a network with legacy IPv4-only hosts. Hosts can get a 
public IPv6 address and a RFC 1918 IPv4 address. I wonder how in your
approach such a mix of legacy and new hosts will work out.

>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.

We seem to have a different recall of history. 6to4 was extremely popular.
Popular enough that major content providers did not turn on IPv6 until
host stacks were modified to essentially kill 6to4. (in case we are talking
about different 6to4 protocols. I meant the one that interconnects with the
non-6to4 IPv6 internet. So more than just islands)

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

[Philip Homburg]

> > 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.

Re: MAP-T (was: Re: V6 still not supported)

[Rajiv Asati (rajiva) via NANOG]

FWIW, MAP has been deployed by few operators (in at least 3 continents that I 
am aware of).

Charter communications is one of the public references (see NANOG preso 
https://www.youtube.com/watch?v=ZmfYHCpfr_w).

MAP (CPE function) has been supported in OpenWRT software (as well as many CPE 
vendor implementations) for few years now;
MAP (BR function) has been supported by few vendors including Cisco (in IOS-XE 
and XR).

Cheers,
Rajiv 

https://openwrt.org/packages/pkgdata_owrt18_6/map-t 
https://openwrt.org/docs/guide-user/network/map

 

-Original Message-
From: NANOG  on behalf of Vasilenko 
Eduard via NANOG 
Reply-To: Vasilenko Eduard 
Date: Friday, March 25, 2022 at 11:17 AM
To: Jared Brown , "nanog@nanog.org" 
Subject: RE: MAP-T (was: Re: V6 still not supported)

Hi Jared,
Theoretically, MAP is better. But 

1. Nobody has implemented it for the router.
The code for the CGNAT engine gives the same cost/performance.
No promised advantage from potentially stateless protocol.

2.MAP needs much bigger address space (not everybody has) because:
a) powered-off subscribers consume their blocks anyway
b) it is not possible to add "on the fly" additional 64 ports to the 
particular subscriber that abuse some Apple application (and go to 1k ports 
consumption) that may drive far above any reasonable limit of ports per subs.
Design should block a big enough number of UDP/TCP ports for every subs 
(even most silent/conservative).

Ed/
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Jared Brown
Sent: Friday, March 25, 2022 4:49 PM
To: nanog@nanog.org
Subject: MAP-T (was: Re: V6 still not supported)

Most IPv6 transition mechanisms involve some form of (CG)NAT. After 
watching a NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, 
or something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared

Re: V6 still not supported

[Philip Homburg]

>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: A straightforward transition plan (was: Re: V6 still not supported)

[Philip Homburg]

>If by ?straightforward transition plan? one means a clear and rational set of 
>options that allows networks to plan their own migration from IPv4-only to IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of effor
>t reasonable comparable to just running IPv4, then I would disagree, as such a
>n "IPng transition plan? was achievable, expected, and we collectively failed 
>to deliver on it (as noted below) 

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a process
failure. However, it is not clear to me that waiting a few years would 
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT. 
>From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6. 

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation 
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Masataka Ohta]

james.cut...@consultant.com wrote:


Overlap here refers to network address space address space, a
fundamental part of this discussion.  Formerly separate networks
containing separately managed rfc1918 spaces are prone to overlap
require ingenious solutions for end-to-end traffic without
renumbering.


If you are not satisfied with static punch holing and require
to use many connections with fully dynamically generated
port numbers by end systems, then, as I wrote:

: The basic idea is to let NAT boxes perform address translations
: only without adjusting check sums or translating ports and
: to let end systems perform reverse address translations,
: which restores correct check sums, and port number
 ^^^
: restrictions.
  ^

end to end NAT is your solution, because a locally provided
port number combined with a globally unique address is
a globally unique identifier at the transport layer.


Mergers do not cause relocation of an office, which is not germane to
this discussion.


As mergers often cause office mergers, which imply relocations, it
is your fault to have failed to clarity details.


Or, if you mean network merger remotely with VPN, small number of
hosts requiring E2E transparency may be renumbered, but it is not
so painful.


Nobody mentioned VPN or limiting the number of hosts requiring E2E.


It is also your fault not to have considered VPN at all, even
though VPN could reduce renumbering efforts a lot.

> "not so painful" is not  meaningful metric in this discussion.

Then, IPv6 is just painful. PERIOD.

Masataka Ohta

Re: Routes to twitter via 8359 8359 8342

[Peter Potvin via NANOG]

I'm seeing the same thing from my edge routers in Toronto and New York but
am discarding the route on each due to it being RPKI invalid. Looks like a
potential hijack by a Russian ISP based on the origin ASN.

NLNOG RING also shows some of their peers accepting the invalid
announcement while others are accepting the correct one.
https://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=104.244.42.0/24

Regards,
Peter Potvin

On Mon., Mar. 28, 2022, 8:36 a.m. Drew Weaver, 
wrote:

> Is anyone else seeing this route destined for Twitter in the US being
> directed through 8359 announced by 8342?
>
>
>
> 104.244.42.0/24
>
>
>
> Just curious, replies off list welcome.
>
>
>
> -Drew
>
>
>
>
>
>
>

-- 
The information contained in this message may be privileged, confidential 
and protected from disclosure. This message is intended only for the 
designated recipient(s). It is subject to access, review and disclosure by 
the sender's Email System Administrator. If you have received this message 
in error, please advise by return e-mail so that our address records can be 
corrected and please delete immediately without reading, copying or 
forwarding to others. Any unauthorized review, use, disclosure or 
distribution is prohibited.
Copyright © 2022 Accuris Technologies Ltd. All 
Rights Reserved.


L'information contenue dans ce message pourrait être de 
nature privilégiée, confidentielle et protégée contre toute divulgation. Ce 
message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le 
gestionnaire de système du courrier électronique de l'expéditeur pourrait 
avoir accès à ce message, l'examiner et le divulguer. Si ce message vous 
est transmis par erreur, veuillez nous en aviser par courrier électronique 
à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez 
le supprimer immédiatement, sans le lire, le copier ou le transmettre à des 
tiers. Tout examen, toute utilisation, divulgation ou distribution non 
autorisé de cette information est interdit.
Droit d'auteur © 

2022 
Accuris Technologies Ltd. Tous droits réservés.

Re: Routes to twitter via 8359 8359 8342

[Job Snijders via NANOG]

On Mon, Mar 28, 2022 at 12:33:05PM +, Drew Weaver wrote:
> Is anyone else seeing this route destined for Twitter in the US being
> directed through 8359 announced by 8342?
> 
> 104.244.42.0/24
> 
> Just curious, replies off list welcome.

Seems visible in a handful of places:

$ w3m -dump 
'https://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=104.244.42.0/24' | fgrep 
8342
BGP.as_path: 198644 21283 8447 8359 8342
BGP.as_path: 8607 8359 8342
BGP.as_path: 16086 8359 8342
BGP.as_path: 31027 8359 8342

There is a RPKI ROA which only authorizes AS 13414 to originate that
/24, chances are that RPKI ROV is helping limit the blast radius.

https://console.rpki-client.org/rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/521eb33f-9672-4cd9-acce-137227e971ac/69f7b69a-b519-4b2d-a7be-03aa505b2576/672a3d03-abc2-3f66-8052-26ed409619a3.roa.html

Kind regards,

Job

Routes to twitter via 8359 8359 8342

[Drew Weaver]

Is anyone else seeing this route destined for Twitter in the US being directed 
through 8359 announced by 8342?

104.244.42.0/24

Just curious, replies off list welcome.

-Drew

Re: Let's Focus on Moving Forward Re: V6 still not supported

[John Gilmore]

Christopher Morrow  wrote:
> I think the advice in the draft, and on the quoted page of Google cloud
> docs is that you can use whatever address space you want for your voc
> network. I think it also says that choosing poorly could make portions if
> the internet unreachable.
> 
> I don't see that the docs specify usage of 240/4 though.

Thank you for catching this!  Draft-schoen-intarea-unicast-240 links its
reference [VPC] to:

  https://cloud.google.com/vpc/docs/vpc#valid-ranges

As late as March 18, 2022, that page included a table of "Valid ranges"
that include "240.0.0.0/4", which you can see in the Internet Archive's
"Wayback Machine" copy of the page:

  
http://web.archive.org/web/20220318080636/https://cloud.google.com/vpc/docs/vpc

  A subnet's primary and secondary IP address ranges are regional
  internal IP addresses. The following table describes valid ranges.  ...

  240.0.0.0/4   Reserved for future use (Class E) as noted in
RFC 5735 and RFC 1112.

Some operating systems do not support the
use of this range, so verify that your OS
supports it before creating subnets that use
this range.

However, as of March 20, Google moved that table into a subsidiary page,
the "Subnets overview", which is now linked from the original page:

  
http://web.archive.org/web/20220320031522/https://cloud.google.com/vpc/docs/vpc
  
http://web.archive.org/web/20220328102630/https://cloud.google.com/vpc/docs/subnets

The same information about 240/4 is there.

Thanks again for the bug report!  We'll update the URL in the next
version of the draft.

John