Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This document is UNSAF #39

Open
martinthomson opened this issue Feb 11, 2025 · 3 comments
Open

This document is UNSAF #39

martinthomson opened this issue Feb 11, 2025 · 3 comments

Comments

@martinthomson
Copy link
Member

There's a lot of material in the RFC series about this particular space, yet the document presently mentions none of that work. This is not so much about citing sources as in demonstrating that this isn't re-implementing easily avoidable mistakes and using those resources to make this better.

UNilateral Self-Address Fixing (UNSAF) is a concept in RFC 3424, which goes over some of the important considerations in this area.

Also, this isn't a public address, but a reflexive [transport] address. At least that is the term used by STUN in RFC 5389.

@huitema
Copy link
Collaborator

huitema commented Feb 11, 2025

My personal opinion is that RFC3434 did more harm than good. It seems motivated by two opposite reasons, one not liking NAT as a concept and the other liking NAT as a firewall and not liking applications doing their own thing through them. The bias shows in picking the acronym "UNSAF", which is kind of like attaching a slur to a class of solutions. Note that the recommendation that "Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought." That was written 23 years ago. I wonder what the search of a better architectural solution produced in that interval. The only practical result of RFC 3424 is that for a period all RFCs touching the subject were supposed to add an "IAB considerations" section, and swear on their pinky that they were defining a provisional transition mechanism -- look for example at the 3 pages long "IAB Considerations" section in RFC 5245, which feel like "OK, IAB, here is your pound of flesh". @martinthomson, if you really insist, we could indeed add an "IAB consideration" section that would point to RFC 5245.

That being said, I thought that yes, we should use "reflexive address" throughout the document. I thought we did, but I was probably mistaken.

@martinthomson
Copy link
Member Author

Yeah, I'm not saying that you need to add their silly IAB considerations thing, just to acknowledge that this is what you are doing.

@huitema
Copy link
Collaborator

huitema commented Feb 12, 2025

I just checked. We are indeed using "reflexive address" throughout the document. There is only one leftover "public address" in the whole document, but it is in the abstract. Missed that in the previous pass. Will fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants