[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: IoT 64
From:       Alexandre Petrescu <alexandre.petrescu () gmail ! com>
Date:       2018-06-25 9:27:33
Message-ID: f6509375-fbae-8def-72e8-eab713ab3386 () gmail ! com
[Download RAW message or body]

I had private email with Michael.

He explained it better to me.

I agree with most points he makes: Ethernet and WiFi on IoT devices are
so used to /64 and SLAAC, which make for a 64 problem. Yet these same
IoT devices could work with host-based routes too. If they did, there
would be no /64 problem.

He rightfully points to a particular protocol that would work and that
has no /64 problem and that does not use SLAAC. It's RPL.

On my particular IoT context, I can not consider RPL.

But I do agree with Michael's technical points.

Alex

Le 24/06/2018 à 19:00, Alexandre Petrescu a écrit :
> 
> 
> Le 24/06/2018 à 16:22, Michael Richardson a écrit :
> [...]
> 
>> ----------------MESSAGE ORGINAL ci-dessous------------------
>>
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>      > But we have no idea what the future will bring or what the IoT 
>> will
>>      > really turn out to be. A few moments' thought shows that the edge
>>      > networks for moving vehicles and fixed roadside infrastructure 
>> will be
>>      > nothing like existing provider/subscriber networks, for 
>> example. For
>>      > those networks we need total flexibility in the design space; a 
>> magic
>>      > boundary at /64 looks like premature ossification to me.
>>
>>      > I have no idea what the SAIL and LAP values for a generic IoT 
>> network
>>      > might be, but I see no reason to believe they will be 64.
>>
>> Real (non-wifi-connected camera stuff) IoT networks are not based upon
>> emulating the 25yr obsolete 10base2 Coax cable the way that 100G ethernet
>> still is.
> 
> Other IoT networks do use Ethernet, SLAAC and do need growth beyond 64.
> 
> For example, an IoT Router that connects a car to the Internet.  The car 
> network is made of more than 2 segments of Ethernet subnets.  The main 
> access to Internet is cellular.  The device that does it is called "IoT" 
> device by manufacturer, because it is small and has sensors too.  There 
> is a tiny Ethernet RJ45 involved too.
> 
> Other smartphones, glasses and watches are also called 'IoT' by their 
> manufacturers and use SLAAC.
> 
> NB-IoT devices equipped with Ethernet RJ45 are also hindered by 64.
> 
> Refs available upon request.
> 
>> Current technology, (RFC6550-ROLL, but also if you use OLSRv2,
>> BABEL, and even LOADNG), assigns a /128 to each IoT node from within
>> a /64, and routes the /128.
> 
> That assignment is a kind that is not SLAAC.
> 
> Maybe that is a difference that makes it not be bothered by 64.
> 
> Alex
> 
>>  The network size is not limited by routing table
>> size of the smaller nodes, but by the routing table size of the largest
>> nodes.
>>
>> The /64 boundary is useful within 2000::/3 and ULA-space, because it 
>> becomes
>> the natural aggregation point beyond which routing information is always
>> summarized.
>>
>> The real problem is that people are clinging to ethernet and wifi as
>> broadcast media, when they haven't been that for decades: it's all 
>> layer-2
>> tricks caused by a shortage of IPv4 for subnetting.
>>
>> If you can give that up, then the things go straight down to the bottom
>> *immediately*, with /128 per-host with /128 routing, and layer-2 and 
>> layer-3
>> becoming blurred, and IPv4 being mapped into IPv6-only networks.
>> IID generation still works, and you still need to allocate at least a 
>> /64 per
>> home, but the L bit is always 0.
>>
>> -- 
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>   -= IPv6 IoT consulting =-
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]