Hi all,

This is only a preliminary version of my AD review, for a couple of 
reasons. I had many questions, and I wanted to voice them as soon as 
possible. I'm on vacation and didn't have enough time to go back and 
look at the WG discussions for the rationale of various design 
decisions, and since this e-mail is being written in an airplane, I did 
not have the possibility of calling the authors or chairs for 
clarification. Finally, as the public network scenario in this document 
resembles DSL, I wanted to show this spec to my co-AD who is an expert 
on DSL.

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 802.16 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 behaviour. 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. Why was RFC 4605 used instead of RFC 4541? What can this 
spec mandate about the behaviour of hosts connected via a regular 
Ethernet and a bridge to the 802.16 network?

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 802.16/Ethernet 
without which no interoperability can be achieved.

Detailed comments below.

Technical:

> 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 802.16 based
> access network in a large volume.
> The IEEE 802.16 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.

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.)

>    IEEE 802.16g [802.16g] defines a GPCS (Generic Packet Convergence
>    Sublayer), which may be used to transfer Ethernet frames over IEEE
>    802.16 as well.

s/may be used to transfer/may be used by future specifications to define 
how to transfer/

> In the Public Access scenario, direct communication between nodes is
> restricted because of security and accounting issues.

And presumably mere volume of traffic as well?

> 6.1.1. 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.

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 802.16/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.

> All multicast and multicast control messages SHOULD be processed in
> the network-side bridge according to [RFC4605].
I would like to understand the decision to use 4605 instead of 4541 
which seems more suited to bridged environment.

> The IEEE 802.16 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 802.16 Ethernet link model to
> reduce the multicast packet flooding.
>
> The network-side bridge in the IEEE 802.16 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.

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.

> The network-side bridge in the IEEE 802.16 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.
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.

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.

> Note that packets destined for permanently
> assigned multicast addresses such as 224.0.0/24 in IPv4 or FF02::1 in
> IPv6 are also regarded as broadcast data.
All permanently assigned addresses? Even all-routers, for instance? Be 
more specific.

> 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.
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.

> 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. 

If we are employing per-SS prefixes, what is the point of the Redirect 
discussion above?

> 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 6.1.2.

Hmm. Given that there can be regular Ethernet bridges and 802.16 unaware 
hosts at the subscriber side, where does that leave hosts that are 
relying on RAs? (E.g., hosts complying with RFC 3775.)

> 9.2.2. Address Configuration
> SS SHOULD derive its global IPv6 addresses based on prefix and EUI-
> 64-derived interface identifier

And similar other sections.

Again, given that this must work with regular Ethernet-attached hosts, 
to what extent are these statements useful?

Also, this document should not make any recommendations on what 
particular address assignment mechanism should be employed (4862, 3041, 
etc).

>    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.

First, the same malicious user can employ the same technique and still 
cause denia-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.

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?

Editorial:

Term PKM used before expanded or introduced.

> The IEEE 802.16 standards define a packet CS (Convergence Sublayer)
> for interfacing with all packet-based protocols.  IEEE 802.16g
> [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 802.16 based access network.
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.

> forwarding of packets over the air is performed
> only on base of the CID value
s/base/based/

> 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.

s/.../This is required for bridging./

> This document does not introduce new vulnerability to operations of

any new vulnerabilities?

the operations?

>    services suffers from several following drawbacks.
from the following drawbacks

Jari


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www.ietf.org/mailman/listinfo/16ng