people think?
I think it's too much thinking.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
could generate
> more collisions and make the problem worse.
1) Not re-inventing TCP is important.
2) Perhaps the question is better turned around: what should the sender do if
an ACK arrives without having been asked for?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting
ge 1 mode for fragments?
Allocating all fragment code points from page 1?
Maybe we should have a document about source routing fragments end to end for
projected DAO, and then we can see the full picture.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Des
n IPv6 header (e.g., a new option in a
Pascal> hop-by-hop header) should be provided, even if for now it appears
to be
Pascal> for completeness only.
I haven't read the deadline draft at this point, so I don't know if a new hop
by hop header makes sense, but it sou
d!
> --
> SY, Jen Linkova aka Furry
>
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------
re any new state in
the end device, as they don't even have to listen for the ECHO REPLY.
Let me suggest a different hack: use stateful DHCPv6.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
the NCE usage by untrusted nodes so that we have space for as many
registered nodes.
I think you are agreeing with me above.
I believe that the issue that Jen is describing would for unaware leaves that
were sleepy.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
_
hange the authenticate messages. The key used for
> encryption can also be negociated via DTLS.
"Just use DTLS" doesn't really work.
Please reference 6tisch-minimal-security instead.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
a good idea if the content would otherwise be padding.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
t;
to the list of aliases for PANC.
Thank you for mentioning 6tisch-minimal-security.
There is also a BRSKI-like 6tisch mechanism that uses IDevID.
Is it the case that the PLC devices can have no L2 security as an option?
I believe that you may wish to outlaw that situation.
--
Michael Richardson ,
ation layer and
> above, the L2 security is considered to be applied by default.
Then uou can use dtsecurity-zerotouch-join or 6tisch-minimal-security.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
certificate can't be provisioned a priori?
dtsecurity-zerotouch-join assumes a certificate provisioned prior to deployment.
So I can't agree with the last sentence.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_
oob] via
transports like PANA [RFC5191]. No specific mechanism is specified by
this document as an appropriate mechanism will depend upon deployment
circumstances.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
De
rk encryption key
> appropriate for the layer-2 can also be acquired during the onboarding
> process.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
compared to RFC6282.
Since you have assumed some kind of hierarchal network, would you use RFC6550
for routing, or is it that you don't need any routing due to your architecture?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ot
if there is a win until most nodes have
deployed it.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
man. Or maybe we need to do the LLN work here, and then write an
>> operational/deployment considerations document for v6ops.
> Indeed. But 6MAN is a think tank that produces threads whereas 6lo is
> alive and kicking. I tried draft-thubert-6lo-unicast-lookup at 6MAN
> under the same thinking as yours here, and it stay rotting on a shelf.
okay.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
of
> RPL. Routing related procedures is refined according to this design,
> see Section 5, 6 and 8.
I'm unaware of a large need to renumber.
Maybe that's a result of lack of IPv6 deployment.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sand
me border
> router or edge node?
I think that it is okay if it doesn't work for mixed prefixes from multiple
providers.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
tions" if "brown
field" is not considered a well enough known term.
12.2 why is the I field repeated in this table, if it was defined in 8505?
The need for an rfc6550bis seems even more important after all these patches.
--
] Never tell me the odds!
6lo recording (conflict with jwp BOF) yesterday, and the
question about resiliency and alternate paths is a very serious one.
Is this a routing protocol or not?
I do not support adoption of the document.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works I
Luigi IANNONE wrote:
> Resiliency is indeed a very important issue and we wrote an entire
> document on it:
> https://datatracker.ietf.org/doc/draft-li-nsa-reliability/
Yes, I know.
Does the protocol have any use/value without that?
Where would I use it?
--
Michael R
together in any
topology and have them work is definitely a win.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo
d.
The other question is whether or not you have looked at the BIER routing work
that we started in ROLL, as that actually might map even better to your use
case.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
D
://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/slides-interim-2021-roll-02-sessa-issues-with-controlling-secure-network-enrollment-in-rpl-networks-00
slide 4.
Then you can say things like, "node 20 is a Leaf Node"
--
Michael Richardson. o O ( IPv6 IøT
baseT1 that the
automotive industry likes.
One concern that I have with NSA is that I think the network can get renumbered
whenever there are new devices.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottaw
rt a new device in the tree, then all of the tree below that device
has to renumber.
I also think that it can happen if I add a new device to an existing rank.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and W
se case we have so far is sensors in a data center
>> I also think that it can happen if I add a new device to an existing
>> rank.
> No, as long as there is enough address for this new device.
And if there isn't?
--
Michael Richardson. o O ( IPv6 IøT cons
"Liguangpeng (Roc, Network Technology Laboratory)" wrote:
>> -Original Message- From: Pascal Thubert (pthubert)
>> Sent: Monday, August 22, 2022
>> 2:18 PM To: Liguangpeng (Roc, Network Technology Laboratory)
>> Cc: Michael Richardson
block?
I was a fool to have no used IPv6 in the first place.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf
aying that I have active, physical, hands-on experience with cabinets in
data centers today.
I have doubts that I could wire NSA correctly, and I'm certain that I wouldn't
be
able to get the people that do work for me to get it right.
--
Michael Richardson. o O ( IPv6 IøT consulti
ER encoding at the same time, and
> would be happy to contribute that part.
I think it would exceed our allocation of Pascal Thubert cycles :-)
So it would be great if we had some gradual student or some super brliiant
intern to work on this.
--
Michael Richardson.
I assumed that the HomeRouter had a physical interface that was a PLC.
Maybe it's physically a USB cable, but the PLC's layer-3 interface was inside
the homerouter.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and
mention other choices somewhere?
What about in the case of non-LLNs? Would it work with OSPFv3?
Would it work for /128 prefixes on un-bridged wifi?
Could PASA make use of this? (I'm genuinely unclear)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Wo
Pascal Thubert (pthubert) wrote:
> What if we start like:
Good.
> " 3. Overview
>This specification extends [RFC8505] and inherits from [RFC8928] to
> provide a registration method - called subscription in this case - for
> anycast and multicast address. [RFC8505] is a
llow-cable.
https://en.wikipedia.org/wiki/10BASE5
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
charter.
I don't think that they want it.
> Third, one potential application that has been suggested is low-cost
> sensors in server racks,
> yet I have seen no suggested wired MAC for this application. RFC 8163
> covers this base.
I don't buy this soluti
ing it
this way, and it would be nice to figure out what's in the way here)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo ma
a. What do they want, if anything.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
suitable one can be
> chosen for each deployment.
I don't object to multiple methods in theory, if there is a way to clearly
articulate (at build time), which one will be used. But it would be better
for mindshare and debugging, and code maintenance to have fewer methods.
--
Michael
I have read this document at -00, and support adopting it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo
network to accept gratuitous L2 address spoofing?
How does this interact with Back-Bone Router EARO processing?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6
te the L2-security upwards, then I agree that this transition could be
secured. I'm still thinking that we might need a L3-RPL level signal
which would be secured.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description:
try, and if so would we need different liason
request for that?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
conclude that this is not the case.
Please confirm that there is simply unwritten text at this point, rather
than references I haven't followed.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP sign
R. CGA is more than a decade old now.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
-ietf-6lo-paging-dispatch in
some way. I wonder if it worth delay to do this now?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https
about what to do, and to the point of having a
normative reference to something concrete that ought to be done.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing
t L3 IID in a deterministic, but
private to holders of the L2 key, from a shorter set of bits that would go
into IPHC header is a better goal. I think that this fits into charter for
6lo. (It would be a good codestand.ietf.org project too!)
--
Michael Richardson , Sandelman Software Works
-
sion/compression cycle.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
t; sure that new standards will not use the same values as the experiment.
> Is that something we should be enable here?
Yes. It's a very good idea.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descri
savings will be
probably on the order of ten bytes of zeroes.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
to reply to myself
Michael Richardson wrote:
> This will contain a copy of the 16-byte DODAGID so that a very sleepy
> node returning to operation would be able to identify which beacon
> belongs to which network. A joining node will have no idea which
> DODAGID it
A few weeks ago I posted about draft-ietf-richardson-6lo-ra-in-ie, which was
a method for storing 6loRH compressed Routing Advertisements in 802.15.4
Information Elements. The mechanism described would have permitted arbitrary
IPv6 packets to be stored there (it was a general mechanism).
The sub
p with 6lowpan-ND behavior and whether it is
moving
> away from 6lowpan base requirements.
We haven't changed 6lowpan-ND behaviour.
It's just about transporting (multicasting) RA-equivalent information inside
the Enhanced beacon.
--
Michael Richardson , Sandelman Software
comments about this, and it would be
worth having on the agenda for IETF98.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca
ed bandwidth aggregation mechanism at link
> layer.
I don't understand how TSCH could be be worse than CSMA methods.
Probably, I don't understand enough about your needs, or the context of your
experiment.
--
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
hash of the DODAGID of the
network. The result will be a 32-byte hash, and the lower 16-bytes should be
used.
{oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the
diagram}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.
I would suggest that networks that want to move from mesh-under to route-over
and are already running IPv6, would be best to use RPL in the way 6tisch
uses it. Gather the topology with RPL, then establish 6tisch-like tracks
at L2.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT c
hat we'll get some
more details soon.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
PDs in the field, and when they discover upstream CPDs that speak RPL
they join both PANIDs. Then they just send DAOs for all their L2 connected
BPDs.
There are probably some ND issues to sort out, and maybe an (efficient!) ND
proxy is in order. Basically the RPL becomes the "backbone"
source MAC address to from MAC_prev to MAC_self
"to from" --- is this correct, or is there an extra word here?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
eated an MPLS LSP can carry non IP
> traffic.
I think you are saying that since the final fragment assembler will have
reassembled the L3 header, that it will know where to send the ACK.
>
> change the source MAC address to from MAC_prev to MAC_self
&g
rg/doc/search/?name=rafiee&sort=&rfcs=on&activedrafts=on&olddrafts=on
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
e my routing for me".
This is not a burden, because such leaf devices do not really exist yet.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
hat I should change RFC6775-update to specify that.
> I'm happy with that approach and will do it if the WG does not
> disagree. What do others think?
> -Original Message-
> From: Roll [mailto:roll-boun...@ietf.org] On Behalf Of Michael Richardson
> S
at
correct?
> As it stands in RFC 6775 update, the fact that the DAR and DAC messages
> are in fact extended DAR and DAC is indicated by the ICMP code of 1.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Softwar
what
to do with the document. I suspect that a bunch of it will get removed,
and that the document will change name, but I think we can do that.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
we can discuss things like
whether we need more variants...
> Adding more
> variants of 6LoWPAN to the mix is NOT going to help with that.
or probably *FEWER* variants.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman
uld be adopted (or not), please send a
> message to that effect in response. Let’s give it another week.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6
18 15:00
> | Europe summer time (Paris, GMT+02:00) | 1 h
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
1-6lo-6lo-wg-charter-00
> These slides are the ones that were presented in the 6lo session at
> IETF 121.
I didn't make the meeting, but I reviewed the slides, and they look good to
me. Thank for the link to IOTOPS.
--
Michael Richardson , Sandelman Software Works
remember everything. I also don't think anyone has time/energy to do that
work now.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
74 matches
Mail list logo
