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 th

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

[Masataka Ohta]

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 the reliability

longer packets mean more collision (with hidden terminals)
probability and less reliability.

A link broadcast domain must be same for all the members
of the link and should be defined as set of terminals which
can receive broadcast from a central station (or, stations)
with certain probability, which is why Wifi broadcast is
relayed by a central station.


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


Ethernet? Even though its broadcast is reliable?

Though Wifi bridged by Ethernet may have its own problems,
they are Wifi-specific problems.


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.


You can't expect people still insisting on IPv6 as is much.


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.


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.

Masataka Ohta

AKAMAI CDN

[Nielsen Kaezer]

I'm interested

ASN 53172

Re: AS8075(Microsoft) Contact

[richey goldberg]

Unless you are mega huge gigantor network they will never respond.  I tried for 
a year doing everything they required when I worked for another provider and 
could never get anywhere with them. It’s kind of like reporting abuse to 
them.   They just don’t seem to care if you are not big enough.

0richey

From: NANOG  on behalf of 
netops Network Operations via NANOG 
Date: Thursday, January 12, 2023 at 8:04 AM
To: nanog list 
Subject: AS8075(Microsoft) Contact
Hi,
Is anybody from AS8075(Microsoft) on the list ?

We are trying to establish BGP Public/Exchange Peering Sessions for almost 3 
months... Multiple emails sent to 
peer...@microsoft.com and 
inte...@microsoft.com, but never heard back.
Later we followed the guide and created all the connections via Azure 
PowerShell and again, it is in PendingApproval State for more then 1 month.
Does everybody has the same experience establishing BGP Peering Sessions with 
Microsoft ?

AS8075(Microsoft) Contact

[netops Network Operations via NANOG]

Hi,

Is anybody from AS8075(Microsoft) on the list ?

We are trying to establish BGP Public/Exchange Peering Sessions for almost
3 months... Multiple emails sent to peer...@microsoft.com and
inte...@microsoft.com, but never heard back.
Later we followed the guide and created all the connections via Azure
PowerShell and again, it is in PendingApproval State for more then 1 month.

Does everybody has the same experience establishing BGP Peering Sessions
with Microsoft ?

Re: AKAMAI CDN

[Niels Bakker]

I can put you in touch with your account manager, what's your ASN?


-- Niels.

* pascalma...@gmail.com (Pascal Masha) [Thu 12 Jan 2023, 12:21 CET]:

Hello,

Anyone from Akamai responsible for making decisions on cluster
scaling /refresh here?

Kindly contact me offlist.

Regards

Paschal Masha

AKAMAI CDN

[Pascal Masha]

Hello,

Anyone from Akamai responsible for making decisions on cluster
scaling /refresh here?

Kindly contact me offlist.

Regards

Paschal Masha

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

[William Herrin]

On Wed, Jan 11, 2023 at 11:16 PM Vasilenko Eduard via NANOG
 wrote:
> The comment looks outdated: Who cares now about ATM?

You may have missed the sarcasm. The 1995 Addison Wesley IPng book
spends pages and pages talking about potential IPv6 use in the Navy
and interoperability with ATM before it gets around to discussing IPv6
in the enterprise and acceptance on the general Internet. It's an
understatement to say their priorities were out of whack.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/