> AFAICS there's certainly enough room for me to experiment with patches to
> i) reduce MTU to avoid problems arising from L2 MTU mismatches and
> ii) to reduce the amount of fragments (at the expense of more UDP packets)
> without any tweaking of the standards.
In case you're interested, here's t
Juliusz Chroboczek wrote on 20/09/2019 14:23:
1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.
I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
A OK so you're saying this is already covered in (Section 4.4 of) 7787
[..
>>> 1) DNCP allows an option of whether a network state TLV contains optional
>>> nested payload (HNCP) TLV's or not.
>> I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
> A OK so you're saying this is already covered in (Section 4.4 of) 7787
[...]
> state hash. The Node Sta
Thanks for your response.
Juliusz Chroboczek wrote on 20/09/2019 12:40:
1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.
I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
The Network-State TLV only contains the network st
> 1) DNCP allows an option of whether a network state TLV contains optional
> nested payload (HNCP) TLV's or not.
I'm pretty sure that's not the case. RFC 7787 Section 7.2.2.
The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs. An implem
Hi,I've done some more investigation and the "problem" packet size growth looks to be the result of a single UDP reply packet containing multiple node state TLV's.This reply is triggered by a query from a new node joining an existing network, where the new node requests node TLV updates for all of
On Sep 19, 2019, at 7:51 PM, Juliusz Chroboczek wrote:
> Because HNCP allows aggregating multiple TLVs in a single packet, to the
> implementation's discretion. Section 4.2 of RFC 7787.
Thanks, Juliusz. This and your previous message were quite helpful.
I think there does need to be some hacki
> The reason for the 64k limit is clear (due to the design choice of relying on
> UDP fragmentation).
> What's still unclear to me is why the packet contains all the nodes' TLV's.
Because HNCP allows aggregating multiple TLVs in a single packet, to the
implementation's discretion. Section 4.2 of
>> HNCP is a standards track protocol, and there's nobody left who's
>> willing and competent to work on a new revision.
> Yes, of course. We can never change a standards track protocol. That
> would be wrong. :)
My wording was perhaps badly chosen. Sorry for that.
I meant to say that I don't c
> I notice in the current Openwrt code that the max UDP packet size is set at
> 9000 octets with the comment:
> /* Very arbitrary. On some implementations, I have seen some issues
> * with 10+kb frames so we use this for now. It MUST be significantly
> * more than 4k, due to how code is written
On 19 Sep 2019 15:11, Ted Lemon wrote:Yes, of course. We can never change a standards track protocol. That would be wrong. :)
What I’m trying to understand is how bad a problem this is.That's what I'm still trying to understand.The reason for the 64k limit is clear (due to the design choice of rel
Juliusz Chroboczek wrote on 19/09/2019 01:02:
The problem is, how’d the packet get so big that it was fragmented?
HNCP relies on network-layer fragmentation: it uses UDP and has no
application-layer mechanism for fragmenting large TLVs. See Section 4.2
and Appendix B.2 of RFC 7787.
Agreed. I'm
Yes, of course. We can never change a standards track protocol. That would be
wrong. :)
What I’m trying to understand is how bad a problem this is.
> On Sep 19, 2019, at 04:56, Juliusz Chroboczek wrote:
>
>
>>
>> This still doesn’t address the problem that the HNCP packet needs to be
>> fr
> This still doesn’t address the problem that the HNCP packet needs to be
> fragmented. Fragmented Multicast doesn’t scale well.
HNCP doesn't fragment multicast, it only uses fragmentation for (link-local)
unicast. This is way less severe than what you incorrectly claim.
At any rate, the right
This still doesn’t address the problem that the HNCP packet needs to be
fragmented. Fragmented Multicast doesn’t scale well.
> On Sep 18, 2019, at 19:09, Juliusz Chroboczek wrote:
>
>
>>
>> If you have a discontinuous L2 MTU, you do not need fragmented packets
>> to see packets disappear.
>
> If you have a discontinuous L2 MTU, you do not need fragmented packets
> to see packets disappear.
Ah, I see.
> No fragmentation of any sort involved, just incorrectly set up L2 segments.
Right. It's an incorrect network setup.
To fix that, it should be enough to point the tunnel directly at
> The problem is, how’d the packet get so big that it was fragmented?
HNCP relies on network-layer fragmentation: it uses UDP and has no
application-layer mechanism for fragmenting large TLVs. See Section 4.2
and Appendix B.2 of RFC 7787.
(I seem to recall that an earlier version of DNCP include
On Sep 18, 2019, at 4:57 PM, Gert Doering wrote:
>> The problem is, how???d the packet get so big that it was fragmented?
> If you have a discontinuous L2 MTU, you do not need fragmented packets
> to see packets disappear.
That’s kind of a non-sequitur. The packet would need to be fragmented in
Hi,
On Wed, Sep 18, 2019 at 04:05:39PM -0400, Ted Lemon wrote:
> On Sep 18, 2019, at 3:39 PM, Juliusz Chroboczek wrote:
> > Is that not a bug?
> The problem is, how???d the packet get so big that it was fragmented?
If you have a discontinuous L2 MTU, you do not need fragmented packets
to see pac
On Sep 18, 2019, at 3:39 PM, Juliusz Chroboczek wrote:
> Is that not a bug?
The problem is, how’d the packet get so big that it was fragmented?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report ICMP
> PTB, so HNCP packets in one direction get through, but replies get dropped.
Is that not a bug?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org
Ray Hunter (v6ops) wrote:
> First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3
breaks
> UDP fragmentation (works as designed).
> The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report
> ICMP PTB, so HNCP packets in one direction get through
Mark Andrews wrote on 18/09/2019 12:00:
Question: As a simple mitigation, is there any way of manually signalling to
the kernel that ALL UDP packets on port 8231 should assume an PMTU of 1280
octets?
setsockopt(IPV6_USE_MIN_MTU=1); from RFC 3542 works provided the OS has
implemented it. It
> On 18 Sep 2019, at 5:36 pm, Ray Hunter (v6ops) wrote:
>
> Hi,
>
> I've been experimenting with Homenet before looking at enhancing HNCP for
> extended naming functionality (the current implementation only covers
> resolver configuration and not name server configuration).
>
> During my te
Hi,
I've been experimenting with Homenet before looking at enhancing HNCP
for extended naming functionality (the current implementation only
covers resolver configuration and not name server configuration).
During my testing I managed to break HNCP, so that it got stuck in a
state where it d
25 matches
Mail list logo
