On Mar 2, 2019, at 8:50 PM, Juliusz Chroboczek <j...@irif.fr> wrote:
> That's an property of the hnetd implementation, not a feature of the
> protocol (and it doesn't apply to shncpd). See RFC 7788 Section 6.5.
The text:
An HNCP router MUST create a private IPv4 prefix [RFC1918
<https://tools.ietf.org/html/rfc1918>]
whenever it wishes to provide IPv4 Internet connectivity to the
network and no other private IPv4 prefix with Internet
connectivity currently exists. It MAY also enable local IPv4
connectivity by creating a private IPv4 prefix if no IPv4 prefix
exists but MUST NOT do so otherwise.
So it does allow the implementation to use use RFC1918 addresses internally
when there is no upstream address, but it really does seem to be saying that’s
not necessary. Better advice would be that if an IPv4 address is ever
obtained externally, that internal RFC1918 addressing should remain available
until some substantial amount of time has passed. Right now this behavior is
optional.
>> This is one of the reasons that I would like us to get together and hack on
>> this at the hackathon:
>
> It should be an easy fix, feel free to go ahead.
The point of soliciting participation at hackathon is for us to gain collective
experience on the easy or difficulty of deploying homenet in practice. It’s
all very well and good to have implementations, but if nobody is able to use
them, this isn’t really what we want when we talk about having interoperating
implementations. This is particularly true when the goal of a body of work is
automatic operation (as in ops), as opposed to mere protocol interoperation.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
