Additional links and headings

1 files changed, 7 insertions, 4 deletions

diff --git a/proposals/XXX-udp-app-support.md b/proposals/XXX-udp-app-support.md
index b7dc616..386037f 100644
--- a/proposals/XXX-udp-app-support.md
+++ b/proposals/XXX-udp-app-support.md
@@ -25,7 +25,7 @@ The focus of this work was on a potential way to support unreliable traffic, not
 
 In proposal 100, a Tor *stream* is used for one pairing of local and remote address and port, copying the technique used by Tor for TCP. This works for some types of UDP applications, as we detail below, but for many peer-to-peer use cases it's unhelpful to allocate local ports that can only be used with a single remote peer.
 
-Furthermore, no additional large-message fragmentation protocol is defined, so the MTU in proposal 100 is limited to a one Tor cell. This value we will see is unusably small for most applications.
+Furthermore, no additional large-message fragmentation protocol is defined, so the MTU in proposal 100 is limited to what fits in a single Tor cell. This value we will see is unusably small for most applications.
 
 It's possible these UDP protocol details would have been elaborated during design, but the proposal hit a snag elsewhere:
 there was no agreement on a way to avoid facilitating new attacks against anonymity.
@@ -108,9 +108,10 @@ Every datagram sent or received on the socket may have a different peer address.
 Much of the real-world complexity in UDP applications comes from their strategies to detect and overcome the effects of NAT.
 
 Many RFCs have been written on NAT behavior and NAT traversal strategies.
-RFC4787 and later RFC7857 offer best practices for implementing NAT.
-Carrier-grade NAT requirements are addressed by RFC6888.
-RFC8445 describes the Interactive Connectivity Establishment (ICE) protocol, which has become a common and recommended application-level technique for building peer to peer applications that work through NAT.
+[RFC4787](https://www.rfc-editor.org/rfc/rfc4787.html) and later [RFC7857](https://www.rfc-editor.org/rfc/rfc7857.html) offer best practices for implementing NAT. These are sometimes referred to as the [BEHAVE-WG](https://datatracker.ietf.org/wg/behave/about/) recommendations, based on the "Behavior Engineering for Hindrance Avoidance" working group behind them.
+Carrier-grade NAT requirements are addressed by [RFC6888](https://www.rfc-editor.org/rfc/rfc6888.html).
+
+[RFC8445](https://www.rfc-editor.org/rfc/rfc8445.html) describes the Interactive Connectivity Establishment (ICE) protocol, which has become a common and recommended application-level technique for building peer-to-peer applications that work through NAT.
 
 There are multiple fundamental technical issues that NAT presents:
 
@@ -135,6 +136,8 @@ For example, in analyzing Tor as a type of carrier-grade NAT, we may consider th
 Tor by necessity must carefully limit how predictable these mappings can ever be, to preserve its anonymity properties.
 A literal application of RFC6888 would find trouble in REQ-2 and REQ-9, as well as the various per-subscriber limiting requirements.
 
+### Mapping and Filtering Behaviors
+
 RFC4787 defines a framework for understanding the behavior of NAT by analyzing both its "mapping" and "filtering" behavior separately.
 Mappings are the NAT's unit of state tracking.
 Filters are layered on top of mappings, potentially rejecting incoming datagrams that don't match an already-expected address.