RFC 3794
Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents
Title Block 🎀
Okay bestie, this one is RFC 3794, and it's called "Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents" 🦋 It's by P. Nesser, II from Nesser & Nesser Consulting and A. Bergstrom, Ed. from Ostfold University College. It's Informational, dated June 2004, and the header doesn't list any RFCs it obsoletes or updates ✨ it's giving standalone survey energy 💅
Status of this Memo 📜
This memo is here to inform the Internet community 💜 It's not a standard of any kind, and you can share it as much as you want, because distribution is unlimited 🌈
Copyright Notice ©️
The copyright line is Copyright (C) The Internet Society (2004). ✨
Abstract 🔥
Okay so the whole point of this doc is to track down every single place where IPv4 addresses are used in the IETF Transport Area's documented standards that are currently deployed 🔍 The Internet is going from an all IPv4 world to an all IPv6 world, and that's a big glow-up that needs lots of interim steps 🦋 One of those steps is updating current protocols that depend on IPv4 🛠️ The dream is that these protocols (and their implementations) get redesigned so they're network address independent 🌸 but if that doesn't happen, they should at least dually support IPv4 and IPv6 💖 So this survey looks at all Standards (Full, Draft, and Proposed) plus Experimental RFCs and writes down every dependency it finds 📝
Table of Contents 🧚
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 311.0. Introduction ✨
This doc is part of a set that's trying to document all IPv4 address usage in IETF standards 🌟 The whole thing would be way too much for one file, so it's been split into 7 documents that follow the current IETF areas: Application, Internet, Operations & Management, Routing, Security, Sub-IP, and Transport 🗂️
For the full intro, check out [1] 📖
2.0. Document Organization 🗺️
Here's the tea on how the rest of the doc is laid out 🍓
Sections 3, 4, 5, and 6 are the raw analysis of Full, Draft, and Proposed Standards, plus Experimental RFCs. Each RFC gets its own turn, starting with RFC 1 and ending around RFC 3100. The comments are "raw," which means every RFC is judged in a vacuum 🙈 Problems don't "look ahead" to see if they've already been fixed later.
Section 7 is the big-picture part 🧩 It takes everything from Sections 3, 4, 5, and 6 and looks at it all together, matching up the problems that were fixed in later RFCs.
3.0. Full Standards 💎
Full Internet Standards (usually just called "Standards") are fully mature protocol specs that are widely implemented and used all over the Internet 👑
3.1. RFC 768 User Datagram Protocol 🦋
Even though UDP is a transport protocol, there's one spot where it talks about the UDP/IP interface and says: "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." 👀 It doesn't force a rewrite of the protocol, but it's definitely going to cause changes in implementations 🔧
3.2. RFC 793 Transmission Control Protocol 🌸
Section 3.1 is the one that lays out the TCP header format 📋 The TCP header is totally free from IPv4 references, but the checksum computation is inconsistent 😭 The text says: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to be 32-bit IPv4 addresses 🫶 TCP doesn't need to be modified because of this, but an alternative has to be specified, either as an update document or as part of another IPv6 document 💅
3.3. RFC 907 Host Access Protocol specification 🧚
This one is a layer 3 protocol, so it has no IPv4 dependencies at all ✨ no drama here 🫧
3.4. NetBIOS Service Protocols 💅 RFC1001, RFC1002
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS 🎀
okay so RFC 1001 is the concepts-and-methods one for NetBIOS services running over TCP/UDP, and it's giving full "here's how the whole vibe works" energy ✨
Section 15.4.1. RELEASE BY B NODES defines:
A NAME RELEASE DEMAND contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
Section 15.4.2. RELEASE BY P NODES defines:
A NAME RELEASE REQUEST contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
A NAME RELEASE RESPONSE contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
- Result:
- Yes: name was released
- No: name was not released, a reason code is provided
Section 16. NetBIOS SESSION SERVICE states:
okay so the NetBIOS session service begins after one or more IP addresses have been found for the target name 💖 those addresses might have been picked up through NetBIOS name query transactions, or from something like a local name table or cache 🧚
16.1. OVERVIEW OF NetBIOS SESSION SERVICE
the session service has three phases 🦋 and the first one is:
- Session establishment: this is the phase where the IP address and TCP port of the called name get determined, and a TCP connection gets set up with the remote party 🌸
6.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
bestie, here's how session establishment goes 🫶 an end-node starts setting up a session to another node by somehow acquiring the IP address of the node (or nodes) that's supposed to own the destination name. It could use name query transactions or a local cache to do that 💅
once the TCP connection is open, the calling node sends a session service request packet 📦 this packet carries the following information:
- Calling IP address (see note)
- Calling NetBIOS name
- Called IP address (see note)
- Called NetBIOS name
NOTE: The IP addresses are obtained from the TCP service interface.
if a compatible LISTEN exists and there are adequate resources, the session server may turn the existing TCP connection into the NetBIOS data session ✨ or, alternatively, the session server may redirect (aka "retarget") the caller to another TCP port (and IP address) 🔀
if the caller gets redirected, it starts the session establishment all over again, but this time using the new IP address and TCP port given in the retarget response 😭 another TCP connection gets created, and the calling and called nodes exchange credentials again. The called party can accept the call, reject the call, or make a further redirection 💀
17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
every NetBIOS datagram has a named destination and source 🎀 to send one, the datagram service has to do a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (That info can be cached, so the overhead of name query doesn't have to happen on every subsequent NetBIOS datagram 🧠)
17.1.1. UNICAST, MULTICAST, AND BROADCAST
NetBIOS datagrams can be unicast, multicast, or broadcast 🌈 a NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datagram addressed to a group NetBIOS name is multicast, whether there are zero, one, or more actual members. And a NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast 📣
17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
okay this one's important 🚨 when the header and data of a NetBIOS datagram go over the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt 🧩
a NetBIOS Datagram is made up of the following protocol elements:
- IP header of 20 bytes (minimum)
- UDP header of 8 bytes
- NetBIOS Datagram Header of 14 bytes
- The NetBIOS Datagram data.
18. NODE CONFIGURATION PARAMETERS
here's the config checklist for each node type 📝
- B NODES:
- Node's permanent unique name
- Whether IGMP is in use
- Broadcast IP address to use
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- P NODES:
- Node's permanent unique name
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- M NODES:
- Node's permanent unique name
- Whether IGMP is in use
- Broadcast IP address to use
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
ngl, all of the proceeding sections make implicit use of IPv4 addresses 🌸 so a new specification should be defined for using IPv6 underlying addresses 🦋
3.4.2. RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS 🧚
okay, RFC 1002 is the detailed specs version, so buckle up 💅 this is where all the exact bytes live 🍓
Section 4.2.1.3. RESOURCE RECORD defines
RESOURCE RECORD RR_TYPE field definitions 💖
Symbol Value Description:
A 0x0001 IP address Resource Record (See
REDIRECT NAME QUERY RESPONSE)so the sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME OVERWRITE REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST, 4.2.5. POSITIVE NAME REGISTRATION RESPONSE, 4.2.6. NEGATIVE NAME REGISTRATION RESPONSE, 4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9. NAME RELEASE REQUEST & DEMAND, 4.2.10. POSITIVE NAME RELEASE RESPONSE, 4.2.11. NEGATIVE NAME RELEASE RESPONSE and 4.2.13. POSITIVE NAME QUERY RESPONSE all contain 32 bit fields labeled NB_ADDRESS, clearly defined for IPv4 addresses 🌈 and 4.2.15. REDIRECT NAME QUERY RESPONSE contains a field NSD_IP_ADDR, which is also designed for an IPv4 address 🙈
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Section 4.4.1. NetBIOS DATAGRAM HEADER
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Section 4.4.3. DATAGRAM ERROR PACKET
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Section 4.4.4. DATAGRAM QUERY REQUEST
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So that's the end of the packet diagram, with SOURCE_IP, SOURCE_PORT, and a DESTINATION_NAME that stretches across the whole thing 💅
5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS 🎀
Okay so these are the GLOBAL variables, and NetBIOS users are supposed to be able to configure them 🫶 The only one listed is:
BROADCAST_ADDRESS: the IP address B-nodes use for datagrams aimed at group name destinations, and for broadcast datagrams. The default is the IP broadcast address for one single IP network 🌸
There's also a big pile of pseudo code for most of the protocol's functionality, and none of it mentions IPv4 addresses specifically 🧚 It does assume the packets defined above, though. Lowkey, the pseudo code could be fine for IPv6 too, as long as the packet formats get updated 💜
3.5. RFC 1006 ISO Transport Service on top of the TCP (Version: 3) ✨
This is Section 5, The Protocol, which defines a mapping specification. The mapping parameters are also super straightforward, look:
network service TCP
------- ---
CONNECTION RELEASE
Called address server's IP address
(4 octets)
Calling address client's IP address
(4 octets)4.0. Draft Standards 🦋
Draft Standards are the penultimate standard level in the IETF, so basically almost there! A protocol can only reach draft standard once there are multiple, independent, interoperable implementations. These are usually super mature and widely used, no cap 👑
4.1. RFC 3530 Network File System (NFS) version 4 Protocol
Good news bestie, this one has no IPv4 dependencies 💖
4.2. RFC 3550 RTP: A Transport Protocol for Real-Time Applications
Also no IPv4 dependencies here 🌈
4.3. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control.
Again, zero IPv4 dependencies in this one 💅
5.0. Proposed Standards 🌸
Proposed Standards are the introductory level. There are no requirements for even a single implementation! In a lot of cases, Proposed ones never get implemented or advanced in the IETF standards process, so they're often just proposed ideas that get presented to the Internet community. Sometimes flaws get exposed, or they're one of many competing solutions to a problem. In those later cases, no discussion is presented, because it wouldn't serve the purpose of this discussion 🙈
5.01. RFC 1144 Compressing TCP/IP headers for low-speed serial links
This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers, so it's giving "someone already did the homework" 🧚
5.02. RFC 1323 TCP Extensions for High Performance
No IPv4 dependencies in this specification ✨
5.03. RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)
No IPv4 dependencies in this specification 🍓
5.04. RFC 1692 Transport Multiplexing Protocol (TMux)
Okay so in Section 6, Implementation Notes is states:
Because the TMux mini-header does not contain a TOS field, only
segments with the same IP TOS field should be contained in a
single TMux message. As most systems do not use the TOS
feature, this is not a major restriction. Where the TOS field
is used, it may be desirable to hold several messages under
construction for a host, one for each TOS value.
Segments containing IP options should not be multiplexed.This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality 💖
5.05. RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC
No IPv4 dependencies in this specification 🎀
5.06. RFC 1833 Binding Protocols for ONC RPC Version 2
In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there's this code fragment, and it's giving main character energy 🦋
* Protocol family (r_nc_protofmly):
* This identifies the family to which the protocol belongs.
* The following values are defined:
* NC_NOPROTOFMLY "-"
* NC_LOOPBACK "loopback"
* NC_INET "inet"
* NC_IMPLINK "implink"
* NC_PUP "pup"
* NC_CHAOS "chaos"
* NC_NS "ns"
* NC_NBS "nbs"
* NC_ECMA "ecma"
* NC_DATAKIT "datakit"
* NC_CCITT "ccitt"
* NC_SNA "sna"
* NC_DECNET "decnet"
* NC_DLI "dli"
* NC_LAT "lat"
* NC_HYLINK "hylink"
* NC_APPLETALK "appletalk"
* NC_NIT "nit"
* NC_IEEE802 "ieee802"
* NC_OSI "osi"
* NC_X25 "x25"
* NC_OSINET "osinet"
* NC_GOSIP "gosip"It's clear that the value for NC_INET is meant for the IP protocol, and it seems clear that it's IPv4 dependent 🔥
5.07. RFC 1962 The PPP Compression Control Protocol (CCP)
No IPv4 dependencies in this specification 💜
5.08. RFC 2018 TCP Selective Acknowledgement Options
No IPv4 dependencies in this specification ✨
5.09. RFC 2029 RTP Payload Format of Sun's CellB Video Encoding
No IPv4 dependencies in this specification 🌸
5.10. RFC 2032 RTP Payload Format for H.261 Video Streams
No IPv4 dependencies in this specification 🦋
5.11. RFC 2126 ISO Transport Service on top of TCP (ITOT)
This specification is IPv6 aware and has no issues 👑
5.12. RFC 2190 RTP Payload Format for H.263 Video Streams
No IPv4 dependencies in this specification 🍓
5.13. RFC 2198 RTP Payload for Redundant Audio Data
No IPv4 dependencies in this specification 🧚
5.14. RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
In Section 1. Introduction the statement is made:
RSVP operates on top of IPv4 or IPv6, occupying the place of a
transport protocol in the protocol stack.Appendix A defines all of the header formats for RSVP, and there are multiple formats for both IPv4 and IPv6 💖
There are no IPv4 dependencies in this specification 🌈
5.15. RFC 2207 RSVP Extensions for IPSEC Data Flows
The defined IPsec extensions are valid for both IPv4 & IPv6. There are no IPv4 dependencies in this specification 🎀
5.16. RFC 2210 The Use of RSVP with IETF Integrated Services
No IPv4 dependencies in this specification 💅
5.17. RFC 2211 Specification of the Controlled-Load Network Element Service
No IPv4 dependencies in this specification 🙈
5.18. RFC 2212 Specification of Guaranteed Quality of Service
No IPv4 dependencies in this specification ✨
5.19. RFC 2215 General Characterization Parameters for Integrated Service Network Elements
No IPv4 dependencies in this specification 🫶
5.20. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
No IPv4 dependencies in this specification 🌸
5.21. RFC 2326 Real Time Streaming Protocol (RTSP)
Section 3.2, RTSP URL, defines this:
The "rtsp" and "rtspu" schemes are used to refer to network
resources via the RTSP protocol. This section defines the
scheme-specific syntax and semantics for RTSP URLs.
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP
address (in dotted decimal form), as defined
by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGITLater in that section the following text is added, and this part is the one that's a little bit spicy:
The use of IP addresses in URLs SHOULD be avoided whenever
possible (see RFC 1924 [19]).Some later examples show:
Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,
application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portraitThis implies the use of the "IP4" tag, and it should be possible to use an "IP6" tag. There are also a bunch of other similar examples using the "IP4" tag 🙈
RTSP is also dependent on IPv6 support in a protocol that can describe media configurations, like SDP RFC 2327. RTSP can be used over IPv6 as long as the media description protocol supports IPv6, but only for certain restricted use cases. For full functionality there's a need for IPv6 support. The amount of updates needed is small, though, so it's not a huge lift 💖
5.22. RFC 2327 SDP: Session Description Protocol (SDP)
This specification is under revision, and IPv6 support was added in RFC 3266, which updates this specification 🦋
5.23. RFC 2380 RSVP over ATM Implementation Requirements
This specification is both IPv4 and IPv6 aware 👑
5.24. RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM
There doesn't seem to be any inherent IPv4 limitations in this specification, but it assumes the work of other standards that do have IPv4 limitations 🍓
5.25. RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
No IPv4 dependencies in this specification 🧚
5.26. RFC 2431 RTP Payload Format for BT.656 Video Encoding
No IPv4 dependencies in this specification 🌈
5.27. RFC 2435 RTP Payload Format for JPEG-compressed Video
No IPv4 dependencies in this specification 🎀
5.28. RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
This specification is both IPv4 and IPv6 aware 💅
5.29. RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
This specification is both IPv4 and IPv6 aware 🙈
5.30. RFC 2581 TCP Congestion Control
No IPv4 dependencies in this specification ✨
5.31. RFC 2597 Assured Forwarding PHB Group
This specification is both IPv4 and IPv6 aware 🫶
5.32. RFC 2658 RTP Payload Format for PureVoice(tm) Audio 🎀
Okay bestie, this one's a total win ✨ There are no IPv4 dependencies in this specification. 💖
5.33. RFC 2678 IPPM Metrics for Measuring Connectivity 🦋
Lowkey limited here 🥺 This specification only supports IPv4.
5.34. RFC 2679 A One-way Delay Metric for IPPM ⏱️
Same energy as the last one, sadly 😭 This specification only supports IPv4.
5.35. RFC 2680 A One-way Packet Loss Metric for IPPM 📉
Still IPv4 only, bestie 💀 This specification only supports IPv4.
5.36. RFC 2681 A Round-trip Delay Metric for IPPM 🔁
Yep, IPv4 only again 🙈 This specification only supports IPv4.
5.37. RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) 👑
This one is iconic 👑 It's both IPv4 and IPv6 aware, so it needs no changes. Ate, no crumbs 💅
5.38. RFC 2733 An RTP Payload Format for Generic Forward Error Correction 🛡️
Okay so this one is giving "almost there" 🥲 It depends on SDP, and SDP has IPv4 dependencies. Once that limitation is fixed, this specification should support IPv6 ✨
5.39. RFC 2745 RSVP Diagnostic Messages 🩺
Slay, both IPv4 and IPv6 aware, and no changes needed 💖
5.40. RFC 2746 RSVP Operation Over IP Tunnels 🚇
Also both IPv4 and IPv6 aware, needs no changes 🫶
5.41. RFC 2750 RSVP Extensions for Policy Control 📜
No IPv4 dependencies in this specification 🌸
5.42. RFC 2793 RTP Payload for Text Conversation 💬
No IPv4 dependencies in this specification 💜
5.43. RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks 🤔
Okay this one is a little bit of a mess, not gonna lie 💀 It claims to be both IPv4 and IPv6 aware, but all of the examples use IPv4 addresses. That by itself isn't a dealbreaker, but the following statement is made:
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
0.0.0.0) and priority. All IP addresses are assumed to be in
network byte order. In addition, current DSBM's L2 address is
also stored as part of this state information.It could just be sloppy wording 🙃 Honestly, a short document clarifying the text would be appropriate 📝
5.44. RFC 2815 Integrated Service Mappings on IEEE 802 Networks 🧩
No IPv4 dependencies in this specification 🌈
5.45. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals ☎️
No IPv4 dependencies in this specification 🎶
5.46. RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services 📞
Ugh, same SDP issue here 😩 This specification depends on SDP, which has IPv4 dependencies. Once these limitations are fixed, this specification should support IPv6 ✨
5.47. RFC 2862 RTP Payload Format for Real-Time Pointers 👆
No IPv4 dependencies in this specification 💖
5.48. RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP 🪪
No IPv4 dependencies in this specification ✨
5.49. RFC 2873 TCP Processing of the IPv4 Precedence Field 🚦
This one is IPv4 limited, and that's the whole point 😅 It documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6 🔮
5.50. RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP 🧾
No IPv4 dependencies in this specification 🌸
5.51. RFC 2907 MADCAP Multicast Scope Nesting State Option 🪆
Both IPv4 and IPv6 aware, no changes needed ✅
5.52. RFC 2960 Stream Control Transmission Protocol 🚚
This one is both IPv4 and IPv6 aware and needs no changes. Main character energy 👑
5.53. RFC 2961 RSVP Refresh Overhead Reduction Extensions 🔋
Both IPv4 and IPv6 aware, no changes needed 💅
5.54. RFC 2976 The SIP INFO Method ℹ️
No IPv4 dependencies in this specification 💜
5.55. RFC 2988 Computing TCP's Retransmission Timer ⏳
No IPv4 dependencies in this specification 🫶
5.56. RFC 2996 Format of the RSVP DCLASS Object 🏷️
No IPv4 dependencies in this specification 🌈
5.57. RFC 2997 Specification of the Null Service Type 🫥
No IPv4 dependencies in this specification ✨
5.58. RFC 3003 The audio/mpeg Media Type 🎧
No IPv4 dependencies in this specification 🎀
5.59. RFC 3006 Integrated Services in the Presence of Compressible Flows 🗜️
Okay so this one defines a protocol that discusses compressible flows, but only in an IPv4 context 😭 When IPv6 compressible flows are defined, a similar technique should also be defined 🌸
5.60. RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams 🎬
No IPv4 dependencies in this specification 💖
5.61. RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol 🧩
Both IPv4 and IPv6 aware, needs no changes. Iconic 👑
5.62. RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit 🔁
No IPv4 dependencies in this specification ✨
5.63. RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 🎵
No IPv4 dependencies in this specification 💜
5.64. RFC 3057 ISDN Q.921-User Adaptation Layer 📡
No IPv4 dependencies in this specification 🫶
5.65. RFC 3095 Robust Header Compression (ROHC): Framework and four profiles 🗜️
Both IPv4 and IPv6 aware, no changes needed 🦋
5.66. RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections 🛰️
This one is currently limited to IPv4, and the details are right here 👀
The range and format of the <rtcpPortNum> and <rtcpIPaddr>
subparameters is per [1]. The <rtcpPortNum> is a decimal
number between 1024 and 65535. It is an odd number. If an
even number in this range is specified, the next odd number is
used. The <rtcpIPaddr> is expressed in the usual dotted
decimal IP address representation, from 0.0.0.0 to
255.255.255.255.and
<rtcpIPaddr> IP address for receipt Dotted decimal,
7-15 chars of RTCP packets5.67. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio 🎧
No IPv4 dependencies in this specification 🌈
5.68. RFC 3124 The Congestion Manager 🚦
This document is IPv4 limited, since it uses the IPv4 TOS header field 😬
5.69. RFC 3140 Per Hop Behavior Identification Codes 🏷️
No IPv4 dependencies in this specification 💖
5.70. RFC 3173 IP Payload Compression Protocol (IPComp) 🗜️
No IPv4 dependencies in this specification ✨
5.71. RFC 3181 Signaled Preemption Priority Policy Element 👑
No IPv4 dependencies in this specification 🫶
5.72. RFC 3182 Identity Representation for RSVP 🪪
No IPv4 dependencies in this specification 💜
5.73. RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior) 🚀
No IPv4 dependencies in this specification 🌸
5.74. RFC 3261 SIP: Session Initiation Protocol 📞
No IPv4 dependencies in this specification 💅
5.75. RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP) 🔔
No IPv4 dependencies in this specification 🦋
5.76. RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers 🗺️
No IPv4 dependencies in this specification ✨
5.77. RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP) 🤝
No IPv4 dependencies in this specification 💖
5.78. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification 📣
No IPv4 dependencies in this specification 🌈
5.79. RFC 3390 Increasing TCP's Initial Window 🪟
No IPv4 dependencies in this specification 💜
5.80. RFC 3525 Gateway Control Protocol Version 1 🌉
No IPv4 dependencies in this specification 🫶
5.81. RFC 3544 IP Header Compression over PPP 🗜️
No IPv4 dependencies in this specification 🎀
6.0. Experimental RFCs ✨
Okay so Experimental RFCs are the experimental era of the RFC world 🧪 They usually describe protocols that aren't widely implemented or used across the Internet. Honestly, a lot of them are proprietary or only show up in small, niche spaces. They get published so the Internet community can see them and check for possible interoperability or other useful scenarios. Every now and then, one is offered as an alternative to the mainstream solution for a problem everyone already knows about 💅
6.1. RFC 908 Reliable Data Protocol (RDP)
This one is giving IPv4 only, and the next section explains why 🙈
4.1. IP Header Format
When RDP segments are used on the internet, they get sent with the version 4 IP header, as described in RFC791, "Internet Protocol." The RDP protocol number is ??? (decimal). The time-to-live field should be set to a reasonable value for the network.
All other fields should be set as specified in RFC-791.
A new protocol specification would be needed to support IPv6 🌈
6.02. RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP)
Here's what this spec says 🎀
4.1. State Variables
Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules it will communicate with. For each remote internet address, an IRTP module must maintain the following information (called the connection table):
rem_addr (32 bit remote internet address)A new specification that is IPv6 aware would need to be created ✨
6.03. RFC 998 NETBLT: A bulk data transfer protocol
This RFC says:
The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number.
Clearly this is IPv4 dependent 🥺 but it could easily be modified to support IPv6 addressing 🦋
6.04. RFC 1045 VMTP: Versatile Message Transaction Protocol
This spec has a lot of IPv4 dependencies hiding in its implementation appendices 👀 For operations over IPv6, a similar implementation procedure must be defined. The IPv4 specific info is shown below 💖
IV.1. Domain 1
For initial use of VMTP, we define the domain with Domain identifier 1 like this:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bitsThe Internet address is the Internet address of the host on which this entity-id was originally allocated. The Discriminator is an arbitrary value that is unique relative to this Internet host address. On top of that, the host must guarantee that this identifier does not get reused for a long period of time after it becomes invalid. ("Invalid" means that no VMTP module considers in bound to an entity.) One technique is to use the lower order bits of a 1 second clock. The clock need not represent real-time, but it must never be set back after a crash. In a simple implementation, using the low order bits of a clock as the time stamp, the generation of unique identifiers is overall limited to no more than 1 per second on average. The type flags were described in Section 3.1 🧠
An entity may migrate between hosts. So an implementation can heuristically use the embedded Internet address to locate an entity, but it should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred 🫶
Entity group identifiers in Domain 1 come in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bitswith the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator tells apart group identifiers that use the same Internet host group. Well-known entity group identifiers should be allocated to match the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain, as its embedded Internet host group address, the host group for Domain Name servers 🍓
A dynamically allocated entity identifier is structured as:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bitswith the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is an Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X, where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier.
We use the following notation for Domain 1 entity identifiers <10> and propose it as a standard convention:
<flags>-<discriminator>-<Internet address>where <flags> are:
[X]{BE,LE,RG,UG}[A]
X = reserved
BE = big-endian entity
LE = little-endian entity
RG = restricted group
UG = unrestricted group
A = aliasand <discriminator> is a decimal integer, and <Internet address> is in standard dotted decimal IP address notation 🔥
V.1. Authentication Domain 1
A principal identifier is structured like this 🌸
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bitsVI. IP Implementation
VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol. (It may also be implemented as a local network protocol directly in "raw" network packets.)
The well-known entity identifiers specified so far are:
VMTP_MANAGER_GROUP RG-1-224.0.1.0
Managers for VMTP operations.
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0
Client entity identifier to use when a (big-
endian) host has not determined or been allocated
any client entity identifiers.
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0
Client entity identifier to use when a (little-
endian) host has not determined or been allocated
any client entity identifiers.Note that 224.0.1.0 is the host group address assigned to VMTP, and all VMTP hosts belong to it 🧚
6.05. RFC 1146 TCP alternate checksum options
No IPv4 dependencies in this specification! 🎉
6.06. RFC 1151 Version 2 of the Reliable Data Protocol (RDP)
No IPv4 dependencies in this specification! 🎉
6.07. RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification
No IPv4 dependencies in this specification! 🎉
6.08. RFC 1693 An Extension to TCP : Partial Order Service
No IPv4 dependencies in this specification! 🎉
6.09. RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
No IPv4 dependencies in this specification! 🎉
6.10. RFC 2343 RTP Payload Format for Bundled MPEG
No IPv4 dependencies in this specification! 🎉
6.11. RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm
No IPv4 dependencies in this specification! 🎉
6.12. RFC 2762 Sampling of the Group Membership in RTP
No IPv4 dependencies in this specification! 🎉
6.13. RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
Both IPv4 and IPv6 aware, and it needs no changes 💜
6.14. RFC 2861 TCP Congestion Window Validation
Both IPv4 and IPv6 aware, and it needs no changes 💜
6.15. RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
Both IPv4 and IPv6 aware, and it needs no changes 💜
7.0. Summary of Results ✨
In the initial survey, 24 positives were identified out of a total of 104, broken down like this 📊
Standards: 3 out of 5 or 60.00%
Draft Standards: 0 out of 2 or 0.00%
Proposed Standards: 17 out of 82 or 20.73%
Experimental RFCs: 4 out of 15 or 26.67%Of those identified, many require no action, because they document outdated and unused protocols. Others document protocols that the appropriate working groups are actively updating 🙌 There are also many instances of standards that SHOULD be updated but don't cause any operational impact if they aren't. The remaining instances are documented below 🦋
7.1. Standards
7.1.1. STD 7 Transmission Control Protocol (RFC 793)
Section 3.1 defines the technique for computing the TCP checksum, and it uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1 💅
7.1.2. STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002)
These two RFCs have a lot of inherent IPv4 assumptions, so a new set of protocols must be defined 😭
7.1.3. STD 35 ISO Transport over TCP (RFC 1006)
This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP ✨
7.2. Draft Standards
There are no draft standards within the scope of this document 🌈
7.3. Proposed Standards ✨
7.3.01. TCP/IP Header Compression over Slow Serial Links (RFC 1144) 🎀
okay so this one got sorted out in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links 🦋. you should also peek at RFC 2507 & RFC 2509 bc they're part of the same vibe 💅
7.3.02. ONC RPC v2 (RFC 1833) 🧚
the problems can be fixed by defining the NC_INET6 protocol family 💜 it's giving clean upgrade energy ✨
7.3.03. RTSP (RFC 2326) 🌸
the RTSP developer group has acknowledged the problem and it's going to get addressed when the spec moves from Proposed to Draft Standard 🫶 this one is also covered by RFC 2732, IPv6 Literal Addresses in URL's, so two birds, one stone 🐦
7.3.04. SDP (RFC 2327) 🎀
one of the problems is handled by RFC 2732, IPv6 Literal Addresses in URL's. the other one just needs a minor textual clarification 📝 and honestly this has to happen if the doc wants to move from Proposed to Draft. these fixes are solved by documents that are currently in Auth48 or IESG discuss, so it's almost there bestie 🥹
7.3.05. IPPM Metrics (RFC 2678) 🌈
the IPPM WG is on it and working to resolve these issues 🫡
7.3.06. IPPM One Way Delay Metric for IPPM (RFC 2679) ⭐
the IPPM WG is working to resolve these issues. there's an ID you can check out, draft-ietf-ippm-owdp-03.txt 📖
7.3.07. IPPM One Way Packet Loss Metric for IPPM (RFC 2680) 🍓
the IPPM WG is working to resolve these issues 💅
7.3.09. Round Trip Delay Metric for IPPM (RFC 2681) 🔥
the IPPM WG is working to resolve these issues 🙌
7.3.08. The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848) 📞
this spec depends on SDP, and SDP has IPv4 dependencies 😤 once those limitations get fixed, this protocol should support IPv6 too 🩷
7.3.09. TCP Processing of the IPv4 Precedence Field (RFC 2873) 💀
the problems are not being addressed. no cap, that's the tea ☕
7.3.10. Integrated Services in the Presence of Compressible Flows (RFC 3006) 🦋
this document defines a protocol that talks about compressible flows, but only in an IPv4 context 👀 when IPv6 compressible flows get defined, a similar technique should also be defined. it's a whole vibe waiting to happen ✨
7.3.11. SDP For ATM Bearer Connections (RFC 3108) 🫠
the problems are not being addressed, but honestly it's unclear whether this spec is even being used 🤷♀️
7.3.12. The Congestion Manager (RFC 3124) 👑
an update to this doc could simply define the use of the IPv6 Traffic Class field, since it's defined to be exactly the same as the IPv4 TOS field 🎀 so it's a small glow-up, not a total rewrite 💖
7.4. Experimental RFCs 🧪
7.4.1. Reliable Data Protocol (RFC 908) 🌸
this spec relies on IPv4, and a new protocol standard may be produced 🫶
7.4.2. Internet Reliable Transaction Protocol functional and interface specification (RFC 938) 🍓
this spec relies on IPv4, and a new protocol standard may be produced 💅
7.4.3. NETBLT: A bulk data transfer protocol (RFC 998) 🚀
this spec relies on IPv4, and a new protocol standard may be produced ✨
7.4.4. VMTP: Versatile Message Transaction Protocol (RFC 1045) 🧚
this spec relies on IPv4, and a new protocol standard may be produced 🌈
7.4.5. OSPF over ATM and Proxy-PAR (RFC 2844) 🦋
this spec relies on IPv4, and a new protocol standard may be produced 💜
8.0. Security Considerations 🔐
this memo examines the IPv6-readiness of specifications. this memo does not have security considerations in itself 🙈 but the vibes of IPv6-readiness are still super important for everyone 🫶
9.0. Acknowledgements 🫶
the authors want to give a huge shoutout to the Internet Society for supporting the research and production of this document 🥰 author Philip J. Nesser II also wants to thank his partner in all ways, Wendy M. Nesser 💖
the editor, Andreas Bergstrom, wants to thank Pekka Savola for guidance and for collecting comments while editing this doc 🙌 he'd also like to thank Allison Mankin, Magnus Westerlund and Colin Perkins for valuable feedback on some points 🌟
10.0. Normative Reference 📚
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
RFC 3789, June 2004.11.0. Authors' Addresses 📬
please contact the authors with any questions, comments or suggestions at:
Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202
Kirkland, WA 98034
Phone: +1 425 481 4303
Fax: +1 425 48
EMail: phil@nesser.com
Andreas Bergstrom, Editor
Ostfold University College
Rute 503 Buer
N-1766 Halden
Norway
EMail: andreas.bergstrom@hiof.no12.0. Full Copyright Statement 📜
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 there, the authors keep all their rights 🔒
this document and the information in it are provided on an "AS IS" basis. the contributor, the organization they represent or are sponsored by (if any), the Internet Society and the Internet Engineering Task Force all disclaim every warranty, express or implied. that includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🙅♀️
Intellectual Property ✨
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology in this document, or on whether any license under those rights might be available. it also doesn't claim to have made any independent effort to find such rights 🕵️♀️ info on how rights work for RFC documents is in BCP 78 and BCP 79 📖
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of an attempt to get a general license or permission to use those proprietary rights, can be found in the IETF online 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 needed to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 📩
Acknowledgement 💖
funding for the RFC Editor function is currently provided by the Internet Society 🌸
📦 where this page comes from
- ietf: rfc3794 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms