Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

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.
> 
> 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 a Homenet
> router rather than relying on bridging.  (A good idea in any case, since
> Babel is able to make better routing decisions if the tunnel is directly
> visible to it.)
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

> 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 a Homenet
router rather than relying on bridging.  (A good idea in any case, since
Babel is able to make better routing decisions if the tunnel is directly
visible to it.)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

> 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 included provisions for
application-layer fragmentation of TLVs, but that was removed at some
point.  I don't remember why.)

Let's please come back to my question.  RFC 4443 paragraph 3.2 says

   A Packet Too Big MUST be sent by a router in response to a packet
   that it cannot forward because the packet is larger than the MTU of
   the outgoing link.

If your tunnelling software violates this, how is it not buggy?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DoH??

[Stephen Farrell]

On 18/09/2019 23:51, Ted Lemon wrote:
> Let’s not discuss this here. This is a topic for add. 

Yes. The ADD list was setup for that discussion (and
exploded). A review of it's archive [1] might be eye
opening, if tedious.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/browse/add/

> 
>> On Sep 18, 2019, at 18:27, Michael Thomas  wrote:
>>
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DoH??

[Ted Lemon]

Let’s not discuss this here. This is a topic for add. 

> On Sep 18, 2019, at 18:27, Michael Thomas  wrote:
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DoH??

[Michael Thomas]

On 9/18/19 3:12 PM, Ted Lemon wrote:
On Sep 18, 2019, at 6:07 PM, Michael Thomas > wrote:
So I'm a little unclear about the specifics of Firefox using DNS over 
HTTP, but wouldn't this affect homenet naming, or any split horizon 
kind of naming?


In order for DoH to not break lots of things, it has to be implemented 
in such a way that special-use names are not resolved using a global 
resolver, and that VPN-supported names are looked up using the VPN 
resolver.   It would also be nice if there were a way for the homenet 
to signal that a public domain belonging to it is resolved locally, so 
that split-horizon naming on the homenet works correctly.  Similar 
functionality will be required for corporate networks that do 
split-horizon naming.


Yeah, that's pretty much what it seemed to me too. How vetted was this? 
I mean, did it make the rounds in standards-ville, or is this roll your 
own by Mozilla?


I also don't get what the motivation is, and/or problem it's trying to 
solve. Seems pretty scary to have a single point of failure (Cloudflare) 
introduced.


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DoH??

[Stephen Farrell]

Hiya,

On 18/09/2019 23:07, Michael Thomas wrote:
> 
> So I'm a little unclear about the specifics of Firefox using DNS over
> HTTP, but wouldn't this affect homenet naming, or any split horizon kind
> of naming?

FWIW, I just tested with FF nightly in my home n/w for a
name that is locally resolved within net10 but that also
has a global IPv6 address. It worked fine with FF's TRR
mode 2, though there was maybe a short but visible delay
before FF fell back to the system resolver.

So - doesn't have to be a problem.

Cheers,
S.

> 
> Mike
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DoH??

[Ted Lemon]

On Sep 18, 2019, at 6:07 PM, Michael Thomas  wrote:
> So I'm a little unclear about the specifics of Firefox using DNS over HTTP, 
> but wouldn't this affect homenet naming, or any split horizon kind of naming?

In order for DoH to not break lots of things, it has to be implemented in such 
a way that special-use names are not resolved using a global resolver, and that 
VPN-supported names are looked up using the VPN resolver.   It would also be 
nice if there were a way for the homenet to signal that a public domain 
belonging to it is resolved locally, so that split-horizon naming on the 
homenet works correctly.  Similar functionality will be required for corporate 
networks that do split-horizon naming.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] DoH??

[Michael Thomas]

So I'm a little unclear about the specifics of Firefox using DNS over 
HTTP, but wouldn't this affect homenet naming, or any split horizon kind 
of naming?


Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

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 this 
case.  The question is, how’d it get that big?  If we’re seeing packets large 
enough to fragment in a normal-sized network, that’s a really big problem 
(pardon the pun).

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Gert Doering]

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

Host A has an ethernet MTU of 1500.  Sends a packet with 1400 bytes, no
fragmentation needed.

Somewhere in between is an ethernet bridge that only handles 1350 payload
("L2TPv3 with an outer max packet size capped to something too small to
transport 1518 byte packets inside, and not doing outer fragmentation")

Packet gone.

No fragmentation of any sort involved, just incorrectly set up L2 segments.

(Rule #1 for real world operation: ensure that end system L3 MTU is 
always <= the smallest L2 MTU that the packet might encounter in your 
L2 fabric)


Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

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

Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

> 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/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Michael Richardson]

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, but replies get
> dropped.

> Early drafts of HNCP stated that UDP fragmentation would not be broken in 
the
> Homenet for the foreseeable future. Well I managed to break that ;)

(Why are we using a L2 tunnel?  So that a few of us, including Ray, can hack on 
stuff together)

> Changing the MTU on the LAN interfaces of my routers to 1280 brought
> everything back to normal, as expected.

I think that the right answer is for the software to assume a 1280 MTU.
Someone could write an HNCP extension to do PLPMTUD inside afterwards to
increase the size if desired.

> Question: If Homenets are moving to flat L2 meshes over foo, as some have
> said, will this impact HNCP?

Unlikely, in my opinion, because "good" L2 meshes will preserve the 1500 byte 
MTU.

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

> That wouldn't require any specification change and would allow HNCP to 
work
> reliably in the presence of tunnels and varying MTU's that don't match the
> local interface MTU.

I think that the HNCP code can do this.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

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’s a really pity that POSIX hasn’t picked up RFC 3542 in the 
16 years since it was published like they picked up RFC 3493.  This is a epic 
fail of SDOs.


Thanks for the tip.

Unfortunately checking  in the current openwrt build tree.
..
#if 0   /* not yet */
#define IPV6_USE_MIN_MTU    63
#endif

:( not yet implemented

--
regards,
RayH

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] appropriateness of draft-shytyi-opsawg-vysm-03 to homenet WG?

[Ted Lemon]

That diagram isn’t consistent with what Homenet has been trying to build: it 
appears to be a base assumption of this work that there is a single virtual CPE 
router, and that’s not a homenet problem.

> On Sep 18, 2019, at 4:14 AM, Alexandre Petrescu 
>  wrote:
> 
> 
> 
> Le 17/09/2019 à 15:34, Ted Lemon a écrit :
>> On Sep 17, 2019, at 9:29 AM, Alexandre Petrescu 
>> mailto:alexandre.petre...@gmail.com> 
>> >>
>> wrote:
>>> Thanks for the reply.  As I do not author the draft, and my
>>> colleague is not subscribed to this list, I paste here his reply to
>>> your question:
 It is not really clear if the draft is appropriate to the homenet
 wg. One can state that this draft presents a tool/solution
 (service yang model) for orchestator to manage the different uCPE
 equipment. uCPE eqipment is not regular cpe/homenet device. uCPE
 is a host that hosts guest OSs. uCPE is like PC with virtualbox where the 
 VMs are running (VMs such as homenet router,cisco
 router, firewall, SD-WAN.)
>> Thanks.   The question I would ask here is, is it intended that this
>> uCPE integrate into a multi-subnet, multi-homed homenet?
> 
> Temporary speaking for my colleague, this is what he has to say to the 
> question:
> 
>> If we are talking, for example, about several IPv6 prefixes that are
>> learned from muliple ISPs I could suggest that uCPE is transparent in
>> this case. On the figure below we can see that uCPE connects 2 PHY
>> ports via virtual Links to the Virtual Ports of VNF. So it is the
>> VNF(vRouter) that is doing the job. There is example where the
>> constructor of equipment merges the uCPE NFVIs with router (i find it
>> as a very particular case).
>> If we are talking about implementation of babel in the uCPE please
>> check the figure below. I suppose it is a vRouter that will have this
>> functionality (not uCPE NFVIs).
>> P.S. There is a management of NFVIs that maybe could be integrated.
>> But it is a question if there is an interest to do that.
> 
>   ++
>   |uCPE|
>   ||
>   | ++ |
>   |   |-|vRouter |-|WAN1
> LAN1 --||  | ++ |
>   ||  |  | |
>   ||  |  | |
> LAN2 --||--|  |-|WAN2
>   ||   |
>   ||   |
> LAN3 --||   |
>   ||
>   ||
>   ++

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] DNCP/HNCP Revisited

[Mark Andrews]

> 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 testing I managed to break HNCP, so that it got stuck in a state 
> where it didn't converge.
> 
> Looking at the specification in detail this shouldn't have been a surprise to 
> me or anyone else due to the design choices that were made.
> 
> 
> 
> 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, but replies get 
> dropped.
> 
> Early drafts of HNCP stated that UDP fragmentation would not be broken in the 
> Homenet for the foreseeable future. Well I managed to break that ;)
> 
> So this is a known situation.
> 
> Changing the MTU on the LAN interfaces of my routers to 1280 brought 
> everything back to normal, as expected.
> 
> Question: If Homenets are moving to flat L2 meshes over foo, as some have 
> said, will this impact HNCP?
> 
> The Linux kernel (in Openwrt) can/could easily support PMTUD.
> 
> But since the L2 tunnels don't report drops, it makes PMTUD potentially 
> challenging for a simple protocol like HNCP.
> 
> 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’s a really pity that POSIX hasn’t picked up RFC 3542 in the 
16 years since it was published like they picked up RFC 3493.  This is a epic 
fail of SDOs.

> That wouldn't require any specification change and would allow HNCP to work 
> reliably in the presence of tunnels and varying MTU's that don't match the 
> local interface MTU.
> 
> 
> 
> 
> Second Observation: HNCP packets grow quickly in size, which may become a 
> concern for scaling.
> 
> Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro).
> 
> AFAICS that is 64K per DNCP system, not per node.
> 
> Question: Is that correct?
> 
> For my 4 node Homenet, HNCP reached 3140 octets, without any modifications or 
> additions or long names.
> 
> Question: Does the amount of state scale linearly with the number of routers?
> 
> Question: Is this starting to become a concern?
> 
> The limitation for 64K seems to come from the following:
> 
> RFC7788
> Request Network State TLV (Section 7.1.1): The receiver MUST reply
>   with a Network State TLV (Section 7.2.2) and a Node State TLV
>   (Section 7.2.3) for each node data used to calculate the network
>   state hash.
> 
> 
> In the Openwrt implementation, I observe that the requester is requesting the 
> node state for all 4 devices in one packet.
> 
> I also observe that the reply from the peer contains the entire state of the 
> entire Homenet in a single UDP packet (network TLV and node state TLV for all 
> 4 routers + optional payload data).
> 
> Question: Is that as designed/intended? Is this where the 64K data limit 
> comes from in RFC7787?
> 
> If this was a design goal to reduce chatiness, and improve convergence time, 
> is it possible to implement this differently to reduce packet size and/or 
> increase overall TLV data capacity?
> 
> Could the requester in step1 request the network status TLV, and the peer 
> reply with just the network status TLV and the node TLV's, but without the 
> underlying optional HNCP payload data TLV's.
> 
> Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this from 
> blank node data?
> 
> That would give enough information for both nodes to know exactly which 
> payload data needed synchronising.
> 
> Then as step 2, the requester could individually request the Node TLV for 
> each node one per packet, and the peer would reply with the Node TLV but this 
> time including the optional data TLV's. 
> 
> The receiver and peer would both know that HNCP hadn't converged whilst 
> waiting for the additional data, and could mark it internally as being stale 
> whilst waiting for the additional detailed update.
> 
> Question: What would break?
> 
> Question: What would need to be amended in the standard RFC? The 
> more-HNCP-data-to-come TLV in RFC7788?
> 
> Question: Would this tweak increase the ±64K limit of TLV data from being per 
> network to being 64K per node? [max UDP packet size for a single node TLV + 
> associated payload data]
> 
> Question: Is this raw fragmentation by separating DNCP essentials from HNCP 
> payload something that the WG would support?
> 
> regards,
> 
> -- 
> regards,
> RayH
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 

Re: [homenet] appropriateness of draft-shytyi-opsawg-vysm-03 to homenet WG?

[Alexandre Petrescu]

Le 17/09/2019 à 15:34, Ted Lemon a écrit :
On Sep 17, 2019, at 9:29 AM, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>>

wrote:

Thanks for the reply.  As I do not author the draft, and my
colleague is not subscribed to this list, I paste here his reply to
your question:


It is not really clear if the draft is appropriate to the homenet
wg. One can state that this draft presents a tool/solution
(service yang model) for orchestator to manage the different uCPE
equipment. uCPE eqipment is not regular cpe/homenet device. uCPE
is a host that hosts guest OSs. uCPE is like PC with virtualbox 
where the VMs are running (VMs such as homenet router,cisco

router, firewall, SD-WAN.)


Thanks.   The question I would ask here is, is it intended that this
 uCPE integrate into a multi-subnet, multi-homed homenet?


Temporary speaking for my colleague, this is what he has to say to the 
question:



If we are talking, for example, about several IPv6 prefixes that are
learned from muliple ISPs I could suggest that uCPE is transparent in
this case. On the figure below we can see that uCPE connects 2 PHY
ports via virtual Links to the Virtual Ports of VNF. So it is the
VNF(vRouter) that is doing the job. There is example where the
constructor of equipment merges the uCPE NFVIs with router (i find it
as a very particular case).

If we are talking about implementation of babel in the uCPE please
check the figure below. I suppose it is a vRouter that will have this
functionality (not uCPE NFVIs).

P.S. There is a management of NFVIs that maybe could be integrated.
But it is a question if there is an interest to do that.


   ++
   |uCPE|
   ||
   | ++ |
   |   |-|vRouter |-|WAN1
LAN1 --||  | ++ |
   ||  |  | |
   ||  |  | |
LAN2 --||--|  |-|WAN2
   ||   |
   ||   |
LAN3 --||   |
   ||
   ||
   ++

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

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 didn't converge.


Looking at the specification in detail this shouldn't have been a 
surprise to me or anyone else due to the design choices that were made.




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, but 
replies get dropped.


Early drafts of HNCP stated that UDP fragmentation would not be broken 
in the Homenet for the foreseeable future. Well I managed to break that ;)


So this is a known situation.

Changing the MTU on the LAN interfaces of my routers to 1280 brought 
everything back to normal, as expected.


Question: If Homenets are moving to flat L2 meshes over foo, as some 
have said, will this impact HNCP?


The Linux kernel (in Openwrt) can/could easily support PMTUD.

But since the L2 tunnels don't report drops, it makes PMTUD potentially 
challenging for a simple protocol like HNCP.


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?


That wouldn't require any specification change and would allow HNCP to 
work reliably in the presence of tunnels and varying MTU's that don't 
match the local interface MTU.





Second Observation: HNCP packets grow quickly in size, which may become 
a concern for scaling.


Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro).

AFAICS that is 64K per DNCP system, not per node.

Question: Is that correct?

For my 4 node Homenet, HNCP reached 3140 octets, without any 
modifications or additions or long names.


Question: Does the amount of state scale linearly with the number of 
routers?


Question: Is this starting to become a concern?

The limitation for 64K seems to come from the following:

RFC7788
Request Network State TLV (Section 7.1.1): The receiver MUST reply
  with a Network State TLV (Section 7.2.2) and a Node State TLV
  (Section 7.2.3) for each node data used to calculate the network
  state hash.


In the Openwrt implementation, I observe that the requester is 
requesting the node state for all 4 devices in one packet.


I also observe that the reply from the peer contains the entire state of 
the entire Homenet in a single UDP packet (network TLV and node state 
TLV for all 4 routers + optional payload data).


Question: Is that as designed/intended? Is this where the 64K data limit 
comes from in RFC7787?


If this was a design goal to reduce chatiness, and improve convergence 
time, is it possible to implement this differently to reduce packet size 
and/or increase overall TLV data capacity?


Could the requester in step1 request the network status TLV, and the 
peer reply with just the network status TLV and the node TLV's, but 
without the underlying optional HNCP payload data TLV's.


Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this 
from blank node data?


That would give enough information for both nodes to know exactly which 
payload data needed synchronising.


Then as step 2, the requester could individually request the Node TLV 
for each node one per packet, and the peer would reply with the Node TLV 
but this time including the optional data TLV's.


The receiver and peer would both know that HNCP hadn't converged whilst 
waiting for the additional data, and could mark it internally as being 
stale whilst waiting for the additional detailed update.


Question: What would break?

Question: What would need to be amended in the standard RFC? The 
more-HNCP-data-to-come TLV in RFC7788?


Question: Would this tweak increase the ±64K limit of TLV data from 
being per network to being 64K per node? [max UDP packet size for a 
single node TLV + associated payload data]


Question: Is this raw fragmentation by separating DNCP essentials from 
HNCP payload something that the WG would support?


regards,

--
regards,
RayH

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet