RFC 3795
Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents
RFC 3795 🎀 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents
Title block, bestie 💖
- Network Working Group, Request for Comments: 3795 📄
- Authors: R. Sofia and P. Nesser, II, from Nesser & Nesser Consulting ✨
- Category: Informational 🧚
- Date: June 2004 🌸
- Obsoletes / Updates: The title block doesn't list any RFCs as obsoleted or updated. 🙈
Status of This Memo
okay so this memo is just here to inform the Internet community 💅 It does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🦋
Copyright Notice
The copyright line is Copyright (C) The Internet Society (2004). 🎀
Abstract
okay this one is giving main character energy 👑 The doc looks at the IPv4 addressing dependencies that show up in specs, so we can figure out the steps needed to redesign and reimplement them to be network address independent. Or at the very least, so they can dually support IPv4 and IPv6. 🔥
Getting there takes a few interim steps, and one of them is evolving the current IPv4-dependent specs into a format that doesn't care what kind of IP addressing scheme is in use. So the hope is that specs get redesigned and reimplemented to be network address independent, or at least to dually support IPv4 and IPv6 ✨
To make that happen, we have to survey and document every IPv4 dependency that current standards (Full, Draft, and Proposed) and Experimental RFCs have. So this doc describes the IPv4 addressing dependencies that deployed IETF Application Area documented Standards might run into 💜
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 501. Introduction ✨
so the big picture: the full documentation of IPv4 address usage in currently deployed IETF documented standards got split into seven documents, one for each main IETF area: Applications, Internet, Operations and Management, Routing, Sub-IP, and Transport 🧚 For the general overview, the methodology, and the historical perspective, check [1]. This doc is one of the seven blocks, and its scope is just surveying the possible IPv4 dependencies in IETF Application Area documented Standards 💅
2. Document Organization
okay here's how the rest of this is laid out 🗺️ Sections 3, 4, 5, and 6 are the raw analysis of Internet Standards [2], and they go in this order: Full Standards, Draft Standards, Proposed Standards, and Experimental RFCs 🌈 Within each section, standards are analyzed by RFC number, in sequential order, from RFC 1 to RFC 3200.
There are exceptions, though. A few RFCs above RFC 3200 got included too, because they obsoleted RFCs within the 1-3200 range 🙈 The comments for each RFC are raw, meaning each RFC is just analyzed for possible IPv4 addressing dependencies, no fluff. And finally, Section 7 gives a global overview of everything in the earlier sections and suggests possible future steps 🔥
3. Full Standards
Full Standards are the top of the ladder 🪜 They've hit the highest level of maturity on the standards track process. People call them "Standards" for short, and they're fully technical, mature specs that are widely implemented and used all over the Internet 👑
3.1. RFC854: Telnet Protocol Specifications
Good news, no drama here 🌸 There are no IPv4 dependencies in this specification.
3.2. RFC 855: Telnet Option Specifications
Clean slate ✨ There are no IPv4 dependencies in this specification.
3.3. RFC 856: Binary Transmission Telnet Option
Still no IPv4 dependencies in this one 💖 There are no IPv4 dependencies in this specification.
3.4. RFC 857: Echo Telnet Option
Nothing to see here, bestie 🫶 There are no IPv4 dependencies in this specification.
3.5. RFC 858: Suppress Go Ahead Telnet Option
Still clean 💅 There are no IPv4 dependencies in this specification.
3.6. RFC 859: Status Telnet Option
Zero IPv4 drama 🦋 There are no IPv4 dependencies in this specification.
3.7. RFC 860: Timing Mark Telnet Option
Slay, no dependencies 💜 There are no IPv4 dependencies in this specification.
3.8. RFC 861: Extended Options List Telnet Option
Iconic and IPv4-free 👑 There are no IPv4 dependencies in this specification.
3.9. RFC 862: Echo Protocol
Literally nothing IPv4 here 🌈 There are no IPv4 dependencies in this specification.
3.10. RFC 863: Discard Protocol
Zero IPv4 vibes 🫧 There are no IPv4 dependencies in this specification.
3.11. RFC 864: Character Generator Protocol
Still no IPv4 dependencies 🍓 There are no IPv4 dependencies in this specification.
3.12. RFC 865: Quote of the Day Protocol
Quote of the day: no IPv4 dependencies 💅 There are no IPv4 dependencies in this specification.
3.13. RFC 866: Active Users Protocol
Everyone's active and none of them are IPv4-dependent 🧚 There are no IPv4 dependencies in this specification.
3.14. RFC 867: Daytime Protocol
It's giving clean 🌸 There are no IPv4 dependencies in this specification.
3.15. RFC 868: Time Server Protocol
Time for another no-IPv4 entry ⏰ There are no IPv4 dependencies in this specification.
3.16. RFC 959: File Transfer Protocol
okay, this one is actually messy 😭 Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes the port command using the following format:
"A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host
address."This is a clear reference to an IPv4 address 🚩 In sections 4.2.1 and 4.2.2, on reply codes, the code:
"227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"also needs to be reworked for IPv6 addressing 🛠️ Also, Section 5.3.2 (FTP COMMAND ARGUMENTS) contains:
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"This needs to be solved to transition to IPv6 💖
3.17. RFC 1350: Trivial File Transfer Protocol
Simple and dependency-free 🫶 There are no IPv4 dependencies in this specification.
3.18. RFC 1870: SMTP Service Extension for Message Size Declaration
Still good 💅 There are no IPv4 dependencies in this specification.
3.19. RFC 1939: Post Office Protocol - Version 3
POP3 keeping it clean 📬 There are no IPv4 dependencies in this specification.
3.20. RFC 2920: SMTP Service Extension for Command Pipelining
Pipelined and IPv4-free 🦋 There are no IPv4 dependencies in this specification.
4. Draft Standards ✨
Draft Standards are the second-to-top level of the standards track 🪜 They're considered final specs, and the only changes they get are ones meant to fix specific problems that were found. A spec only counts as a Draft Standard if there are at least two known independent and interoperable implementations. So Draft Standards are usually pretty mature and widely used 💜
4.1. RFC 954: NICNAME/WHOIS
No IPv4 dependencies here 🌸 There are no IPv4 dependencies in this specification.
4.2. RFC 1184: Telnet Linemode Option
Still nothing IPv4 🫧 There are no IPv4 dependencies in this specification.
4.3. RFC 1288: The Finger User Information Protocol
Finger-clean, bestie 🍓 There are no IPv4 dependencies in this specification.
4.4. RFC 1305: Network Time Protocol (Version 3) Specification, Implementation
okay this one is the real tea ☕ NTP has a lot of IPv4 stuff going on 👀 Section 3.2.1 (Common Variables) provides the following variable definitions:
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
(peer.peerport, pkt.peerport): These are the 32-bit Internet
address and 16-bit port number of the peer.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port
(peer.hostport, pkt.hostport): These are the 32-bit Internet
address and 16-bit port number of the host. They are included
among the state variables to support multi-homing."Section 3.4.3 (Receive Procedure) defines the following procedure:
"The source and destination Internet addresses and ports in the IP
and UDP headers are matched to the correct peer. If there is no
match a new instantiation of the protocol machine is created and
the association mobilized."Section 3.6 (Access Control Issues) proposes a simple authentication scheme in the following way:
"If a more comprehensive trust model is required, the design can
be based on an access-control list with each entry consisting of a
32-bit Internet address, 32-bit mask and three-bit mode. If the
logical AND of the source address (pkt.peeraddr) and the mask in
an entry matches the corresponding address in the entry and the
mode (pkt.mode) matches the mode in the entry, the access is
allowed; otherwise an ICMP error message is returned to the
requestor. Through appropriate choice of mask, it is possible to
restrict requests by mode to individual addresses, a particular
subnet or net addresses, or have no restriction at all. The
access-control list would then serve as a filter controlling which
peers could create associations."Appendix B Section 3 (B.3 Commands) defines the following command:
"Set Trap Address/Port (6): The command association identifier,
status and data fields are ignored. The address and port number
for subsequent trap messages are taken from the source address and
port of the control message itself. The initial trap counter for
trap response messages is taken from the sequence field of the
command. The response association identifier, status and data
fields are not significant. Implementations should include sanity
timeouts which prevent trap transmissions if the monitoring
program does not renew this information after a lengthy interval."The tea is spilled 🫖✨ The address clearly assumes the IPv4 version 🙈 Also, there are tons of places in sample code and algorithms that use the variables above. It seems like there's no reason to modify the actual protocol itself. A small number of textual changes, plus an update to implementations so they understand both IPv4 and IPv6 addresses, will be enough to get an NTP version that works on both network layer protocols 🎀
4.5. RFC 1575: An Echo Function for CLNP (ISO 8473)
Zero IPv4 energy here 🌊 There are no IPv4 dependencies in this specification.
4.6. RFC 1652: SMTP Service Extension for 8bit-MIME Transport
Clean and simple 💌 There are no IPv4 dependencies in this specification.
4.7. RFC 1832: eXternal Data Representation Standard
Data representation, no IPv4 included 🧸 There are no IPv4 dependencies in this specification.
4.8. RFC 2045: Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies
MIME part one, IPv4-free 📎 There are no IPv4 dependencies in this specification.
4.9. RFC 2046: MIME, Part Two: Media Types
Media types, zero IPv4 drama 🎞️ There are no IPv4 dependencies in this specification.
4.10. RFC 2047: MIME, Part Three: Message Header Extensions for Non-ASCII Text
Non-ASCII text, still no IPv4 🌍 There are no IPv4 dependencies in this specification.
4.11. RFC 2049: MIME Part Five: Conformance Criteria and Examples
Conformance vibes, no IPv4 attached ✅ There are no IPv4 dependencies in this specification.
4.12. RFC 2279: UTF-8, a transformation format of ISO 10646
UTF-8 is giving clean 💖 There are no IPv4 dependencies in this specification.
Part 1 of 8 done, bestie 🦋 Section 5 (Proposed Standards) is up next 💜
4.13. RFC 2347: TFTP Option Extension 💖
Good news bestie, this one has zero IPv4 dependencies 💅 nothing to stress about here ✨
4.14. RFC 2348: TFTP Blocksize Option 🎀
The spec has an example that's giving main character energy, so here it is exactly as written:
"For example:
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary)
transfer mode, with a block size of 1428 octets (Ethernet MTU,
less the TFTP, UDP and IP header lengths)."Okay so this example would totally not work with IPv6 header sizes 🙈 but no biggie, since larger blocksizes are also available 🦋
4.15. RFC 2349: TFTP Timeout Interval and Transfer Size Options 🌸
No IPv4 dependencies in this one either, so it's a clean pass ✨
4.16. RFC 2355: TN3270 Enhancements 🧚
Zero IPv4 dependencies here, bestie 💜
4.17. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax 🌈
Section 3.2.2. (Server-based Naming Authority) says:
"The host is a domain name of a network host, or its IPv4 address
as a set of four decimal digit groups separated by ".". Literal
IPv6 addresses are not supported.
...
Note: A suitable representation for including a literal IPv6
address as the host part of a URL is desired, but has not yet been
determined or implemented in practice."So basically, literal IPv6 addresses weren't supported yet, and the spec was still hunting for a good way to write them as the host part of a URL. Not iconic 😭
4.18. RFC 2616: Hypertext Transfer Protocol HTTP/1.1 🍓
Section 3.2.2 (http URL) gives the scheme-specific syntax and semantics for http URLs. Here's the grammar and the important bits:
"The "http" scheme is used to locate network resources via the
HTTP protocol. This section defines the scheme-specific syntax
and semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The
semantics are that the identified resource is located at the
server listening for TCP connections on that port of that host,
and the Request-URI for the resource is abs_path (section 5.1.2).
The use of IP addresses in URLs SHOULD be avoided whenever
possible (see RFC 1900 [24])."The vibe is that the text is version neutral, but it's unclear whether individual implementations will support IPv6 addresses 🤔 The ":" separator used in IPv6 addresses can cause misinterpretation when parsing URIs, which is a whole mess. There are also other discussions about a server recognising its own IP addresses, spoofing DNS/IP address combinations, and multiple HTTP servers running on a single IP interface. Again, the text is version neutral, but these are clearly implementation issues 💅
4.19. RFC 3191: Minimal GSTN address format in Internet Mail 🦋
Nothing IPv4-flavoured in this one, so we're good ✨
4.20. RFC 3192: Minimal FAX address format in Internet Mail 📠
No IPv4 dependencies here, bestie 💖
4.21. RFC 3282: Content Language Headers 🌷
Zero IPv4 dependencies, so it's a yes from me 🫶
4.22. RFC 3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications 📬
This one is IPv4-free too 💜
4.23. RFC 3462: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages 📨
Also no IPv4 dependencies. Clean as a whistle 🧼
4.24. RFC 3463: Enhanced Mail System Status Codes 🔥
No IPv4 dependencies in this spec either ✨
4.25. RFC 3464: An Extensible Message Format for Delivery Status Notifications 🎀
And again, nothing IPv4-related here 💅
5. Proposed Standards 👑
Okay so Proposed Standards are the initial, first-level documents in the IETF standards track 🦋 They're stable in terms of design, but they don't need implementations to exist yet. Sometimes these specs are just put forward as solid technical ideas for the Internet community to analyse 🧠 and they never actually get implemented or moved forward in the standards process 😭
5.1. RFC 698: Telnet extended ASCII option 🌸
No IPv4 dependencies, bestie ✨
5.2. RFC 726: Remote Controlled Transmission and Echoing Telnet option 💜
Zero IPv4 dependencies here 🧚
5.3. RFC 727: Telnet logout option 🌈
Nothing IPv4-related in this one 💖
5.4. RFC 735: Revised Telnet byte macro option 🍓
No IPv4 dependencies to see here 🫶
5.5. RFC 736: Telnet SUPDUP option 🔥
This one has no IPv4 dependencies either 💅
5.6. RFC 749: Telnet SUPDUP-Output option 🌷
Zero IPv4 dependencies, no cap 💖
5.7. RFC 779: Telnet send-location option 🦋
No IPv4 dependencies in this spec ✨
5.8. RFC 885: Telnet end of record option 💜
Also no IPv4 dependencies 🎀
5.9. RFC 927: TACACS user identification Telnet option 🧚
No IPv4 dependencies here, bestie 🫶
5.10. RFC 933: Output marking Telnet option 🌸
Nothing IPv4-flavoured in this one 💅
5.11. RFC 946: Telnet terminal location number option 📍
Okay so this one is giving IPv4 vibes. Section "TTYLOC Number" states:
"The TTYLOC number is a 64-bit number composed of two (2) 32-bit
numbers: The 32-bit official ARPA Internet host address (may be
any one of the addresses for multi-homed hosts) and a 32-bit
number representing the terminal on the specified host. The host
address of [0.0.0.0] is defined to be "unknown", the terminal
number of FFFFFFFF (hex, r or-1 in decimal) is defined to be
"unknown" and the terminal number of FFFFFFFE (hex, or -2 in
decimal) is defined to be "detached" for processes that are not
attached to a terminal."The clear references to 32-bit numbers and to literal addresses like [0.0.0.0] are obviously an IPv4 dependency 😭 so the text above needs to be rewritten.
5.12. RFC 977: Network News Transfer Protocol 🗞️
No IPv4 dependencies, so we're safe ✨
5.13. RFC 1041: Telnet 3270 regime option 🌈
Zero IPv4 dependencies here 💖
5.14. RFC 1043: Telnet Data Entry Terminal option: DODIIS implementation 🍓
No IPv4 dependencies in this spec 🫶
5.15. RFC 1053: Telnet X.3 PAD option 🔥
Nothing IPv4-related, bestie 💅
5.16. RFC 1073: Telnet window size option 🌷
No IPv4 dependencies to worry about 💜
5.17. RFC 1079: Telnet terminal speed option 🦋
Zero IPv4 dependencies, slay ✨
5.18. RFC 1091: Telnet terminal-type option 🎀
Also no IPv4 dependencies 🧚
5.19. RFC 1096: Telnet X display location option 🌸
No IPv4 dependencies here either 💖
5.20. RFC 1274: The COSINE and Internet X.500 Schema 📚
Nothing IPv4-flavoured in this one 🫶
5.21. RFC 1276: Replication and Distributed Operations extensions to provide an Internet Directory using X.500 🗂️
No IPv4 dependencies, bestie ✨
5.22. RFC 1314: A File Format for the Exchange of Images in the Internet 🖼️
Zero IPv4 dependencies, so this one passes 💅
5.23. RFC 1328: X.400 1988 to 1984 downgrading 🌈
No IPv4 dependencies here 💜
5.24. RFC 1372: Telnet Remote Flow Control Option 🍓
Nothing IPv4-related in this spec 🦋
5.25. RFC 1415: FTP-FTAM Gateway Specification 🌉
Okay so this one defines a gateway between FTAM and FTP, which means any possible IPv4 dependencies come from FTP. We already looked at FTP above, in section 3.16, so we're covered 🫶
5.26. RFC 1494: Equivalences between 1988 X.400 and RFC-822 Message Bodies 📧
No IPv4 dependencies, bestie 💖
5.27. RFC 1496: Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages 📨
Zero IPv4 dependencies here ✨
5.28. RFC 1502: X.400 Use of Extended Character Sets 🔤
Nothing IPv4-flavoured in this one 🌸
5.29. RFC 1572: Telnet Environment Option 🌿
No IPv4 dependencies, so it's a pass 💅
5.30. RFC 1648: Postmaster Convention for X.400 Operations 📮
Also no IPv4 dependencies 🧚
5.31. RFC 1738: Uniform Resource Locators 🔗
Section 3.1. (Common Internet Scheme Syntax) says:
"host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by ".".
Fully qualified domain names take the form as described in
Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [4]: a
sequence of domain labels separated by ".", each domain label
starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses."Clearly, that's only valid when using IPv4 addresses 😭 Later, in Section 5. (BNF for specific URL schemes), we get this:
"; URL schemeparts for ip based protocols:
ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"So yeah, this also has implications for IP-version neutrality 🫠
5.32. RFC 1740: MIME Encapsulation of Macintosh Files - MacMIME 🍎
No IPv4 dependencies here, bestie ✨
5.33. RFC 1767: MIME Encapsulation of EDI Objects 📦
Zero IPv4 dependencies 💜
5.34. RFC 1808: Relative Uniform Resource Locators 🧭
No IPv4 dependencies in this spec 🦋
5.35. RFC 1835: Architecture of the WHOIS++ service 🔍
Nothing IPv4-flavoured in this one 🌸
5.36. RFC 1913: Architecture of the WHOIS++ Index Service 🗃️
Section 6.5. (Query referral) makes this statement:
"When referrals are included in the body of a response to a query,
each referral is listed in a separate SERVER-TO-ASK block as shown
below.
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number"The syntax used doesn't have specific IPv4 dependencies 💅 but implementations should be modified to check, in incoming packets, which IP version the original request used, so they can work out whether or not to return an IPv6 address 🧠 That's the vibe for this one, bestie 🫶
5.37. RFC 1914: How to Interact with a Whois++ Mesh 🦋
okay so Section 4 (Caching) says this, and it's giving a whole vibe 💅:
"A client can cache all information it gets from a server for some
time. For example records, IP-addresses of Whois++ servers, the
Directory of Services server etc.
A client can itself choose for how long it should cache the
information.
The IP-address of the Directory of Services server might not
change for a day or two, and neither might any other information."Then subsection 4.1 (Caching a Whois++ servers hostname) is where it gets spicy ✨:
"An example of cached information that might change is the cached
hostname, IP-address and portnumber which a client gets back in a
servers-to-ask response. That information is cached in the server
since the last poll, which might occurred several weeks ago.
Therefore, when such a connection fails, the client should fall
back to use the serverhandle instead, which means that it contacts
the Directory of Services server and queries for a server with
that serverhandle. By doing this, the client should always get
the last known hostname.
An algorithm for this might be:
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server"No IPv4-specific syntax shows up in that paragraph, so IPv6 compliance is left up to each implementation 🫶
5.38. RFC 1985: SMTP Service Extension for Remote Message Queue Starting 💌
No IPv4 dependencies in this one, bestie. Nothing to see here ✨
5.39. RFC 2017: Definition of the URL MIME External-Body Access-Type 🌸
No IPv4 dependencies in this one either 💖
5.40. RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes 🧚
Clean. No IPv4 dependencies here 🫶
5.41. RFC 2056: Uniform Resource Locators for Z39.50 📚
No IPv4 dependencies in this specification 🦋
5.42. RFC 2077: The Model Primary Content Type for Multipurpose Internet Mail Extensions 💅
No IPv4 dependencies, periodt ✨
5.43. RFC 2079: Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) 🌈
No IPv4 dependencies here 💜
5.44. RFC 2086: IMAP4 ACL extension 🔐
No IPv4 dependencies, so we're good 💖
5.45. RFC 2087: IMAP4 QUOTA extension 🍓
No IPv4 dependencies in this one 🎀
5.46. RFC 2088: IMAP4 non-synchronizing literals ✨
No IPv4 dependencies in this specification 🌸
5.47. RFC 2122: VEMMI URL Specification 🧚
Section 3 (Description of the VEMMI scheme) says:
"The VEMMI URL scheme is used to designate multimedia interactive
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
709).
A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value>
as specified in Section 3.1. of RFC 1738. If :<port> is omitted,
the port defaults to 575 (client software may choose to ignore the
optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted."The IPv4 drama here is that the <host> portion could contain an IPv4 address, as defined in RFC 1738 (see section 5.31. above). Once that's sorted out for RFC 1738, this issue gets fixed automatically 🫶
5.48. RFC 2141: URN Syntax 🌈
No IPv4 dependencies in this specification 💅
5.49. RFC 2142: Mailbox Names for Common Services, Roles and Functions 📬
No IPv4 dependencies, bestie ✨
5.50. RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME 🦋
No IPv4 dependencies in this specification 💖
5.51. RFC 2157: Mapping between X.400 and RFC-822/MIME Message Bodies 🎀
No IPv4 dependencies here 🌸
5.52. RFC 2158: X.400 Image Body Parts 🖼️
No IPv4 dependencies in this one 💜
5.53. RFC 2159: A MIME Body Part for FAX 📠
No IPv4 dependencies, so it's a yes from me 🍓
5.54. RFC 2160: Carrying PostScript in X.400 and MIME 📄
No IPv4 dependencies in this specification ✨
5.55. RFC 2163: Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping 🌐
No IPv4 dependencies here 🫶
5.56. RFC 2164: Use of an X.500/LDAP directory to support MIXER address mapping 🗂️
No IPv4 dependencies, periodt 💅
5.57. RFC 2165: Service Location Protocol 🧭
Okay, this one has a lot going on 😭
Section 7. (Service Type Request Message Format) and Section 9. (Service Registration Message Format) both have an 80-bit field from addr-spec (see below), and that field can't hold IPv6 addresses 💀
Section 20.1. (Previous Responders' Address Specification) says:
"The previous responders' Address Specification is specified as
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>
i.e., a list separated by commas with no intervening white space.
The Address Specification is the address of the Directory Agent or
Service Agent which supplied the previous response. The format
for Address Specifications in Service Location is defined in
section 20.4. The comma delimiter is required between each
<addr-spec>. The use of dotted decimal IP address notation should
only be used in environments which have no Domain Name Service."Later, Section 20.4. (Address Specification in Service Location) brings up addr-spec again:
"The address specification used in Service Location is:
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
When no Domain Name Server is available, SAs and DAs must use
dotted decimal conventions for IP addresses. Otherwise, it is
preferable to use a fully qualified domain name wherever possible
as renumbering of host addresses will make IP addresses invalid
over time."Section 21. (Protocol Requirements) sets out the requirements for each element of the protocol. There are several IPv4 statements in there, but the syntax is neutral enough to work for IPv6 too 🫶
Section 22. (Configurable Parameters and Default Values) says:
"There are several configuration parameters for Service Location.
Default values are chosen to allow protocol operation without the
need for selection of these configuration parameters, but other
values may be selected by the site administrator. The
configurable parameters will allow an implementation of Service
Location to be more useful in a variety of scenarios.
Multicast vs. Broadcast
All Service Location entities must use multicast by default.
The ability to use broadcast messages must be configurable
for UAs and SAs. Broadcast messages are to be used in
environments where not all Service Location entities have
hardware or software which supports multicast.
Multicast Radius
Multicast requests should be sent to all subnets in a site.
The default multicast radius for a site is 32. This value
must be configurable. The value for the site's multicast
TTL may be obtained from DHCP using an option which is
currently unassigned."Once again, nothing here rules out IPv6 🦋
Section 23. (Non-configurable Parameters) says:
"IP Port number for unicast requests to Directory Agents:
UDP and TCP Port Number: 427
Multicast Addresses
Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service
Specific Discovery Multicast Addresses will be assigned by IANA."So yeah, those statements clearly need specs for equivalent IPv6 multicast addresses to do the same job 😭
5.58. RFC 2177: IMAP4 IDLE command ⏳
No IPv4 dependencies in this specification 💖
5.59. RFC 2183: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field 🎀
No IPv4 dependencies here 🌸
5.60. RFC 2192: IMAP URL Scheme 🔗
This one has IPv4 dependencies. RFC 1738 is integral to the document, and RFC 1738 isn't IPv6 aware 💀
5.61. RFC 2193: IMAP4 Mailbox Referrals 📨
Section 6. (Formal Syntax) has this statement:
referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[RFC-1738] for <url> definitionThat creates dependencies on the RFC 1738 URL definitions, which we already covered in section 5.31 ✨
5.62. RFC 2218: A Common Schema for the Internet White Pages Service 📇
No IPv4 dependencies in this specification 🫶
5.63. RFC 2221: IMAP4 Login Referrals 🔑
Section 4.1. (LOGIN and AUTHENTICATE Referrals) gives this example:
Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2.Even though "user@SERVER2" shows up a lot, there's no spec for the format of "SERVER2". So it's up to each implementation to decide what counts as an acceptable hostname. That may or may not include explicit IPv6 addresses 🤷♀️
5.64. RFC 2227: Simple Hit-Metering and Usage-Limiting for HTTP 📊
No IPv4 dependencies in this specification 💅
5.65. RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations 🌍
No IPv4 dependencies, bestie ✨
5.66. RFC 2234: Augmented BNF for Syntax Specifications: ABNF 🧩
No IPv4 dependencies in this specification 🦋
5.67. RFC 2244: Application Configuration Access Protocol ⚙️
No IPv4 dependencies here 💖
5.68. RFC 2247: Using Domains in LDAP/X.500 Distinguished Names 🌸
No IPv4 dependencies, so we're all good 🫶
5.69. RFC 2251: Lightweight Directory Access Protocol (v3) 📒
No IPv4 dependencies in this specification 🎀
5.70. RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions 📖
No IPv4 dependencies, periodt 💅
5.71. RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names 🌸
okay so Section 7.1 (Disclosure) is basically saying that Distinguished Names are usually full of descriptive info about whatever they name 🫶 and that thing could be a person, an org, a device, or any real-world object. The stuff that usually shows up includes:
- the common name of the object (basically a person's full name) 🧑
- an email or TCP/IP address 📧
- its physical location (country, locality, city, street address) 🗺️
- organizational attributes (like department name or affiliation) 🏢
This section needs the caveat "Without putting any limitations on the version of the IP address.", so nobody gets confused about which IP version is meant 💅
5.72. RFC 2254: The String Representation of LDAP Search Filters ✨
No IPv4 dependencies in this one, bestie. Zero. Nada. 🦋
5.73. RFC 2255: The LDAP URL Format 🎀
This one does have IPv4 dependencies, and the reason is kinda sad 😭 It leans on RFC 1738, which is basically integral to the doc, and RFC 1738 isn't IPv6 aware.
5.74. RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 💜
No IPv4 dependencies here either. Clean girl energy ✨
5.75. RFC 2293: Representing Tables and Subtrees in the X.500 Directory 🧚
No IPv4 dependencies, periodt 💖
5.76. RFC 2294: Representing the O/R Address hierarchy in the X.500 Directory Information Tree 🌈
Also zero IPv4 dependencies. Iconic consistency 👑
5.77. RFC 2298: An Extensible Message Format for Message Disposition Notifications 📬
No IPv4 dependencies in this spec ⭐
5.78. RFC 2301: File Format for Internet Fax 📠
No IPv4 dependencies, no cap 🧢
5.79. RFC 2305: A Simple Mode of Facsimile Using Internet Mail 💌
No IPv4 dependencies. Simple and slay 🍓
5.80. RFC 2334: Server Cache Synchronization Protocol 🔥
okay this one's giving "example that's doing a lot of work" 🤓 In Appendix B, part 2.0.1 (Mandatory Common Part), the Cache Key gets defined like this. It's a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wants to sync with its peers for a given "Protocol ID/Server Group ID" pair. It's usually a small opaque byte string that SCSP links to a piece of data in a cache. For example, an originator might give a particular 4 byte string to the binding of an IP address with an ATM address. Generally, the originating server of a CSA record is in charge of making a Cache Key for every bit of data it originates and wants to sync with its peers in the SG 💅
The thing is, that statement is only an example. So any possible IPv4 dependency of this protocol is an implementation issue, not something the spec itself decides 🫶
5.81. RFC 2342: IMAP4 Namespace 💜
No IPv4 dependencies in this spec. Pure vibes 🌸
5.82. RFC 2359: IMAP4 UIDPLUS extension ✨
No IPv4 dependencies, bestie 🦋
5.83. RFC 2368: The mailto URL scheme 📧
No IPv4 dependencies. Main character energy 👑
5.84. RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields 🌈
No IPv4 dependencies here either 🎀
5.85. RFC 2371: Transaction Internet Protocol Version 3.0 🔥
Okay so this one has a few spots that need some serious glow-up 😭
In Section 7 (TIP Transaction Manager Identification and Connection Establishment), the <hostport> component is defined like this:
<host>[:<port>]Here <host> can be either a <dns name> or an <ip address>, and <port> is a decimal number that tells you which port the transaction manager (or proxy) is listening on for requests to set up TIP connections. If the port is left out, the standard TIP port number (3372) gets used. A <dns name> is just a normal name that the domain name service will accept, and it has to be specific enough to be useful to whoever gets the command. An <ip address> is an IP address in the usual form, which is four decimal numbers separated by periods 🌸
This section has to be rewritten so it's IP-version neutral 🦋 Besides adding a reference to the use of IPv6 addresses, the "host" field should only be defined as a "dns name". But if literal IP addresses are going to be included, the format from RFC 2372 has to be followed 💅
Later on, in Section 8 (TIP Uniform Resource Locators), a TIP URL looks like this:
tip://<transaction manager address>?<transaction string>Here <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above), and <transaction string> is a transaction identifier that can come in one of two forms, standard or non-standard 🧚
i. A standard one looks like this:
"urn:" <NID> ":" <NSS>This one is supposed to follow the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141. <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID decides how the Namespace Specific String gets read, and the NSS is a sequence of characters that represents a transaction identifier (as defined by <NID>). The rules for what goes in these fields (valid characters, encoding, and so on) are specified by [6] 🫶
This format can be used to express global transaction identifiers using standard representations. Examples for <NID> might be <iso> or <xopen>, like this:
tip://123.123.123.123/?urn:xopen:xidAlso, Namespace IDs need registration, so check [7] for how to do that 📝
There are other references in Section 8 about using literal IP addresses 😭 So that section needs a rewrite too, and you should be extra careful to avoid using IP literal addresses at all (IPv4 or IPv6). But if one does get used as an example, the format from RFC 2732 has to be respected 💖
Heads up: the rewrite is mandatory, not optional, so don't skip the IP-neutral fixes in Sections 7 and 8!
5.86. RFC 2384: POP URL Scheme 🌈
In Section 3 (POP Scheme), a POP URL is said to be of the general form:
pop://<user>;auth=<auth>@<host>:<port>Here <user>, <host>, and <port> are as defined in RFC 1738, and some or all of the elements can be left out, except for pop:// and <host> 🎀
RFC 1738 (see section 5.31 for the tea) has a potential IPv4 limitation, so RFC 2384 will only be IPv6 compliant once RFC 1738 gets properly updated 😭
5.87. RFC 2387: The MIME Multipart/Related Content-type 💜
No IPv4 dependencies here, slay 💅
5.88. RFC 2388: Returning Values from Forms: multipart/form-data 🍓
No IPv4 dependencies. Forms are giving no drama 🦋
5.89. RFC 2389: Feature negotiation mechanism for the File Transfer Protocol ⭐
No IPv4 dependencies, bestie ✨
5.90. RFC 2392: Content-ID and Message-ID Uniform Resource Locators (CIDMID-URL) 🔥
No IPv4 dependencies in this spec 🌸
5.91. RFC 2397: The "data" URL scheme 🧚
No IPv4 dependencies, iconic 👑
5.92. RFC 2421: Voice Profile for Internet Mail - version 2 🎀
No IPv4 dependencies here, no cap 🧢
5.93. RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration 💖
No IPv4 dependencies. Crisp and clear 📞
5.94. RFC 2423: VPIM Voice Message MIME Sub-type Registration 🌈
No IPv4 dependencies in this one 💅
5.95. RFC 2424: Content Duration MIME Header Definition ⭐
No IPv4 dependencies, periodt ✨
5.96. RFC 2425: A MIME Content-Type for Directory Information 🦋
No IPv4 dependencies here 🫶
5.97. RFC 2426: vCard MIME Directory Profile 💜
No IPv4 dependencies, the vCard is giving clean 💌
5.98. RFC 2428: FTP Extensions for IPv6 and NATs 🌸
This RFC documents an IPv6 extension, so it isn't really part of the IPv4 conversation we're having here 🧚
5.99. RFC 2445: Internet Calendaring and Scheduling Core Object Specification (iCalendar) 📅
Okay so Section 4.8.4.7 (Unique Identifier) defines the UID property. Here are the labelled bits that matter most:
Property Name: UID
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property MUST be specified in the "VEVENT",
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.The Description is where it gets spicy 🔥 The UID itself MUST be a globally unique identifier, and whoever generates it MUST guarantee that it's unique. There are a bunch of algorithms that can get you there 🧠 The identifier is RECOMMENDED to use the same syntax as the [RFC 822] addr-spec. A good way to make it unique is to put the domain name, or a domain literal IP address, of the host where it was created on the right side of the "@". On the left side, you put the current calendar date and time of day (formatted as a DATE-TIME value) plus some other currently unique, maybe sequential, identifier from the system, like a process id number. Using a date/time on the left and a domain name or domain literal on the right makes uniqueness guaranteeable, since no two hosts should be using the same domain name or IP address at the same time 🫶 Other algorithms will work too, but it's RECOMMENDED that the right side has some domain identifier (either the host itself or something else), so the generator can guarantee the left side is unique within that domain 💖
So even though this doesn't explicitly mention IPv4 addresses, it does explicitly use RFC 822, which got obsoleted by RFC 2822. To become IPv6 compliant, it should follow the guidelines for RFC 2822 (see section 5.129) 🌈
5.100. RFC 2446: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries 🎀
No IPv4 dependencies, bestie 📆
5.101. RFC 2447: iCalendar Message-Based Interoperability Protocol (iMIP) 💌
No IPv4 dependencies here 🦋
5.102. RFC 2449: POP3 Extension Mechanism ✨
No IPv4 dependencies in this spec 🧚
5.103. RFC 2476: Message Submission 🔥
This RFC has a bunch of discussions about using IP Address authorization schemes, but it doesn't limit those addresses to IPv4 💅 So it's giving IP-version neutral vibes, which is a W 🫶
5.104. RFC 2480: Gateways and MIME Security Multiparts 💜
No IPv4 dependencies, slay ⭐
5.105. RFC 2518: HTTP Extensions for Distributed Authoring 🌸
No IPv4 dependencies here 🍓
5.106. RFC 2530: Indicating Supported Media Features Using Extensions to DSN and MDN 🌈
No IPv4 dependencies, periodt 💖
5.107. RFC 2532: Extended Facsimile Using Internet Mail 📠
No IPv4 dependencies in this one 🎀
5.108. RFC 2533: A Syntax for Describing Media Feature Sets 🦋
No IPv4 dependencies, the syntax is clean 🫶
5.109. RFC 2534: Media Features for Display, Print, and Fax ✨
No IPv4 dependencies. Display, print, and fax are all good to go 🖨️
5.110. RFC 2554: SMTP Service Extension for Authentication 🔐
Okay bestie, good news: no IPv4 dependencies in this one. Zero. Nada. Moving on 💅
5.111. RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML 🎀
No IPv4 dependencies in this spec either, so this one is giving clean slate ✨
5.112. RFC 2589: Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services 📂
Also no IPv4 dependencies. LDAP is lowkey just vibing here 🌸
5.113. RFC 2595: Using TLS with IMAP, POP3 and ACAP 🔒
No IPv4 dependencies in this specification 🦋
5.114. RFC 2596: Use of Language Codes in LDAP 🌍
Again, no IPv4 dependencies. Honestly iconic restraint 👑
5.115. RFC 2608: Service Location Protocol, Version 2 🧭
Okay, this one needs a little attention 👀 Section 8.1. (Service Request) has this diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The spec quotes this section as follows: "...<PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means."
And later on:
"A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned."
Main takeaway: this protocol needs a new version to become IPv6 compliant 🫠
5.116. RFC 2609: Service Templates and Service: Schemes 🪧
Section 2.1. (Service URL Syntax) defines the ABNF for a service: URL like this:
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)This doc has a bunch more references to hostnumber, so it needs an update to support IPv6 🔧
5.117. RFC 2640: Internationalization of the File Transfer Protocol 🗣️
No IPv4 dependencies here 💖
5.118. RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses 📬
No IPv4 dependencies in this specification ✨
5.119. RFC 2646: The Text/Plain Format Parameter 📝
No IPv4 dependencies. Simple and slay 🎀
5.120. RFC 2651: The Architecture of the Common Indexing Protocol (CIP) 🗂️
No IPv4 dependencies in this one 🌷
5.121. RFC 2652: MIME Object Definitions for the Common Indexing Protocol 🧩
No IPv4 dependencies. Clean ✅
5.122. RFC 2653: CIP Transport Protocols 🚚
No IPv4 dependencies here either 🦋
5.123. RFC 2732: Format for Literal IPv6 Addresses in URL's 🌐
This one defines an IPv6 specific protocol, so it's not discussed in this document. Not my drama 💅
5.124. RFC 2738: Corrections to "A Syntax for Describing Media Feature Sets" 🛠️
No IPv4 dependencies in this spec 💜
5.125. RFC 2739: Calendar Attributes for vCard and LDAP 📅
No IPv4 dependencies. Scheduling is clean 🧚
5.126. RFC 2806: URLs for Telephone Calls 📞
No IPv4 dependencies here, bestie 🫶
5.127. RFC 2821: Simple Mail Transfer Protocol 📮
Okay, the spec talks about A records a LOT, plus MX record handling with the different mixes of A and AAAA records. IPv4-only and IPv6-only nodes can cause several kinds of failure modes 😭
5.128. RFC 2822: Internet Message Format ✉️
Section 3.4.1 (Addr-spec specification) says:
"The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host. In both cases, how addressing is used and how messages are transported to a particular host is covered in the mail transport document [RFC2821]. These mechanisms are outside of the scope of this document. The local-part portion is a domain dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox."
Literal IP addresses should be avoided. But if they do get used, there should be a reference to the format described in RFC 2732 🌸
5.129. RFC 2846: GSTN Address Element Extensions in E-mail Services 📠
No IPv4 dependencies here ✨
5.130. RFC 2849: The LDAP Data Interchange Format (LDIF) - Technical Specification 🗃️
No IPv4 dependencies. Bestie, this one's fine 💖
5.131. RFC 2852: Deliver By SMTP Service Extension ⏰
No IPv4 dependencies in this specification 🌈
5.132. RFC 2879: Content Feature Schema for Internet Fax (V2) 📠
No IPv4 dependencies. Not a single one 🙈
5.133. RFC 2891: LDAP Control Extension for Server Side Sorting of Search Results 🔃
No IPv4 dependencies here 🍓
5.134. RFC 2910: Internet Printing Protocol/1.1: Encoding and Transport 🖨️
No IPv4 dependencies in this one ✨
5.135. RFC 2911: Internet Printing Protocol/1.1: Model and Semantics 🧠
No IPv4 dependencies. The model is iconic 👑
5.136. RFC 2912: Indicating Media Features for MIME Content 🎞️
No IPv4 dependencies 💅
5.137. RFC 2913: MIME Content Types in Media Feature Expressions 🎨
No IPv4 dependencies here 🦋
5.138. RFC 2919: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists 📣
No IPv4 dependencies, bestie 🫶
5.139. RFC 2938: Identifying Composite Media Features 🧩
No IPv4 dependencies in this spec 🌷
5.140. RFC 2965: HTTP State Management Mechanism 🍪
Okay so this doc has a few references to host IP addresses, but it never names a particular protocol version. A caveat like "Without putting any limitations on the version of the IP address." should be added, so there's no doubt about possible IPv4 dependencies 🔍
5.141. RFC 2971: IMAP4 ID extension 🆔
No IPv4 dependencies. Clean as ever 💜
5.142. RFC 2987: Registration of Charset and Languages Media Features Tags 🌏
No IPv4 dependencies here 🎀
5.143. RFC 3009: Registration of parityfec MIME types 🧮
No IPv4 dependencies in this specification ✨
5.144. RFC 3017: XML DTD for Roaming Access Phone Book 📖
Section 6.2.1. (DNS Server Address) states:
"The dnsServerAddress element represents the IP address of the Domain Name Service (DNS) server which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1)."
Syntax:
<!-- Domain Name Server IP address -->
<!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>Then Section 6.2.9. (Default Gateway Address) says:
"The defaulttGatewayAddress element represents the address of the default gateway which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1)."
Syntax:
<!-- Default Gateway IP address (in dotted decimal notation) -->
<!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>It should be straightforward to implement elements that are IPv6 aware 🧚
5.145. RFC 3023: XML Media Types 📄
No IPv4 dependencies here 🌸
5.146. RFC 3028: Sieve: A Mail Filtering Language 🧹
No IPv4 dependencies. Filtering is giving tidy 💖
5.147. RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages 📎
No IPv4 dependencies in this one ✨
5.148. RFC 3049: TN3270E Service Location and Session Balancing 🖥️
No IPv4 dependencies here 🎀
5.149. RFC 3059: Attribute List Extension for the Service Location Protocol 🏷️
No IPv4 dependencies 🦋
5.150. RFC 3080: The Blocks Extensible Exchange Protocol Core (BEEP) 🧱
No IPv4 dependencies in this specification 🫶
5.151. RFC 3081: Mapping the BEEP Core onto TCP 🔗
No IPv4 dependencies, bestie 🌷
5.152. RFC 3111: Service Location Protocol Modifications for IPv6 🌐
This is an IPv6 related document, so it's not discussed in this document 💅
5.153. RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration 🖼️
No IPv4 dependencies 💜
5.154. RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application 🔎
This spec has no explicit dependency on IPv4. But when it refers to the URI format specified in RFC 2396 (see section 4.3. flags, first paragraph), a reference to RFC 2732 should also be added 🌈
5.155. RFC 3501: Internet Message Access Protocol - Version 4rev1 📥
No IPv4 dependencies in this specification ✨
6. Experimental RFCs 🧪
Experimental RFCs are the "non-standard" specs. These are "off-track" specifications, like ones that haven't reached an adequate standardization level yet, or ones that have been superseded by newer specs 🙃
Experimental RFCs are part of ongoing research efforts. They're often propriety in nature, or used in limited arenas. They get documented for the Internet community so people can check potential interoperability or other useful scenarios. In a few cases, they're offered as alternatives to the mainstream solution of a known problem 🔬
6.1. RFC 887: Resource Location Protocol 🌸
Okay bestie, the <Who-Anywhere-Provides?> message is basically the third-party version of <Who-Provides?> 🫶. The confirming host is required to send back at least its own IP address (if it provides the resource) plus the IP addresses of any other hosts it thinks might provide it. But here's the drama: it may never return an IP address that matches one already listed with the resource name in the request. If that happens, it must treat the resource as unsupported at that address and leave it off the reply list 💀.
<Does-Anyone-Provide?> is the same energy, just mirroring <Do-You-Provide?> with the third-party twist ✨. The confirming host is required to return its own IP address and the addresses of other possible providers, and it's prohibited from repeating an address that was in the request's resource specifier. Same reason as before, and this message also may not be broadcast 🙅♀️.
Also, all over this section there are references to IP addresses. To avoid confusion, a reference to IPv6 addressing should be added 🦋.
Section 4.1. (Resource Lists) describes a qualifier format 💅. In all <Who-Anywhere-Provides?>, <Does-Anyone-Provide?> and <They-Provide> messages, the resource specifier has an extra qualifier right after the <Protocol-ID>, laid out like this:
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+Here's the breakdown 🍓:
<IPLength>is the number of IP addresses in the<IP-Address-List>that follows. That list takes up the last 4*<IPLength>octets of the resource specifier. In request messages it's the maximum number of qualifying addresses that can show up in the reply specifier. It can be 0, which isn't super useful, and then there's no room for qualifying addresses in the returned specifier. In reply messages it's the number of qualifying addresses known to provide the resource. It may not be bigger than the number in the matching request specifier. A reply must not have 0 here unless the request also had 0, and the confirming host would have returned one or more addresses if there had been space for them.<IP-Address-List>is a list of four-octet IP addresses used to qualify the resource specifier. In replies, these are the confirming host's own addresses (when that makes sense) plus the addresses of any other hosts known to provide the resource, within the list length limits. In requests, these are the addresses of hosts that shouldn't get resource info back. Those addresses should normally be set to some "harmless" value, like the querying host's own address, unless you actually want to exclude the supplied addresses from replies 🧚.
This section needs rewriting for the 128-bit length of IPv6 addresses, and it's going to majorly impact implementations 😭.
6.2. RFC 909: Loader Debugger Protocol (LDP) 🎀
No IPv4 dependencies here, bestie. Not a single one ✨.
6.3. RFC 1143: The Q Method of Implementing TELNET Option Negotiation 🌈
No IPv4 dependencies in this one either 💖.
6.4. RFC 1153: Digest message format (DMF-MAIL) 🦋
Good news: zero IPv4 dependencies here 🫶.
6.5. RFC 1165: Network Time Protocol (NTP) over the OSI Remote Operations Service ⭐
The only dependency this protocol has lives in Appendix A (ROS Header Format) 👀:
ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}6.6. RFC 1176: Interactive Mail Access Protocol: Version 2 💌
No IPv4 dependencies, so we're good to go 🌸.
6.7. RFC 1204: Message Posting Protocol 📮
Nothing IPv4-specific in this one 💅.
6.8. RFC 1235: Coherent File Distribution Protocol 🚀
The "Protocol Specification" section has an example for the Initial Handshake 🎟️. The ticket server answers with a TIYT ("This is Your Ticket") packet that carries the ticket. Figure 2 shows what that packet looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Fig. 2: "This Is Your Ticket" packet.
This protocol assumes IPv4 multicast, but converting it to IPv6 multicast could be done with a little effort 🧁.
6.9. RFC 1279: X.500 and Domains 🌐
This one assumes IPv4, but it doesn't actually have any limits that would stop it working in an IPv6 environment. Slay 👑.
6.10. RFC 1312: Message Send Protocol 2 💬
No IPv4 dependencies to worry about 🌷.
6.11. RFC 1339: Remote Mail Checking Protocol 📬
Zero IPv4 dependencies here 💜.
6.12. RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File Transfer 📁
Nothing IPv4-specific, periodt ✨.
6.13. RFC 1459: Internet Relay Chat Protocol 🫧
There are only two IPv4 addressing references in this one 🙈. The first is in Section 6.2. (Command Response):
203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]"The second is in Section 8.12 (Configuration File). It says that when you specify hostnames, both domain names and the 'dot' notation (127.0.0.1) should both be accepted 🍓.
After fixing the above, adding IPv6 support is pretty straightforward 💅.
6.14. RFC 1465: Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing 🗺️
No IPv4 dependencies in this spec 🌈.
6.15. RFC 1505: Encoding Header Field for Internet Messages 🏷️
Nothing IPv4 here, bestie 🎀.
6.16. RFC 1528: Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures 🖨️
No IPv4 dependencies, so you're all set 🦋.
6.17. RFC 1608: Representing IP Information in the X.500 Directory 📇
No IPv4 dependencies in this specification 💖.
6.18. RFC 1609: Charting Networks in the X.500 Directory 🗂️
Zero IPv4 dependencies, slay 💅.
6.19. RFC 1639: FTP Operation Over Big Address Records 📦
This document defines a way to get around FTP's IPv4 limits, so it's both IPv4 and IPv6 aware. Iconic behaviour 🔥.
6.20. RFC 1641: Using Unicode with MIME 🌍
No IPv4 dependencies here 🫶.
6.21. RFC 1756: Remote Write Protocol - Version 1.0 ✍️
Nothing IPv4-specific in this one ✨.
6.22. RFC 1801: MHS use of the X.500 Directory to support MHS Routing 🧭
No IPv4 dependencies, bestie 💜.
6.23. RFC 1804: Schema Publishing in X.500 Directory 📚
Zero IPv4 dependencies 🌸.
6.24. RFC 1806: Communicating Presentation Information in Internet Messages: The Content-Disposition Header 🎀
No IPv4 dependencies here, so this one's giving clean 💅.
6.25. RFC 1845: SMTP Service Extension for Checkpoint/Restart 🔁
Nothing IPv4-specific ✨.
6.26. RFC 1846: SMTP 521 Reply Code 🔢
No IPv4 dependencies, periodt 🦋.
6.27. RFC 1873: Message/External-Body Content-ID Access Type 🧩
Zero IPv4 dependencies 💖.
6.28. RFC 1874: SGML Media Types 🏷️
No IPv4 dependencies, bestie 🌈.
6.29. RFC 1986: Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol 📻
This protocol is IPv4 dependent, and you can see it in the segment from Section 2. (PROTOCOL DESCRIPTION) 😭:
Table 3: ETFTP Data Encapsulation
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+6.30. RFC 2016: Uniform Resource Agents (URAs) 🤖
No IPv4 dependencies here 🫶.
6.31. RFC 2066: TELNET CHARSET Option 🔤
Nothing IPv4-specific, slay ✨.
6.32. RFC 2075: IP Echo Host Service 🏓
No IPv4 dependencies in this spec 🌸.
6.33. RFC 2090: TFTP Multicast Option 📡
This protocol is limited to IPv4 multicast. It's expected that similar functionality could be built on top of IPv6 multicast 🦋.
6.34. RFC 2120: Managing the X.500 Root Naming Context 🌳
Zero IPv4 dependencies, bestie 💜.
6.35. RFC 2161: A MIME Body Part for ODA 📄
No IPv4 dependencies here 🎀.
6.36. RFC 2162: MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail ✉️
Nothing IPv4-specific in this one 💅.
6.37. RFC 2169: A Trivial Convention for using HTTP in URN Resolution 🔗
No IPv4 dependencies, periodt ✨.
6.38. RFC 2217: Telnet Com Port Control Option 🔌
Zero IPv4 dependencies 🌈.
6.39. RFC 2295: Transparent Content Negotiation in HTTP 🤝
No IPv4 dependencies here 💖.
6.40. RFC 2296: HTTP Remote Variant Selection Algorithm RVSA/1.0 🧚
No IPv4 dependencies in this one, so it's all good 🫶✨.
6.41. RFC 2307: An Approach for Using LDAP as a Network Information Service
okay so this one assumes IPv4 addressing in its schema 🌸 Section 3 (Attribute definitions) has these bits:
"( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )"It does try to give IPv6 some love, though 🥺 Section 5.4 (Interpreting Hosts and Networks) says:
"Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address."
BUT the format above got replaced, so it's no longer valid 💀 not it 🙈
6.42. RFC 2310: The Safe Response Header Field
No IPv4 dependencies in this one 💖 clean and easy ✨
6.43. RFC 2483: URI Resolution Services Necessary for URN Resolution
Also clean, no IPv4 dependencies 🌈
6.44. RFC 2567: Design Goals for an Internet Printing Protocol
Zero IPv4 dependencies here, slay 💅
6.45. RFC 2568: Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
Nothing IPv4-related in this spec either 🎀
6.46. RFC 2569: Mapping between LPD and IPP Protocols
Clean again, no IPv4 dependencies 🦋
6.47. RFC 2649: An LDAP Control and Schema for Holding Operation Signatures
No IPv4 dependencies, bestie ⭐
6.48. RFC 2654: A Tagged Index Object for use in the Common Indexing Protocol
Also no IPv4 dependencies 🧚
6.49. RFC 2655: CIP Index Object Format for SOIF Objects
Nothing IPv4 here either 🍓
6.50. RFC 2656: Registration Procedures for SOIF Template Types
No IPv4 dependencies in this spec 💜
6.51. RFC 2657: LDAPv2 Client vs. the Index Mesh
Same deal, no IPv4 dependencies 🫶
6.52. RFC 2756: Hyper Text Caching Protocol
ngl this one is a little messy 😭 it says it's both IPv4 and IPv6 aware, but Section 2.8 (An HTCP/0.0 AUTH has the following structure) has this SIGNATURE bit that only works with IPv4 addresses:
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest
(see [RFC 2104]), with a B value of 64, of the
following elements, each of which is digested in its
"on the wire" format, including transmitted padding
if any is covered by a field's associated LENGTH:
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"The SIGNATURE calculation should be expanded to support IPv6 16 byte addresses 🔥
6.53. RFC 2774: An HTTP Extension Framework
No IPv4 dependencies, the framework is clean ✨
6.54. RFC 2974: Session Announcement Protocol
This one is both IPv4 and IPv6 aware, and it needs no changes 👑
6.55. RFC 3018: Unified Memory Space Protocol Specification
okay this one is a whole situation 😩 Section 3.4 (Address Formats) explicitly talks about IPv4. It says:
"The following address format numbers are definite for nodes, immediately connected to the global IPv4 network:"
and lists N 4-0-0 (4), N 4-0-1 (4-1), and N 4-0-2 (4-2). Then it shows the 128-bit address layouts:
The appropriate formats of 128-bit addresses:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+It defines the two fields like this:
- Free: it is not used by the protocol.
- IP address: it sets the node address in the global IPv4 network.
⚠️ bestie, the spec itself says this section needs to be re-written so the specification becomes IPv6 compliant. That's a whole rewrite, not a tweak 💅
6.56. RFC 3082: Notification and Subscription for SLP
Both IPv4 and IPv6 aware, so it needs no changes 🌸
6.57. RFC 3088: OpenLDAP Root Service An experimental LDAP referral service
Last one in this batch 🧚 Section 5 (Using the Service) says:
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over TCP/IPv4. Future incarnations of this service may support TCP/IPv6 or other transport/internet protocols."
So it's IPv4-only for now, with IPv6 as a maybe-later 🥹
7. Summary of Results ✨
okay the scoreboard time 📊 This survey looked at 257 RFCs, and 34 (12.84%) had some form of IPv4 dependency. Here's the breakdown:
Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54%Most of the 33 identified just need small fixes 💖 like adding a caveat to IPv6 addressing so nothing's ambiguous, or rewriting a section to avoid IP-version-dependent syntax. The authors organised everything so other protocol designers can find stuff easily 🫶
7.1. Full Standards
7.1.1. RFC 959: STD 9 File Transfer Protocol
Already fixed, see [5] 🎀
7.2. Draft Standards
7.2.1. RFC 1305: Network Time Protocol (version 3): Specification, Implementation and Analysis
The big one 😭 As noted in Section 4.4. above, there are too many specific references to 32-bit IPv4 addresses. An updated spec to support NTP over IPv6 is needed. There has been some related work, an already expired work in progress that allegedly documents it. Also, there is at least one IPv6 NTP implementation 🦋
7.2.2. RFC 2396: URI Syntax
URIs allow literal IPv4 addresses, but there are no specific recommendations for representing literal IPv6 addresses. This was already addressed in [3] ✨
7.2.3. RFC 2616: Hypertext Transfer Protocol HTTP/1.1
HTTP allows literal IPv4 addresses too, with no specific guidance on literal IPv6 ones. Also already addressed in [3] 💜
7.3. Proposed Standards
7.3.1. RFC 946: Telnet Terminal LOC
The TTYLOC Number definition depends on IPv4, so it'd need an updated version. But this feature is pretty marginal now, so an update might not be worth it 🍓
7.3.2. RFC 1738: URLs
URLs with IPv4 dependencies are already addressed in [3] 🌈
These dependencies also touch other specs: RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371, and RFC 2384. All of them need a revisit, but they aren't covered separately in this memo 👀
7.3.3. RFC 2165: Service Location Protocol
Already addressed in [4] ✨
7.3.4. RFC 2384: POP3 URL Scheme
POP URL IPv4 dependencies are already addressed in [3] 🎀
7.3.5. RFC 2608: Service Location Protocol v2
Already addressed in [4] 💖
7.3.6. RFC 2821: Simple Mail Transfer Protocol
Some text updates and clarifications for MX processing would probably help 📬 The operational scenarios and guidelines for avoiding the problems are described in [6].
7.3.7. RFC 3017: XML DTP For Roaming Access Phone Books
Extensions should be defined to support IPv6 addresses 🧚
7.4. Experimental RFCs
7.4.1. RFC 1235: The Coherent File Distribution Protocol
The packet format depends on IPv4, so it'd need an update to add IPv6 support. But the protocol isn't believed to be in use, so an update may not be warranted 🥺
7.4.2. RFC 1459: Internet Relay Chat Protocol
Only a text update is needed to become IPv6 compliant 💅
7.4.3. RFC 1986: Simple File Transfer Using Enhanced TFTP
Also just a text update to become IPv6 compliant ✨
7.4.4. RFC 2090: TFTP Multicast Option
This one relies on IPv4 IGMP Multicast. To become IPv6 compliant, a new version should be produced 🔥
7.4.5. RFC 2307: Using LDAP as a NIS
This document tries to give IPv6 support, but it relies on an outdated format for IPv6 addresses. So an IPv6 compliant version is needed 🌸
8. Acknowledgements
Phil wants to thank the Internet Society for supporting the research and production of this document 🫶 He also wants to thank his partner in all ways, Wendy M. Nesser 💜
9. Security Considerations
okay, serious moment 🙈 This document gives an exhaustive documentation of current IETF documented standards IPv4 address dependencies. That process doesn't have security implications in itself 🔐 (Still, go check the actual dependencies, because the gaps are where the drama lives 💀)
10. References
10.1. Normative References 📚
okay bestie, these are the must-read docs 💅 (the normative ones, so the spec literally leans on them 🫶)
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
RFC 3789, June 2004.
[2] Bradner, S., "The Internet Standards Process - version 3", BCP 9,
RFC 2026, October 1996.10.2. Informative References 🌸
and these ones are the extra-credit reading 🤓✨ helpful for context but the spec doesn't depend on them to work
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[4] Guttman, E., "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001.
[5] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998.
[6] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed
IPv4/IPv6 environements", Work in Progress.11. Authors' Addresses 🎀
these are the lovely people who wrote the whole thing, so you know who to thank (or DM 🦋)
Rute Sofia
FCCN
Av. Brasil, 101
1700 Lisboa, Portugal
Phone: +351 91 2507372
EMail: rsofia@zmail.pt
Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202
Kirkland, WA 98034
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: phil@nesser.com12. Full Copyright Statement ⚖️
okay the legal bit 🙈 but it's important, so read it with me
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭
Intellectual Property 🧚
the IETF is not picking a side on who owns what 🫠 here's the vibe:
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🔥
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 📜
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌
Acknowledgement 🌈
the RFC Editor function gets funded by the Internet Society, so a big thank-you to them 🫶✨
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3795 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms