Network Working Group D. Mitzel Request for Comments: 3002 Nokia Category: Informational December 2000 Overview of 2000 IAB Wireless Internetworking Workshop Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community. Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list. 1 Introduction . . . . . . . . . . . . . . . . . . . . 3 2 Presentation Overview . . . . . . . . . . . . . . . . 4 3 Discussion and Observations . . . . . . . . . . . . . 9 3.1 Discussion on "Walled Garden" Service Model . . . . . 9 3.2 Discussion on Mobility and Roaming . . . . . . . . . 10 3.2.1 Discussion on Mobility and Roaming Model . . . . . . 11 3.2.2 Discussion on Mobility and Roaming Protocols . . . . 11 3.2.3 Discussion on Mobility and Roaming Services . . . . . 12 3.3 Discussion on Security Model . . . . . . . . . . . . 12 3.3.1 Discussion on User Identity . . . . . . . . . . . . . 12 3.3.2 Discussion on WAP Security . . . . . . . . . . . . . 13
3.3.3 Discussion on 3G Network Security . . . . . . . . . . 13 3.4 Discussion on Transports . . . . . . . . . . . . . . 14 3.4.1 Discussion on Link Characteristics and Mobility Effect on Transport . . . . . . . . . . . . . . . . . 14 3.4.2 Discussion on WAP Transport . . . . . . . . . . . . . 16 3.4.3 Discussion on IETF Transport Activities . . . . . . . 16 3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing Policy. . . . . . . . . . . . . . . . . 17 3.6 Discussion on QoS Services . . . . . . . . . . . . . 18 3.6.1 Discussion on "Last Leg" QoS . . . . . . . . . . . . 18 3.6.2 Discussion on Path QoS Discovery . . . . . . . . . . 19 3.7 Discussion on Header Compression . . . . . . . . . . 20 3.8 Discussion on Applications Protocols . . . . . . . . 21 3.9 Discussion on Proxy Agents . . . . . . . . . . . . . 22 3.10 Discussion on Adoption of IPv6 . . . . . . . . . . . 22 3.11 Discussion on Signaling . . . . . . . . . . . . . . . 23 3.12 Discussion on Interactions Between IETF and Other Standards Organizations . . . . . . . . . . . . . . . 24 4 Recommendations . . . . . . . . . . . . . . . . . . . 25 4.1 Recommendations on Fostering Interaction with Non- Internet Standards Organizations . . . . . . . . . . 25 4.2 Recommendations for Dealing with "Walled Garden" Model . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Recommendations on IPv4 and IPv6 Scaling . . . . . . 27 4.4 Recommendations on IPv4 and IPv6 Mobility . . . . . . 28 4.5 Recommendations on TCP and Transport Protocols . . . 29 4.6 Recommendations on Routing . . . . . . . . . . . . . 31 4.7 Recommendations on Mobile Host QoS Support . . . . . 32 4.8 Recommendations on Application Mobility . . . . . . . 33 4.9 Recommendations on TCP/IP Performance Characterization in WAP-like Environment . . . . . . . . . . . . . . . 33 4.10 Recommendations on Protocol Encoding . . . . . . . . 33 4.11 Recommendations on Inter-Domain AAA Services . . . . 34 4.12 Recommendations on Bluetooth . . . . . . . . . . . . 34 4.13 Recommendations on Proxy Architecture . . . . . . . . 34 4.14 Recommendations on Justifying IPv6-based Solutions for Mobile / Wireless Internet . . . . . . . . . . . . . 35 5 Security Considerations . . . . . . . . . . . . . . . 35 6 Acknowledgments . . . . . . . . . . . . . . . . . . . 35 7 Bibliography . . . . . . . . . . . . . . . . . . . . 36 A Participants . . . . . . . . . . . . . . . . . . . . 41 B Author's Address . . . . . . . . . . . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . 42
+ Addressing requirements for wireless devices + Compression and bit error requirements for wireless networks The fundamental question addressed in these discussion is "what are the issues, and what really needs to be done to unify the Internet below the application layer." Applications will also need to be addressed, but were perceived to be more than could be usefully discussed in a three-day workshop, and probably require different expertise. Section 2 presents a concise overview of the individual presentations made during the workshop. References to more extensive materials are provided. Details on major discussion topics are provided in section 3. Section 4 presents the recommendations made to wireless operators, IRTF, and IETF on the architectural roadmap for the next few years. It should be noted that not all participants agreed with all of the statements, and it was not clear whether anyone agreed with all of them. However, the recommendations made are based on strong consensus among the participants. Finally, section 5 highlights references to security considerations discussed, appendix A lists contact information of workshop participants, and appendix B lists the author contact information. http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF, http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt Overview: Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running IP over IEEE 802.11? Presenter: Juha Ala-Laurila Reference: http://www.iab.org/IAB-wireless-work- shop/talks/IEEE80211_IP.ppt Overview:
Title: Overview of Bluetooth Wireless & Issues Running IP over Bluetooth? Presenter: Pravin Bhagwat Reference: http://www.iab.org/IAB-wireless-workshop/talks/BT- overview.PDF, http://www.iab.org/IAB-wireless-workshop/talks/BT- overview.ppt Overview: Title: Overview of Cellular Data Systems & Approaches to more IP centric Cellular Data System Presenter: Jonne Soinien Reference: http://www.iab.org/IAB-wireless-workshop/talks/ Cellular_JSo.PDF, http://www.iab.org/IAB-wireless-workshop/talks/ Cellular_JSo.ppt Overview: Title: IP Packet Data Service over IS-95 CDMA Presenter: Phil Karn Reference: http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm Overview: Title: Wireless Internet Networking Presenter: Chih-Lin I Reference: http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF, http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.ppt Overview: Title: Mobile IP in Cellular Data Systems Presenter: Charlie Perkins
Reference: http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF, http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.ppt Overview: Title: Overview of WAP Presenter: Alastair Angwin Reference: http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf Overview: Title: Mobile Wireless Internet Forum (MWIF) Presenter: Alastair Angwin Reference: http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC _Presentation.PDF, http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC _Presentation.ppt Overview: Title: Some WAP History Presenter: Jerry Lahti Reference: http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF, http://www.iab.org/IAB-wireless-workshop/talks/waphist.ppt Overview: Title: Near-space Wireless Applications Presenter: Mark Allman Reference: http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- wireless.pdf, http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- wireless.ps Overview:
Title: Air Traffic / Aviation Wireless Presenter: Chris Wargo Reference: http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF, http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.ppt Overview: Title: VoIP over Wireless Presenter: Christian Huitema Reference: http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- voip.PDF, http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- voip.ppt Overview: Title: Security Issues in Wireless Networks and Mobile Computing Presenter: N. Asokan Reference: http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- rity.PDF, http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- rity.ppt Overview: Title: Security for Mobile IP in 3G Networks Presenter: Pat Calhoun Reference: http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF, http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.ppt Overview: Title: On Inter-layer Assumptions (A View from the Transport Area) Presenter: Mark Handley
Reference: http://www.iab.org/IAB-wireless-workshop/talks/handley- wireless.pdf, http://www.iab.org/IAB-wireless-workshop/talks/handley-wire- less.ps Overview: Title: Does current Internet Transport work over Wireless? Presenter: Sally Floyd Reference: http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- Mar00.pdf, http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- Mar00.ps Overview: Title: QOS for Wireless (DiffServ, IntServ, other?) Presenter: Lixia Zhang Reference: http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- IAB.PDF, http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- IAB.ppt Overview: Title: Do current WWW Protocols work over Wireless and Small Screen Devices? Presenter: Gabriel Montenegro Reference: http://www.iab.org/IAB-wireless-workshop/talks/wireless- www.PDF, http://www.iab.org/IAB-wireless-workshop/talks/wireless- www.ppt Overview: Title: Compression & Bit Error Requirements for Wireless Presenter: Mikael Degermark
Reference: http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF, http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt Overview: Title: Addressing Requirements for Wireless Devices & IPv6 Presenter: Bob Hinden Reference: http://www.iab.org/IAB-wireless-workshop/talks/Addressing- IPv6.PDF, http://www.iab.org/IAB-wireless-workshop/talks/Addressing- IPv6.ppt Overview: sections 3.1 -- 3.12 summarize these discussion and observations. Rather than organizing the material linearly by presentation, it is grouped according to common "themes" and issues.
Additionally, specification typically define a standalone protocol or application rather than the set of features and interoperation with other components required to deploy a commercial service. Some discussion focused on whether cellular carriers could be persuaded to transition toward the Internet "open" service model. Responses indicated that there was little hope of this as carriers will always fight being reduced to a "bit pipe", fearing they cannot sustain sufficient revenues without the value added services. An additional point raised was that the closed model of the "walled garden" simplifies a number of issues, such as security, authorization, and billing when the entire network is considered secured and controlled under a single administration. These simplification can eliminate roadblocks to service deployment before scalable, interdomain solutions are available. Even though there seems little hope of evolving carriers away from the "walled garden" service in the short term, there was significant value in recognizing its presence. This led to observations that "walled garden" Internet-based services will operate somewhat like current intranet services. Also, mechanisms should be investigated to simplify interoperation and controlled access to the Internet. Finally, the difference between Internet protocol specification contrasted to service profiles highlights some of the confusion those in the telephony environment encounter when attempting to incorporate Internet capabilities. Much of the current work in extending Internet-based services to cellular customers has focused on data services such as email or web access. One observation on the reluctance of carriers to release any control over services was that this may be an impediment to adoption of Internet-based voice services. Current work on voice over IP (VoIP) and call signaling (SIP ) loosens control over these services, much of the functionality is moved into the SIP agent with the carrier being reduced to an access provider (i.e., "bit pipe").
50], and there was disagreement on the point regarding slow handoff under mobile IP. Detriments to the cellular-based roaming include the lack of IP support out to the mobile device and the added tunneling protocols and overhead required. Additionally, roaming is less well defined when traversing service provider boundaries and may involve highly non-optimal forwarding path. There appears significant work remaining to reach convergence on opinions, and additional investigation to support roaming across cellular, WLAN, and IP boundaries.
47] and SLP , that may aid in developing location based services. However, there was considerable frustration on the part of 3G.IP in that there appears little commercial support of these protocols, and even less direction on how to assemble and coordinate the required protocols to deploy the desired services. This exchange illustrated the disconnect between interpreting Internet standards and telephony service profiles. First, in the Internet many protocols are defined but many are optional. Protocol support is typically driven by market demand, which can lead to "chicken and egg" problem. Secondly, individual protocols and applications are developed rather than complete profile to compose a commercial service. For this service, evaluating the usage and scalability of service discovery protocols appears to be an area open for further investigation.
A related topic revolves around the user desire to employ a single device but to take on a different identity and privilege based on the usage at hand (e.g., to gain corporate access, home access, or Internet access). The ability and ease of assuming these multiple identities may be highly dependent on the model of identity integration, as discussed above. Discussion highlighted potential pitfalls based on tieing of device and user identities. IPsec use of device IP address inhibits roaming capabilities as the address may change based on location, and precludes distinguishing identity and capabilities for current usage. IPsec requires additional work to accommodate this added flexibility. A final topic of discussion on user identity establishment was whether possession of the device is sufficient, or whether the user should be required to authenticate to the device. In the real world the first alternative is exemplified by the credit card model, while the second is more analogous to the ATM card where the user must also provide a PIN code. Both models seem useful in the real world, and it's likely both will have uses in wireless networking. 20], with optimized handshake to allow frequent key exchange. The security service employs a "vertical" integration model, with protocol components throughout the network stack. Some argued that this is the wrong model. A better approach may have been a security layer with well defined interfaces. This could allow for later tradeoffs among different protocols, driven by market, applications, and device capabilities. Additional statements argued that the WAP security model illustrates dangers from optimizing for a limited usage domain ("walled garden"). Content provider systems requiring security (e.g., banks) must deploy a special WAP proxy, which breaks the model of a single WAP "domain". Similar issues are inherent in gatewaying to the Internet.
Future 3GPP and 3GPP2 plan to push IP all the way out to the wireless device. An observation is that this results in more potential for exposure of signaling and control plane to attacks. Desire is to perform mutual authentication and securing of the network. This is a difficult problem with additional issues remaining to be solved; however the statement was made that relying on IP and open standards is more likely to produce a provably secure network than former reliance on SS7 protocols and obscurity. Completing support for the security requirements of the 3GPP/3GPP2 network seems to require resolving issues in two primary areas, AAA services and mobile IP. AAA is required for authentication, authorization, and billing. Remaining issues center around cross domain AAA, authentication using PKI, and there was considerable aversion to use of IPsec and IKE protocols due to perceived overhead and delay. Mobile IP issues revolve around solutions to reduce the security associations required between mobile node and home agent, mobile node and foreign agent, and the home and foreign agent. An interim solution being investigated involves use of a RADIUS server ; however, there are concerns with repeated dynamic key generation on each handoff or hiding some details of handoffs, which may violate assumptions in mobile IP protocol . Evaluating requirements and addressing all of these open issues appears to be an excellent opportunity for mutual cooperation on open standardization and review. 4]. This may not be true for all wireless media, but it was interesting in the fact that it indicates
TCP should work properly on many wireless media. However, the amount of discussion and suggestions on TCP performance optimizations showed that there can be a considerable gap between merely working and working well. One issue raised several times was related to the effects of non- congestive loss on TCP performance. In the wireless environment non-congestive loss may be more prevalent due to corruption loss (especially if the wireless link cannot be conditioned to properly control error rate) or an effect of mobility (e.g., temporary outage while roaming through an area of poor coverage). These losses can have great detrimental effect on TCP performance, reducing the transmission window and halving the congestion window size. Much of the discussion focused on proposing mechanisms to explicitly indicate a non-congestive loss to the TCP source. Suggestions included a Non-Congestive Loss Indication (NCLI) sent for instance when packet corruption loss is detected, or sending a Source Encourage (SE) to stimulate source transmission at the end of an outage. In addition to data corruption, wireless links can also experience dropouts. In this situation any active TCP sessions will commence periodic retransmissions, using an exponentially increasing back-off timer between each attempt. When the link becomes available it may be many seconds before the TCP sessions resume transmission. Mechanisms to alleviate this problem, including packet caching and triggered retransmission were discussed. The more generic form of all of these mechanisms is one that allows the state of the layer two (datalink) system to signal to the TCP session its current operating mode. Developing a robust form of such a signaling mechanism, and integrating these signals into the end-to-end TCP control loop may present opportunities to improve TCP transport efficiency for wireless environments. TCP improvements have been incorporated to support "long" links (i.e., those with large delay and bandwidth characteristics) , however considerable expertise may still be required to tune socket buffers for maximum performance. Some work has been done on auto- tuning buffers, which shows promise . An additional problem with large windows and auto-tuning is the added header overheads. This may exasperate the problems of running TCP over low bandwidth links. Suggestions included to explore dynamic negotiation of large window extensions in the middle of a connection to alleviate these issues. A final issue raised with regardport (see discussion below in section 3.4.3). There was also concern regarding mobility effects on TCP performance. TCP has implicit assumptions on bounding propagation delay. If delay exceeds the smoothed round trip time plus four times the round trip variance then the segment is considered lost, triggering the normal
backoff procedures. Could these assumptions be violated by segment loss or duplication during handoff? Work on D-SACK  may alleviate these worries, detecting reordering and allowing for adaptive DUP-ACK threshold. Finally, there was suggestion it might be appropriate to adapt (i.e., trigger slow start) immediately after mobile handoff on the assumption that path characteristics may differ. 12]. WTP offers several classes of service ranging from unconfirmed request to single request with single reply transaction. Data is carried in the first packet and 3-way handshake eliminated to reduce latencies. In addition acknowledgments, retransmission, and flow control are provided. Discussion on WTP centered on assessing details on its operation. Although it incorporates mechanisms for reliability and flow control there was concern that it may miss critical or subtle transport issues learned through years of Internet research and deployment experience. One potential area for disaster appeared to be the use of fixed retransmission timers and lack of congestion control. This gave rise to suggestions that the IETF write up more details on the history and tradeoffs in transport design to aid others doing transport design work, and secondly that the IETF advocate that the congestion control is not optional when using rate adaptive transport protocols. The remaining discussion on WAP transport primarily focused on ways to share information. It was suggested that any result from WAPF study of TCP shortcomings that led to its rejection might be useful for IETF review as inputs for TCP modifications. Similar comments were raised on study of T/TCP shortcomings and its potential exposure to Denial of Service (DoS) attacks. It was also encouraged that the WAPF members participate in the IETF directly contribute requirements and remain abreast of current efforts on evolving TCP operation and introduction of new transport (see discussion below in section 3.4.3.).
sharing of related TCP connection state [3,4,5,6,24,25,43,53,63]. Work on new transports includes SCTP  in the IETF Signaling Transport (sigtran) working group and TCP-Friendly Rate Control (TFRC)  by researchers at ACIRI. SCTP provides a reliable UDP- like protocol supporting persistent associations and in-order delivery with congestion control. TFRC is targeted at unreliable, unicast streaming media. Finally, work in the IETF End-point Congestion Management (ecm) working group is looking at standardizing congestion control algorithms, and work in the Performance Implications of Link Characteristics (pilc) working group is characterizing performance impacts of various link technologies and investigating performance improvements. This vast array of ongoing research and standards development seemed a bit overwhelming, and there was considerable disagreement on the performance and applicability of several TCP extensions. However, this discussion did raise a couple of key points. First, transport work within the Internet community is not stagnant, there is a significant amount of interest and activity in improvement to existing protocols and exploration of new protocols. Secondly, the work with researchers in satellite networking has demonstrated the tremendous success possible in close collaboration. The satellite networking community was dissatisfied with initial TCP performance on long delay links. Through submission of requirements and collaborative investigation a broad range of improvements have been proposed and standardized to address unique characteristics of this environment. This should hopefully set a very positive precedent to encourage those in the wireless sector to pursue similar collaboration in adoption of Internet protocols to their environment.
of multiple ground and space-based access networks), requiring routing policy support for path selection. Finally, QoS path selection capabilities may be beneficial to arbitrate shared access or partition real-time control traffic from other data traffic. Initial prototype of ATN capabilities have been based on ISO IDRP  path selection and QoS routing policy. There was some discussion whether IDRP could be adopted for use in an IP environment. There was quick agreement that the preferred solution within the IETF would be to advance BGP4++ [8,54] as an IDRP-like replacement. This transitioned discussion to evaluation of ATN use of IDRP features and their equivalent to support in BGP. Several issues with BGP were raised for further investigation. For example, whether BGP AS space is sufficient to accommodate each aircraft as an AS? Also issues with mobility support; can BGP provide for dynamically changing peering as point of attachment changes, and alternative path selection policies based on current peerings? A significant amount of additional investigation is required to fully assess ATN usage of IDRP features, especially in the QoS area. These could lead to additional BGP requirements, for instance to effect different prioritization or path selection for aircraft control vs. passenger entertainment traffic.
call control element (SIP agent ) "program" the edge router. This tradeoff seemed to be an area open for additional investigation, especially given the complications that may be introduced in the face of mobility and roaming handoffs. This appears a key component to solve for success in VoIP adoption. Work within the IEEE 802.11 WLAN group identified similar requirements for QoS support. That group is investigating a model employing two transmission queues, one for realtime and one for best-effort traffic. Additional plans include mapping between IP DiffServ markings [14,46] and IEEE 802 priorities. The statement was also made that QoS over the wireless link is not the fundamental problem, rather it is handling mobility aspects and seamless adaptation across handoffs without service disruption. There were concerns about mechanisms establishing per-flow state (RSVP ). Issues include scaling of state, and signaling overhead and setup delays on roaming events. DiffServ  approach allows allocating QoS for aggregate traffic class, which simplifies roaming. However, DiffServ requires measurement and allocation adjustment over time, and policing to limit amount of QoS traffic injected.
alternative is to push capability exchange and negotiation to the application layer. Discussion on this topic was brief, as application issues were deemed outside the workshop charter, however this also seems an area open for future investigation. 52,19], UDP , and RTP ) requires a minimum of 40 bytes of headers for IPv4 or 60 bytes for IPv6 before any application payload (e.g., 24 byte voice sample). This overhead was also presented as a contributing factor for the creation of WAP Wireless Datagram Protocol (WDP) rather than IP for very low datarate bearers. Discussion on header compression techniques to alleviate these concerns focused on work being performed within the IETF Robust Header Compression (rohc) working group. This working group has established goals for wireless environment, to conserve radio spectrum, to accommodate mobility, and to be robust to packet loss both before the point where compression is applied and between compressor and decompressor. Additional requirements established were that the technique be transparent, does not introduce additional errors, and that it is compatible with common protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP). The primary observation was that this problem is now largely solved! The working group is currently evaluating the ROCCO  and ACE  protocols, and expects to finalize its recommendations in the near future. It was reported that these encodings have a minimum header of 1 byte and result in average overhead of less than 2 bytes for an RTP/UDP/IP packet. There is some extra overhead required if transport checksum is required and some issues still to be analyzed related to interoperation with encryption and tunneling. A detriment to IPv6 adoption often cited is its additional header overhead, primarily attributed to its larger address size. A secondary observation made was that it's believed that IPv6 accommodates greater header compression than IPv4. This was attributed to the elimination of the checksum and identification fields from the header. Discussion on use of WWW protocols over wireless highlighted protocol encodings as another potential detriment to their adoption. A number of alternatives were mentioned for investigation, including use of a "deflate" Content-Encoding, using compression with TLS , or
Bellovin's TCP filters. Observation was made that it could be beneficial to investigate more compact alternative encoding of the WWW protocols. 23], however WSP incorporates several changes to address perceived inefficiencies. WSP uses a more compact binary header encoding and optimizations for efficient connection and capability negotiation. Similarly, the WAP Wireless Application Environment (WAE) uses tokenized WML and a tag- based browser environment for more efficient operation. Additional requests for more efficient and compact protocol encodings, and especially improved capability negotiation were raised during discussion on usage of WWW protocols with wireless handheld devices. Finally, work within the near-space satellite environment has pointed out other physical limitations that can affect performance. In this case the long propagation delays can make "chatty" protocols highly inefficient and unbearable for interactive use. This environment could benefit from protocols that support some form of "pipelining" operation. There seemed broad agreement that many of these observations represent valid reasons to pursue optimization of protocol operations. Investigation of compact protocol encoding, capability negotiation, and minimizing or overlapping round trips to complete a transaction could all lead to improved application performance across a wide range of environments.
specifying IPv6 as mandatory in the release 2000. The MWIF effort is also cognizant of IPv4 and IPv6 issues and is currently wrestling with their recommendations in this area. Although there was limited positive signs on IPv6 awareness, indication is that there are long fights ahead to gain consensus for IPv6 adoption in any of the 3G standards efforts. There was considerable feedback that the telephony carriers perceive IPv6 as more difficult to deploy, results in higher infrastructure equipment expenses, and adds difficulty in interoperation and gatewaying to the current (IPv4) Internet. Arguments for sticking with IPv4 primarily came down to the abundance and lower pricing of IPv4-based products, and secondary argument of risk aversion; there is currently minimal IPv6 deployment or operational experience and expertise, and the carriers do not want to drive development of this expertise. Finally, some groups argue IPv4 is sufficient for "walled garden" use, using IPv4 private address space (i.e., the "net 10" solution). One other area of concern regarding IPv6 usage is perceived memory and processing overhead and its effect on small, limited capability devices. This was primarily directed at IPv6 requirement for IPsec implementation to claim conformance. Arguments that continued increase in device capacity will obviate these concerns were rejected. It was stated that power constraints on these low-end devices will continue to force concerns on memory and processing overhead, and impact introduction of other features. There was no conclusion on whether IPsec could be made optional for these devices, or the effect if these devices were "non-compliant". Emerging 3G cellular networks appear ideal environment for IPv6 introduction. IPv6 addresses scaling requirements of wireless data user projections and eliminates continued cobbling of systems employing (IPv4) private address space and NAT. This appears an area for IAB and Internet community to take a strong stance advocating adoption of IPv6 as the various 3G forums wrestle with their recommendations. 32] or SIP . Currently support seems to be split between the protocols, and neither seemed ideal without support for mobility. During discussion on VoIP it was presented that SIP does support mobility, with graceful handling of mobile handoff, updating location information with remote peer, and even simultaneous handoff of both endpoints. The problem with SIP adoption seems to be its slow standardization brought about by
focusing on the harder multicast model rather than expediting definition of a unicast "profile". There seems great need for IETF to expedite finalization of SIP, however some argued at this point it's likely many products will need to develop support for both SIP and H.323, and for their interoperation. A short discussion was also raised on whether it is the correct model to incorporate the additional protocol mechanisms to accommodate mobility into the SIP signaling. An alternative model might be to build on top of the existing mobile IP handoff facilities. There was no conclusion reached, however it seemed an area for further investigation.
There wasn't really a large amount of discussions on ways to address these differences in standards practices. However, it did seem beneficial to understand these concerns and frustrations. It seemed clear there can be some benefits in improving communication with other standards organizations and encouraging their participation in IETF activities.
An exception to this style of partitioning meeting sponsorship is less formal activities, such as BOFs. It was recommended that sponsoring joint BOF could be beneficial. These could enable assembly of experts from multiple domains early in the process of exploring new topics for future standards activities.
22,27,44,45], BOOTP , DHCP , SLP , and others. Specific recommendations on use of these protocols in this environment can help foster common discovery methods across a range of access devices and ease configuration complexity. It was recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet). It seemed clear that a better model is required than trying to map all access over a HTTP  transport connection gateway. One suggestion was to propose use of IP! 60] is to be strongly discouraged. NAT has several inherent faults, including breaking the Internet peer-to-peer communication model, breaking end-to-end security, and stifling deployment of new services [16,29,31]. In addition, the state and performance implications of supporting 10's to 100's million users is cost and technologically prohibitive. 10,11] has potential to restore the end- to-end communication model in the IPv4 Internet, broken by traditional NAT. However there was considerable reluctance to formally recommend this as the long term solution. Detriments to its adoption include that the protocol is still being researched and defined, and potential interactions with applications, QoS features, and security remain. In addition, added signaling, state, and tunneling has cost and may be technologically prohibitive scaling.
55] or address translation due to address space shortage . Therefore, accomplishing this should primarily require installing and enforcing proper address allocation policy on registry and service providers. It was recommended to establish policies requiring service providers to allocate a sufficient quantity of global addresses for a sites use. The feeling was that NAT should be easily eliminated provided efficient strategies are defined to address renumbering [17,62] and mobility  issues. 48]. Primary among these limitations is that mechanisms to support redundant home agents and failover are not currently defined. Redundant home agents are required to avoid single point of failure, which would require (proprietary) extensions. Additional deficiencies related to lack of route optimization, and tunneling and path MTU issues were also identified. Due to these limitations there was reluctance to recommend this as a solution.
37] to support roaming capabilities in the wireless environment. IP mobility over IPv6 incorporates improvements to address several limitations of the IPv4-based mobility. The ability to use autoconfiguration for "care of" address improves robustness and efficiency. Additionally, path MTU is more easily adapted when a router forwards to a new "care of" address. Building wireless roaming atop IPv6-based mobility may introduce IPv4/IPv6 transition issues unique to the mobile environment. It was recommended to add investigation of these issues to the charter of the existing IETF Next Generation Transition (ngtrans) working group, provided any mobile IP interoperation issues be identified. 26,49]. However, due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of these AAA standards and investigation of AAA scalability as high priorities.
establishment, congestion control, loss recovery strategies, etc.), and document some of the history behind transport research in the Internet. This "entry point" document into transport design is in direct support of the recommendations in section 4.1 to foster communication and mutual education. In addition it was deemed critical that the Internet community make it very clear that congestion control is not optional. Internet researchers have learned that optimizing for a single link or homogeneous environment does not scale. Early work by Jacobson [34,35], standardization of TCP congestion control , and continuing work within the IETF Endpoint Congestion Management (ecm) working group could provide excellent basis for education of wireless transport designers. 4,6].
(SE) message . This likely falls to the auspice of the IETF Performance Implications of Link Characteristics (pilc) working group. 25]. D-SACK provides additional robustness to reordered packets, which may prove beneficial in wireless environment where packets are occasionally corrupted. Higher performance may be attainable by eliminating requirements on link-level retransmission maintaining in-order delivery within a flow. 54] to support additional policy features available within the ISO IDRP protocol . The range of policy control desired includes adopting different identity or policies based on current point of attachment, and providing flexibility in path selection based on local policy and/or current
peer policy. These features could be used for instance in support of requirements established in the Aeronautical Telecommunication Network (ATN). 54] to support additional QoS/TOS path selection features available within the ISO IDRP protocol . The range of policies include differentiating service level or path selection based on traffic classes. An example, based on Aeronautical Telecommunication Network (ATN) requirements, might be differentiating path selection and service between airline control and passenger entertainment traffic. 13]), while relying on resource provisioning or more scalable DiffServ  technologies within the core.
7,64]. However, there are significant issues to be solved to enable a scalable, Internet-wide solution. Due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of scalable inter- domain AAA as high priority within the IETF. section 4.1 to foster communication and mutual education.
section 4.3) and mobility (see section 4.4) issues in the future Internet dominated by large numbers of wireless and mobile devices. It was recommended that the IAB draft a formalized justification for these recommendations for adoption of IPv6-based solution. It was believed that the "The Case for IPv6"  document should form an excellent basis for this justification. In addition, documents highlighting architectural and operational pitfalls of continued reliance on IPv4 and NAT also provide excellent justification [29,31,59]. It was deemed urgent to submit these informational documents as inputs to other standards bodies (MWIF, 3GPP, 3G.IP), as many decisions are being made on Internet protocol adoption and this data could be highly influential. section 2 focused on security mechanisms in currently deployed cellular networks and evolution toward 3G cellular and IP networks. Discussion on the "walled garden" service model (see section 3.1) briefly mentions effects on simplifying security requirements. Section 3.3 raises a number of security issues related to wireless devices and mobility. These include alternatives for establishing user identity and capabilities, securing network infrastructure from attacks, and security associations required for mobile IP and AAA operation. Section 3.7 mentions interoperation issues between compression and encryption or tunneling, and finally section 3.9 highlight potential for proxy agent to be used to offload expensive crypto operations.
 ACIRI. TCP-Friendly Rate Control. http://www.aciri.org/tfrc.  A. Aggarwal, S. Savage, and T. Anderson. Understanding the Performance of TCP Pacing. Proceedings of IEEE Infocom 2000, March 2000.  Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.  Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", RFC 2488, January 1999.  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.  Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.  Arkko, J., "Requirements for Internet-Scale Accounting Management", Work in Progress.  Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services" RFC 2475, December 1998.  Borella, M., et al., "Realm Specific IP: Framework", Work in Progress.  Borella, M., et al., "Realm Specific IP: Protocol Specification", Work in Progress.  Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.  Carpenter, B., "Internet Transparency", RFC 2775, February 2000.  Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.  Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985.  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  Everhart, C., Mamakos, L., Ullman, R. and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.  Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.  Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgment (SACK) Option for TCP", RFC 2883, July 2000.  Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.  Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.  Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.  International Telecommunication Union. Visual Telephone Systems and Equipment for Local Area Networks which provide a Non- guaranteed Quality of Service. Recommendation H.323, May 1996.  ISO/IEC. Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs. ISO/IEC IS10747, 1993.  V. Jacobson. Congestion Avoidance and Control. Computer Communication Review, vol. 18, no. 4 August 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.  V. Jacobson. Modified TCP Congestion Avoidance Algorithm. end2end-interest mailing list, April 30, 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.  Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.  Jonsson, L., et al., "RObust Checksum-based header COmpression (ROCCO)", Work in Progress.  Karn, P., et al., "Advice for Internet Subnetwork Designers", Work in Progress.  King, S., et al., "The Case for IPv6", Work in Progress.  J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP for High Delay-Bandwidth Networks. Proceedings of IEEE Globecom '99, December 1999.  Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time Multimedia", Work in Progress.  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
 Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, November 1987.  Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, November 1987.  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.  Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.  Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.  Schulzrinne, H., Casner, S., Fredrick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.  J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer Tuning. Proceedings of ACM SIGCOMM '98, September 1998.
 Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.  Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", Work in Progress.  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.  Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.  Vollbrecht, J., et al., "AAA Authorization Framework", Work in Progress.
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.