AD Review of IP over Ethernet over [draft-ietf-16ng-ip-over-ethernet-over txt] IETF-72, Dublin, July ‘08 Max Riegel (NSN), Sangjin Jeong (ETRI), Hongseok Jeon (ETRI)

Status draft-ietf-16ng-ip-over-ethernet-over txt was published on April 4th incorporating a couple of refinements out of the second WG LC The I-D was forwarded to IESG end of June. Jari Arkko came back with a detailed list of review comments on July 7th. The following slides are listing the comments and the proposed remedies of the authors. –Response of authors was send to the [16ng] list on Jul 20th. Updated I-D will be published after IETF-72 incorporating the remedies.

General comment AD: Overall, there are a number of issues or at least question marks. Not surprisingly the part of this document that defines how to carry IP over Ethernet in is in pretty good shape. But I do have multiple concerns about the way that this draft handles some of the optimizations related to IP layer behavior. For instance, some of the filtering rules seem more appropriate as operational suggestions than parts of the normative spec. There are inconsistencies with regards to IPv6 and redirects need to be handled. The centralized bridge model does not appear to be either necessary or sufficient to handle the task it was designed for. R:Your comments are valid concerns and will be addressed in the next revision of the document. But the main issue leading to the comments is the mixture of different deployment scenarios throughout the document. It is not easy to follow which of the statements are relevant for which of the deployment models. Furthermore the predominant deployment model 'Public Access' is a special case of the generic 'Enterprise LAN' model.

Comments #1 AD: Why was RFC 4605 used instead of RFC 4541? R: RFC 4541 is Informational, RFC 4605 is Standards Path. Making normative references to an Informational document is not appropriate, even if it would have been simpler. Being able to make normative references to RFC 4541 would make our task much easier. AD: What can this spec mandate about the behavior of hosts connected via a regular Ethernet and a bridge to the network? R: The spec can only mandate that the hosts connected to the Ethernet are following the generic specifications like RFC 894 and RFC 2464 for IP over Ethernet. And the spec has to mandate that the Ethernet over does behave like standard Ethernet, e.g. does not introduce any additional restrictions for the MTU size. Probably we missed to state the prerequisite very clearly in the I-D.

Comments #2 AD: One discussion that we should have is what parts of the document are operational advice on techniques that can be employed to reduce extra traffic, and what parts are fundamental parts of IP over /Ethernet without which no interoperability can be achieved. R:Fundamental parts are using 'MUST' statements, while operational advise is usually marked by 'SHOULD' statements. And operational hints are provided in two layers; hints for the generic deployment model and special hints for the public access scenario. The I-D adopted a functional approach and listed the operational hints for the generic case and the special case directly following the introduction of the function. We found that this mixture of generic case and special case is not working well, and a structure where all the generic statements are kept together clearly separated from the special statements for public access scenario may be much better to follow. We will change the structure of the I-D and split out all the special requirements for the public access scenario in a dedicated section after introducing the generic case. The new structure may look like: –Mandatory requirements for interoperability –Optimizations for the generic deployment case –Recommendations for the public access scenarios

I-D Restructuring current --> new 1. Introduction 2. Requirements 3. Terminology 4. The IEEE Link Model 4.1. Connection Oriented Air Interface 4.2. Feeding User Data into the Appropriate Connections 4.3. MAC addressing in IEEE Ethernet Network Model for IEEE IEEE Ethernet Link Model 5.2. Ethernet without Native Broadcast and Multicast Support 5.3. Deployment Scenarios for IP over Ethernet over IEEE Public Access Scenario Enterprise LAN Scenario 6. Network-side Bridge Considerations 6.1. IEEE Ethernet Link Model Considerations Public Access Scenario Case Enterprise LAN Scenario Case 6.2. Segmenting the Ethernet into VLAN 6.3. Multicast and Broadcast Packet Processing Multicast Transmission Considerations Broadcast Transmission Considerations 6.4. Proxy ARP Public Access Scenario Case Enterprise LAN Scenario Case 7. Access Router Considerations 8. Prefix Assignment 8.1. Public Access Scenario Case 8.2. Enterprise LAN Scenario Case 9. Transmission of IP over Ethernet 9.1. IPv4 over Ethernet Address Configuration Address Resolution 9.2. IPv6 over Ethernet Router Discovery, Prefix Discovery and Parameter Discovery Address Configuration Address Resolution 9.3. Maximum Transmission Unit Consideration 10. IANA Considerations 11. Security Considerations 12. … 1. Introduction 2. Requirements 3. Terminology 4. The IEEE Link Model 4.1. Connection Oriented Air Interface 4.2. Convergence Sublayer 4.3. MAC addressing in IEEE Ethernet Network Model for IEEE IEEE Ethernet Link Model 5.2. Segmenting the Ethernet into VLAN 5.3. Ethernet without Native Broadcast and Multicast Support 6. Transmission of IP over Ethernet over IEEE IPv4 over Ethernet 6.2. IPv6 over Ethernet 6.3. Maximum Transmission Unit Consideration 7. Operational Enhancements 7.1. Network-side Bridging Considerations Bridging Topology Multicast Transmission Broadcast Transmission 7.2. IPv4 Operation Proxy ARP DHCP optimizations 7.3. IPv6 Operation Router Advertisements 8. Public Access Recommendations 8.1. Bridging behavior 8.2. Broadcast Transmission 8.3. Prefix Assignment 8.4. Proxy ARP 8.5. Access Router Considerations 9. IANA Considerations 10. Security Considerations 11. …

Comments #3 >> Those IP specific support >> functions are preferably realized in a centralized device containing >> a bridge for aggregation of traffic from all the BSs to provide a >> more straightforward management solution and allow for effectively >> commoditized BSs, which may be deployed in the IEEE based >> access network in a large volume. >> The IEEE Ethernet >> link model MUST interconnect each point-to-point connections assigned >> to SSs at a centralized point, a.k.a. network-side bridge, as shown >> in Figure 2. This is equivalent to today's switched Ethernet with >> twisted pair wires connecting the hosts to a bridge ("Switch"). The >> single and centralized network-side bridge allows best control of the >> broadcasting forwarding behavior and prevents potential security >> threats coming up with cascaded bridges. AD: This appears to be an implementation consideration this is inappropriate for an IETF IP over Foo specification. (See also below on my comments on Appendix B.) R:It looks like an implementation consideration, but it is not. As mentioned in both, the first sentence taken from the introduction and the later sentence in the second paragraph, there is functional reason to co-locate all the forwarding decisions of a switched LAN (bridging function) in a single device. The real issue with the statement above is the 'centralized point'. Such wording is inappropriate for a MUST requirement. Better: The IEEE Ethernet link model MUST interconnect each point-to-point connections assigned to SSs by a network-side bridging function, as shown in Figure 2."

Comment #4 >> IEEE g [802.16g] defines a GPCS (Generic Packet Convergence >> Sublayer), which may be used to transfer Ethernet frames over IEEE >> as well. AD: s/may be used to transfer/may be used by future specifications to define how to transfer/ R:There is no need for future specifications to deploy GPCS for IPoETHo GPCS can be used for transferring ETH frames as well as native IP packets (as well as PPP and MPLS) over When carrying Ethernet, GPCS is interoperable with ETH CS as it uses the same packet formats over the air as ETH CS. The difference is the non-existence of classification rules for GPCS, i.e. it is not defined by IEEE by which filtering of packet headers payload packets are assigned to particular service flows. IMHO, the proposed change is not appropriate. We will add explicit statement that the I-D applies to GP-CS as well.

Comment #5 >> In the Public Access scenario, direct communication between nodes is >> restricted because of security and accounting issues. AD: And presumably mere volume of traffic as well? R:Traffic volume is usually not an issue when the operator is able to charge for it. Enforcing that all traffic is passing through the control point of the operator ensures that all packets are accounted. >> Public Access Scenario Case >> >> The network-side bridge SHOULD forward all packets received from any >> lower side ports to all upper side ports being in the forwarding >> state. Direct communication between SSs SHOULD NOT be supported by >> the network-side bridge and all packets sent from a SS to the BS >> SHOULD be delivered to an AR. AD: The document comes across as a very system oriented. This is unusual for an IETF IP over Foo specification, and I suspect that over time we'll regret too tight bindings to particular deployment situations. I think the spec would be better recast as a the key IP over /Ethernet, followed by a set of recommendations for different situations. You can even specify cleanly separated optional functions (such as preventing direct communication) that deployers can choose to use in a particular situation. R:The description is addressing different aspects particular to a deployment model. The description will fit much better into the 'Recommendations for public access' part of the new structure.

Comment #6 >> All multicast and multicast control messages SHOULD be processed in >> the network-side bridge according to [RFC4605]. AD: I would like to understand the decision to use 4605 instead of 4541 which seems more suited to bridged environment. R:RFC 4541 is Informational. RFC 4605 is Standard. Making normative statements to Informational RFCs looked not appropriate to us. >> The IEEE Ethernet link model in Section 5.1 has a basic tree >> topology and [RFC4541] provides an application guide how bridge, >> non-IP device, to examine and learn group membership. Hence, >> [RFC4605] can be applied to the IEEE Ethernet link model to >> reduce the multicast packet flooding. >> >> The network-side bridge in the IEEE Ethernet link model SHOULD >> play a role in proxying IGMP/MLD messages as specified in [RFC4605]. >> The network-side bridge SHOULD perform the host portion of IGMP/MLD >> process on its upper side port and the router portion of IGMP/MLD >> process on its all lower side ports. AD: I do not understand how the first paragraph can state that bridges are non-IP devices and then the second paragraph goes on to talk about the application of IP layer processes such as acting as a host. R: Agreed. The challenge is to define a system by normative statements based on RFC 4605 to resemble the behavior of RFC The most easy solution would be a normative statement to RFC 4541, but this may require special handling in the standards process.

Comment #7 >> The network-side bridge in the IEEE Ethernet link model SHOULD >> discard all IP broadcast packets except ARP, DHCP (DHCPv4 and >> DHCPv6), IGMP, and MLD related traffic. The ARP, DHCP, IGMP and MLD >> related packets SHOULD be forwarded with special rules specified in >> this specification. AD:This is inappropriate. First, you stated earlier that this Section (6.3) also applies to the enterprise deployment. In that environment, turning off broadcast may be inappropriate. R:You are right, and thanks for pointing to this mistake. We will revise the text to ensure that broadcast is not impacted for the generic case (Enterprise LAN scenario). AD:Secondly, i think you are mixing the specification of IP over Foo with a particular filtering requirement in a specific deployment. Its fine to state operational advice, but do not cast it as a part of the normative specification. R:The distinction between normative requirements and operational hints should become much clearer in the new structure. We will keep such operational hints in a separate section. >> Note that packets destined for permanently >> assigned multicast addresses such as /24 in IPv4 or FF02::1 in >> IPv6 are also regarded as broadcast data. AD:All permanently assigned addresses? Even all-routers, for instance? Be more specific. R:Thanks for showing the shortage. We will provide a more comprehensive description.

Comment #8 >> 6.4. Proxy ARP >> >> Proxy ARP provides a process where a device on the link between hosts >> answers ARP Requests instead of the remote host. In this >> specification, the Proxy ARP mechanism is used to force all traffic >> from hosts to the access router or to avoid broadcasting ARP Requests >> over the air depending on the particular deployment scenario. The >> Proxy ARP process is usually co-located with the network-side bridge. AD:Another part of the specification that should be cast as an operational advice of other techniques that can be used to combat excessive traffic? Please consider a separate section for these. R:Agreed. There is a mode of operation of Proxy ARP, which is applicable to all scenarios, and there is a special treatment of Proxy ARP in the public access scenario. We will separate the two aspects in different sections.

Comment #9 >> In the public access scenario, all packets between SSs will always be >> relayed via access router. In this scenario, the access router >> SHOULD forward packets via the same interface on which the access >> router received the packets, if the source and destination addresses >> are reachable on the same interface. This would result in a Redirect >> message from the access router [RFC0792][RFC4861]. The Redirect >> message MUST be suppressed. >> 8.1. Public Access Scenario Case >> >> Unique IPv6 prefix per SS SHOULD be assigned because it results in >> layer 3 separation between SSs and it forces all packets from SSs to >> be transferred to an AR. AD:If we are employing per-SS prefixes, what is the point of the Redirect discussion above? R:The redirect discussion applies to both IPv4 and IPv6. Unique prefixes per MS are only feasible for IPv6. The redirect requirements is a fall-back function when unique IPv6 prefixes are not deployed. We will restructure the statements making redirect and unique prefixes alternate solutions for IPv6.

Comment #10 >> In this >> specification, SSs perform above the discovery process by solicited >> Router Advertisement messages because periodic Router Advertisement >> messages are discarded on the network-side bridge following the >> Broadcast Data Forwarding Rules in Section AD:Hmm. Given that there can be regular Ethernet bridges and unaware hosts at the subscriber side, where does that leave hosts that are relying on RAs? (E.g., hosts complying with RFC 3775.) R:Thanks for bringing this up. The statements in section 9 must be converted into statements for network behaviors. As you mention, the host may not be aware of the IEEE connection on the link. >> Address Configuration >> SS SHOULD derive its global IPv6 addresses based on prefix and EUI- >> 64-derived interface identifier AD:And similar other sections. Again, given that this must work with regular Ethernet-attached hosts, to what extent are these statements useful? R:Normative language is not appropriate in this section, but it may be helpful to explain what is expected from hosts attached to the Ethernet. Nevertheless the whole section requires rewording to make clear, that only general IPv6 requirements can be asserted to hosts for IPoETHoIEEE AD:Also, this document should not make any recommendations on what particular address assignment mechanism should be employed (4862, 3041, etc). R:Agreed. We will take it into account when revising the text.

Comment #11 >> The Proxy ARP function described in Section 6.4 prevents that ARP >> broadcast messages have to be forwarded to each of the associated >> SSs, when the ARP proxy is aware of the existence of the queried IP >> address at one of the bridge ports. If the queried IP address is not >> known to the ARP proxy, the bridge has to flood all its ports with >> the ARP request. >> >> Distributing the bridging function into the BSs would imply that the >> Proxy ARP function is split into multiple Proxy ARP functions each >> knowing only about the subset of the IP addresses, which are directly >> connected by the BS. IP addresses belonging to the same link but >> being connected to other BSs would not be known to the Proxy ARP >> functions and would cause ARP requests for these IP addresses to be >> broadcast to all SSs. This causes a waste of radio resources for >> transmitting ARP requests and potentially more critical even, it >> would waste scarce battery power in the SSs. >> >> A malicious user would be able to deploy this behavior for denial of >> service attacks by exhausting the batteries of SSs by sending >> malicious ARP Requests. AD:First, the same malicious user can employ the same technique and still cause denial-of-service via ARP requests. All that he has to do is to select an address which is not on the link. According to your explanation above, this would be flooded to every port. R:You are right, the statement about the malicious user is wrong. Malicious ARP requests cant be defended just by a concentrated bridging function. We will remove the statement.

Comment #11 cont. AD: Second, if you really wanted to make this work, wouldn't flooding only to the upstream port achieve what you want to do, without requiring one centralized device? R:Flooding upstream means that the downstream bridge assumes that the upstream bridge has the queried IP address in its ARP cache. This is indeed likely when the cache is large enough to capture all the IP addresses used in the Ethernet. Essentially the upstream bridge acts as centralized Proxy ARP function. In the generic case (Enterprise LAN scenario) there is no upstream port and the AR may reside on any of the port. The preference for a centralized bridging function arises out of the generic scenario, where no indication is available about the position of the AR. Indeed there is not much difference between concentrated and distributed bridging for the public access scenario when there is a proxy ARP function upstream able to capture all the MAC-IP-address associations. We think, a more comprehensive description of the issues of particular bridging topologies for the Net-bridge may be helpful.

Editorials AD:Term PKM used before expanded or introduced. R:o-.k. >> The IEEE standards define a packet CS (Convergence Sublayer) >> for interfacing with all packet-based protocols. IEEE g >> [802.16g], also, specifies a generic packet CS to provide an upper- >> layer protocol independent interface. This document describes >> transmission of IPv4 over Ethernet as well as IPv6 over Ethernet via >> the CSs in the IEEE based access network. AD:This paragraph is confusing. I cannot tell what CS you are using. I think you are using the Ethernet CS, but the paragraph fails to mention this. R:o.k. This paragraph gets more clear text about ETH-CS and the applicability of the GP-CS. >> forwarding of packets over the air is performed >> only on base of the CID value AD:s/base/based/ R:‘only based on the CID value’, o.k. >> This is beneficial when Ethernet frames with arbitrary >> MAC addresses have to be forwarded to a SS in the case that the SS is >> interconnected to another network. AD:s/.../This is required for bridging./ R:o.k. >> This document does not introduce new vulnerability to operations of AD:any new vulnerabilities? the operations? R:This is not an editorial; the statement requires more explicit wording. >> services suffers from several following drawbacks. AD:from the following drawbacks R:o.k.

Conclusion The AD review brought up two major deficiencies of the I-D: –Overall structure mixing interoperability with operation with particular deployment models –Being not clear that host may not be aware of IEEE on the link I-D has to be revised adopting a more clear structure and keeping the role of the host agnostic to the IEEE link –also addressing the other issues found in the review.