Draft: draft-ietf-core-resource-directory

Commentary: The requirement was neither precise with current technology ( requiring base= even for NAT with endpoint - independent filtering ) nor particularly future - proof , and is replaced with a more general statement . While the previous paragraph ( about ephemeral endpoints ) could have been pulled into the new one , I decided against it as it 'd be deeply nested ( " ( e.g. because of using ephemeral ports ( which happens in TCP ) ) " ) and would have borne the risk of implementors overlooking it because of that . Closes : Will merge soon given prior discussion in 
 The current text says " behind a NAT gateway " as one case in which is obligatory . Reviewing ( esp . the part on making base mandatory all the time ) I noticed that this should probably be made more precise ( would have said " NAT other than full cone " , but RFC 4787 has better terminology I 'll yet need to go through ) . 
 other than full cone ? 
 " Full cone " is an older term that AFAICT roughly means that for each inside port there 's an outside port as well ( a rather uncommon setup at least in the simple setups I 've seen ) , but anyway that 's neither the modern term nor the right criterion . The criterion is probably " If a registrant - ep residing on the internal side NAT that does not follow the recommendations of { { ? RFC4787 } } with no stringent filtering ( in particular REQ-1 and the Endpoint - Independent Filtering of REQ-8 ) registers with a Resource Directory on its external side , it MUST NOT register with the RD unless it gives an explicit base address that is usable for the lifetime of the registration ( e.g. using a configured forwarded port ) . " I 've left the general requirement structure as it is , ie . from the normative language , the registrant has to know about the network . This is unreasonable to demand of the software implementation , and will need to be covered by the implementation 's usage instructions or similar ( a la " If you deploy this in behind a NAT , you have to add port forwarding and give the externally visible address in this configuration field ( which becomes base ) , otherwise your endpoint would not be compliant " ) – but that does not change with this edit , and I still think it 's good that way . Reading 4787 I also noted that the lifetime interacts with this as well ; in the same vein as " if in a really - bad NAT then set base " , there 'd be a " if in a regular NAT , need to refresh often enough " ; not sure which line that 'd go into yet . 
 I would be carefull with any of these instructions because they arre very general and new boxes between communicating nodes may appear any time . chrysn schreef op 2019 - 03 - 05 17:16 : Links : [ 1 ] [ 2 ] 
 Valid point ; so can we put that more generally ? Maybe ? Adding " or uses an ephemeral port to register " to the parentheses would even allow this to swallow the paragraph before as well . ( Nitpickers might argue that this needs an exception for link - local addresses , but we 're talking about them in the next paragraph ) .
Paragraph (version A):
If the registrant-ep, located behind a NAT gateway, is
registering with a Resource Directory which is on the network
service side of the NAT gateway, the endpoint MUST use a
persistent port for the outgoing registration in order to
provide the NAT gateway with a valid network address for
replies and incoming requests.
Paragraph (version B):
A registrant that can not be reached by potential lookup
clients at the address it registers from (e.g. because it is
behind some form of Network Address Translation (NAT)) MUST
provide a reachable base address with its registration.