> Dear Mr. Hönes, > > I have queued a document that contains the STRICTLY EDITORIAL corrections > documented below for the RFC Editor. > I did not submit the document yet, because I am waiting for instructions > from the RFC Editor regarding these late comments. Thanks for your efforts and elaborations. At this instant, I only would like to give a short clarifying response to a few details where I believe that you have misunderstood me. > [...] >> >> (B.5) Section 2.2, 1st para -- minor concern >> >> The draft says: >> >> | The term Native IP Address is a Native Address, which MAY be used to >> | reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP >> Address includes the binary IP address, and an OPTIONAL port number >> that MAY be followed by an OPTIONAL protocol identifier. The Native >> IP Address SHALL be encoded as described in Section 2.3. Encoding of >> Native IP Addresses. >> >> The first sentence is highly confusing. >> I suspect that you wanted to indicate: >> >> vvvvvvv vvvvvvvvvvv vvvvvvvv >> | The term Native IP Address denotes a transport address that can be >> used to reach a C12.22 Node on its C12.22 IP Network Segment. [...] > > Actually no. The original text is exacly right. This cannot be right. A phrase like "The term XXX Address _is_ an YYY address ..." is nonsensical, independent of technical intent; a _term_ (as used here) never *is* an _address_, it only can *denote* an address. > Native Address is a Definition in this RFC and used by C12.22. That's correct from a general view of the C12.22 layer(s), but the definition in Section 1.2 says "Native Address" is a *network* address, whereas from the subsequent text it becomes clear that with "Native IP Address" you want to designate a *transport* address, that is the triple consisting of an IP address, a selector for the transport protocol, and the transport protocol port number at that IP address (with default values for protocol and port that can be omitted). "Transport address", or colloquially, "socket" is the standing term in the IETF to designate the communication endpoint where an application (protocol) interfaces with the standard Internet Protocol suite, and it should be your goal to map the generic term from C12.22 to the established Internet terminology that you want to make use of, isn't it? > Native IP Address is also a Definition in this RFC that scopes its > use to an IP Network. But in this paragraph that aims at introducing this term, you can't also use it on the RHS of the definition, or it will become recursive and thus not useful. And yes, in the scope of an IP network you need a "transport address" for an application endpoint. Maybe the problem is that the term "network" has a generic, layer- agnostic meaning and a specific meaning: the IP layer bridging the underlying subnetworks (physical and virtual link layers). When used in combination with "address", IETF participants and most RFC readers will assume the latter meaning; but that's not what I assume that you want to do here. >> [...] > > >> (B.10) Section 2.6, 2nd-to-last para -- major concern >> >> The draft says: >> >> In the implementation of this technique, an administrative domain >> MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in >> the administrative domain SHOULD be configured with a TTL >> | sufficiently large to reach that C12.22 IP Relay. A TTL threshold >> | SHOULD be defined and configured on all border routers linking the >> | administrative domain to the global Internet such that the routers >> | forward on their Internet interfaces only those 224.0.2.4 multicast >> | packets that have a TTL exceeding the threshold value. >> >> This is an architecturally insane recommendation. Routers decrement the >> TTL / Hop Count field on the "fast path" -- frequently with dedicated >> hardware support. This protocol cannot expect to be successful in >> requiring a new kind of TTL / Hop Count processing by major (boundary) >> routers. The only property of TTL / Hop Count that routers should >> remain interested in is whether it counts down to zero. >> The GTSM (RFC 5082) purposely restricts checking of *lower* bounds >> for TTL / Hop Count to the communicating end systems (notwithstanding >> the case where the relevant end systems are routers themselves). >> >> Therefore, IMHO the advice given here is not a good idea. >> An application protocol should not request changes to on-path routers. > > Although I agree with you, this was introduced by another DISCUSS. > See RFC 2365 on Administratively Scoped IP Multicast. IIRC, that is based on counting TTL to 0 or address scope recognition, not on ensuring a lower bound on the TTL in packets being forwarded. NB: Routers typically are not aware of the transport protocol port usage and therefore, even if they implemented the mechanism suggested in the document, would not know to which packets this rule needs to be applied. > The practice in this area is not very clear or clean. Agreed. Relying on such router behavior will, at best, severely impede the deployment of your proposal. >> (B.11) Sections 2.7 and 2.8 -- major concern >> >> Section 2.7 (and other parts of the memo) discuss, and seem to >> encourage, the use of IPv4 network directed broadcast. >> Since since the pervasive use of CIDR the prefix length of subnets >> essentially only is known within confined administrative domains, >> and knowledge of the addressing structure should not be imposed >> on routers other than those at the prefix [de-]aggregation point >> in the network topology, this seems to be a ppor advice as well. >> > The RFC does not have a position and does not encourage the use of > IPv6 nor IPv4. It does not care. > The RFC simply documents the encoding when used. > >> Section 2.8 of the draft says (4th paragraph): >> >> The IPv4 network directed broadcast address can be computed by >> performing a bitwise OR between the bit complement of the subnet mask >> of the target IP subnet and the IP address of any host on that IP >> subnet. >> >> .... but it does not say where the knowledge of the subnet mask should >> be derived from for non-local (i.e. other that on-link) subnets. > > The source and the means by which the knowledge can be obtained was > intentionally omitted. > This is a system implementation / operating system specific concern. > How it is handled internally by the software/firmware is outside the scope > of the RFC. See BCP 34 for the reasoning why directed broadcast has essentially become moot since CIDR has been introduced. It only could make sense inside a tightly controlled management domain, but it simply will not work (any more) on the Internet. >> Note that 11 years ago, RFC 2644 (BCP 34) has changed the default >> for router support of directed broadcast; it also says: >> >> Network service providers and corporate network operators are urged >> to ensure their networks are not susceptible to directed broadcast >> packets originating outside their networks. >> >> Thus, it looks like Internet-wide use of directed broadcast cannot >> be achieved anyway. Recommending its use does not make sense for >> new applications. >> > This RFC does not recommend the use of broadcast. It recommends the > use of multicast. It has proven a good principle of protocol design to not introduce brittle mechanisms that are not expected to be useful, ab initio. So my stance is that adding complications to implementations that only make (very limited) sense in the IPv4 world does not buy. > >> Furthermore, IMO the document should be much more aware of IPv6 >> and not recommend to explore niches of IPv4 no more present in IPv6; >> therefore, I'd strongly suggest to drop broadcast support entirely >> from the document. IP multicast, if properly used, offers scoping. >> with architectured mechanisms. > > This RFC documents existing implementations and describes what is > being done and how it is encoded. > > It tried very hard to remain in that realm. There's no need to specify *all* features of existing implementations in such a document if it's clear that these are of very questionable utility and subsequent implementation would be simplified and furthered by leaving out these additional unnecessary complications. > > >> (B.12) Section 2.8, Figure 2 -- major concern >> >> The whole figure seems to be misleading and overly complicated. >> Most likely the changes applied to arrive at the current Section 2.3 >> have been applied thoughtlessly as well: >> >> IP Multicast and Broadcast does not support connection-oriented >> transport. Thus, in this case, the only possible transport protocol >> supported by this specification is UDP. >> However, according to the 1st para of Section 2.3, an absent "T" >> element in the Native Address encoding means TCP _and_ UDP ! >> >> Thus, for conformance with Section 2.3, the 6 variants (of 9) >> in Figure 2 that do not contain the "T" field are inappropriate >> and should be deleted entirely. >> >> Getting rid of IPv4 Broadcast (as recommended above) will drop the >> first remaining choice as well and leave a single representation >> each for IPv4 and IPv6. > > At first glance I was tempted to say that you are correct about the > interpretation of no "T" field in Figure 2. > > However, the absence of the "T" (as documented in Section 2.3 "... or not > set (absent) for both UDP+TCP transports") should be interpreted as "any of > TCP or UDP as appropriate". > In the case of sending a unicast APDU then if the target supports TCP and > UDP and then the originator may use TCP or UDP to push the message. > In the case of sending a multicast APDU then if the target supports TCP and > UDP and the message should use UDP (of course) to send the multicast > message. > The responses, however, come back as unicast in accordance with the rules > stated in this RFC and the T flag. > > Clearly if one wishes to communicate using TCP and via Multicast they should > go back to school. > > Also However, getting rid of Broadcast is going too far. Why? Using the allocated multicast addresses is functionally equivalent to broadcast in the domain where it is expected to work in IPv4: on-link; so you wouldn't use any functionality, and you have no choice of multicast in IPv6. So why unnecessarily implement feature use specific to IPv4 at the *application* layer that will not work any more in IPv6, which is the only feasible environment for such project with the huge count of expected network nodes. Furthermore, in switched Ethernet fabrics (with IGP/MLD snooping switches), multicast is more efficient than link layer broadcast. >> [...] > > >> (B.15) Section 3.2.1 (ff.) -- major concern >> >> The recommendations given there seem to be in conflict with >> RFC-to-be 6056 (BCP 156) on Transport Protocol Port Randomization. >> The recommendation given there in focor of the use of fixed port >> numbers as far as possible opens an avenue for spoofing attacks. >> >> In the past, the IETF has changed important, also symmetrically >> behaving protocols -- most importantly: BCP-4 -- with regard to such >> concerns, to get rid of the usage of a fixed port number on the side >> of the peer performing the Active Open, and to use the connection, >> once established, in a symmetrical manner, irrespective of the >> asymmetry of port number usage in the underlying transport layer. >> >> Similarly -- as an example for an UDP-based service -- the DNS >> recommendations have been changed in favor of the use of randomized >> source port numbers. >> >> I do not see a necessity to weaken the protocol described here by >> forcing it to once more use practices that have been recognized as >> poor many years ago. >> >> Thus, IMHO, Section 3.2.1 needs a deep reconsideration. >> >> This extends to the rule in the last paragraph of Section 3.2.2 >> and a couple of other places in the text. > > Your concern was reviewed and considered and addressed already in the RFC. > > In peer-to-peer communication between IP Nodes port randomization is > allowed in this RFC (see section "TCP and UDP Port Use" > item 5. "When the target UDP C12.22 IP Node is reachable using direct > messaging (as defined in [1] the C12.22 IP Node MAY set the > source port number to a UDP port number that is different than its > registered port number". > > However C12.22 can and will span across non IP Network Segments. In this > case using source port randomization can and will break the larger C12.22 > Network. > i.e. The span of the Smart Grid and C12.22 is greater than just the IP > Network. Maybe I'm missing something; but by your definition and usage of the encoding of "native IP addresses" you already have the base to handle arbitrary source addresses of peers performing active open. Simply (re-)use these transport associations once they have been established. I'd suggest that you take a look at how this has been solved in BGP-4 when the specification has been updated to RFC 4271 -- the predecessor had similar preferences to fixed port numbers and was the subject of serious concerns. Similarly, RFC 5452 clearly says "don't use port 53 with DNS active open, use random port numbers" (it doesn't use that former term, but it says the same in other words). > [...] > > Many Many Thanks for your input. > > Avy > > </snip> Thanks for your cooperation and responsiveness as well, even in this unusually late stage! Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx | +------------------------+--------------------------------------------+ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf