< draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt   draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt >
16ng Working Group S. Madanapalli 16ng Working Group S. Madanapalli
Internet-Draft Ordyn Technologies Internet-Draft Ordyn Technologies
Intended status: Standards Track Soohong D. Park Intended status: Standards Track Soohong D. Park
Expires: May 3, 2009 Samsung Electronics Expires: December 5, 2009 Samsung Electronics
S. Chakrabarti S. Chakrabarti
IP Infusion IP Infusion
G. Montenegro G. Montenegro
Microsoft Corporation Microsoft Corporation
October 30, 2008 June 3, 2009
Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2009. This Internet-Draft will expire on December 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
IEEE 802.16 is an air interface specification for wireless broadband IEEE 802.16 is an air interface specification for wireless broadband
access. IEEE 802.16 has specified multiple service specific access. IEEE 802.16 has specified multiple service specific
convergence sublayers for transmitting upper layer protocols. The Convergence Sublayers for transmitting upper layer protocols. The
packet CS (Packet Convergence Sublayer) is used for the transport of packet CS (Packet Convergence Sublayer) is used for the transport of
all packet-based protocols such as Internet Protocol (IP), IEEE 802.3 all packet-based protocols such as Internet Protocol (IP), IEEE 802.3
(Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the (Ethernet) and IEEE 802.1Q (VLAN). The IP-specific part of the
Packet CS enables the transport of IPv4 packets directly over the Packet CS enables the transport of IPv4 packets directly over the
IEEE 802.16 MAC. IEEE 802.16 MAC.
This document specifies the frame format, the Maximum Transmission This document specifies the frame format, the Maximum Transmission
Unit (MTU) and address assignment procedures for transmitting IPv4 Unit (MTU) and address assignment procedures for transmitting IPv4
packets over the IP-specific part of the Packet Convergence Sublayer packets over the IP-specific part of the Packet Convergence Sublayer
of IEEE 802.16. of IEEE 802.16.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 3 3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 4
3.1. IEEE 802.16 IPv4 Convergence sub-layer support . . . . . . 4 3.1. IEEE 802.16 IPv4 Convergence Sublayer Support . . . . . . 4
4. IPv4-CS link in 802.16 Networks . . . . . . . . . . . . . . . 5 4. IPv4 CS link in 802.16 Networks . . . . . . . . . . . . . . . 5
4.1. IPv4-CS link establishment . . . . . . . . . . . . . . . . 5 4.1. IPv4 CS link establishment . . . . . . . . . . . . . . . . 5
4.2. Frame Format for IPv4 Packets . . . . . . . . . . . . . . 6 4.2. Frame Format for IPv4 Packets . . . . . . . . . . . . . . 5
4.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 7 4.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6
5. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 8 5. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 8
5.1. IPv4 Unicast Address Assignment and Router Discovery . . . 8 5.1. IPv4 Unicast Address Assignment and Router Discovery . . . 8
5.2. Address Resolution Protocol . . . . . . . . . . . . . . . 9 5.2. Address Resolution Protocol . . . . . . . . . . . . . . . 9
5.3. IP Multicast Address Mapping . . . . . . . . . . . . . . . 9 5.3. IP Multicast Address Mapping . . . . . . . . . . . . . . . 9
6. Handling Multicast and Broadcast packets in IPv4 CS . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Multiple Convergence Layers - Impact on Subnet Appendix A. Multiple Convergence Layers - Impact on Subnet
Model . . . . . . . . . . . . . . . . . . . . . . . . 12 Model . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Sending and Receiving IPv4 Packets . . . . . . . . . 12 Appendix B. Sending and Receiving IPv4 Packets . . . . . . . . . 11
Appendix C. Wimax IPCS MTU size . . . . . . . . . . . . . . . . . 13 Appendix C. WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 12
Appendix D. Thoughts on handling multicast-broadcast IP Appendix D. Thoughts on handling multicast-broadcast IP
packets . . . . . . . . . . . . . . . . . . . . . . . 14 packets . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
IEEE 802.16 [IEEE802_16] is a connection oriented access technology IEEE 802.16 [IEEE802_16] is a connection oriented access technology
for the last mile. The IEEE 802.16 specification includes the PHY for the last mile. The IEEE 802.16 specification includes the PHY
and MAC details. The MAC includes various convergence sublayers (CS) and MAC layers. The MAC includes various Convergence Sublayers (CS)
for transmitting higher layer packets including IPV4 packets for transmitting higher layer packets including IPv4 packets
[RFC5154]. [IEEE802_16].
The scope of this specification is limited to the operation of IPv4 The scope of this specification is limited to the operation of IPv4
over the IP-specific part of the packet CS (referred to as "IPv4 CS" over the IP-specific part of the packet CS (referred to as "IPv4 CS"
or simply "IP CS" in this document). or simply "IP CS" in this document).
This document specifies a method for encapsulating and transmitting This document specifies a method for encapsulating and transmitting
IPv4 [RFC0791] packets over the IP CS of IEEE 802.16. This document IPv4 [RFC0791] packets over the IP CS of IEEE 802.16. This document
also specifies the MTU and address assignment method for the IEEE also specifies the MTU and address assignment method for the IEEE
802.16 based networks using IP CS. 802.16 based networks using IP CS.
This document also discusses ARP (Address Resolution Protocol) and This document also discusses ARP (Address Resolution Protocol) and
Multicast Address Mapping whose operation is similar to any other Multicast Address Mapping whose operations are similar to any other
point-to-point link model. point-to-point link model.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The terminology in this document is based on the definitions in The terminology in this document is based on the definitions in
[RFC5154]. [RFC5154].
3. Typical Network Architecture for IPv4 over IEEE 802.16 3. Typical Network Architecture for IPv4 over IEEE 802.16
The network architecture follows what is described in [RFC5154] and The network architecture follows what is described in [RFC5154] and
[RFC5121]. In a nutshell, each MS is attached to an Access Router [RFC5121]. In a nutshell, each MS is attached to an Access Router
(AR) through a Base Station (BS), a layer 2 entity. The AR can be an (AR) through a Base Station (BS), a layer 2 entity (from the
integral part of the BS or the AR could be an entity beyond the BS perspective of the IPv6 link between the MS and access router (AR)).
within the access network. IPv4 packets between the MS and BS are
carried over a point-to-point MAC transport connection which has a
unique connection identifier (CID). The packets between BS and AR
are carried using L2 tunnel (typically GRE tunnel) so that MS and AR
are seen as layer 3 peer entities. At least one L2 tunnel is
required for each MS, so that IP packets can be sent to MSs before
they acquire IP addresses. From the layer 3 perspective, MS and AR
are connected by a point-to-point link. The figure below illustrates
the network architecture for convenience.
+-----+ CID1 +------+ +-----------+
| MS1 |----------+| BS |----------| AR |-----Internet
+-----+ / +------+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
Figure 1: Typical Network Architecture for IPv4 over IEEE 802.16
The above network model serves as an example and is shown to
illustrate the point to point link between the MS and the AR. The L2
tunnel is not required if BS and AR are integrated into a single box.
3.1. IEEE 802.16 IPv4 Convergence sub-layer support
As described in [RFC5154] section 3.3., an IP specific subpart
classifier carries either IPv4 or IPv6 payloads. In this document,
we are focussing on IPv4 over IP Convergence sublayer.
The convergence sublayer maintains an ordered "classifier table".
Each entry in the classifier table includes a classifier and a target
CID. In case of IP convergence sub-layer, the base-station performs
the mapping between CID or service-flow ID and a corresponding GRE
key for a particular IP-CS session. Also the classification takes
place in Access Router based on the GRE key per service-flow and/or
IP-address of the MS.
The other classifiers in Packet CS are IPv6 CS and Ethernet CS For further information on the typical network architecture, see
[RFC5154]. The classifiers used by IP CS, enable the differentiation [RFC5121] section 5.
of IPv4 and IPv6 packets and their mapping to specific transport
connections over the air interface.
The figure below shows the IPv4 user payload over IP transport over 3.1. IEEE 802.16 IPv4 Convergence Sublayer Support
the packet CS of IEEE 802.16:
+-------------------+ As described in [IEEE802_16], the IP-specific part of the packet CS
| IPv4 Payload | allows the transmission of either IPv4 or IPv6 payloads. In this
+-------------------+ document, we are focusing on the IPv4 over Packet Convergence
| GRE | Sublayer.
+-------------------+ +-------------------+
| IPv4 Payload | | IP |
+-------------------+ +-------------------+
| IP-specific | | BS-AR Layer 2 |
| part of Packet CS | | specific link |
|...................| | (Ex: Ethernet) |
| 802.16 MAC | | |
+-------------------+ +-------------------+
| PHY | | PHY |
+-------------------+ +-------------------+
(1) IPv4 over IP-CS (2) IPv4 in L3 GRE encapsulation For further information on the IEEE 802.16 Convergence Sublayer and
between MS and BS between Base-station and AR encapsulation of IP packets, see [RFC5121] section 4 and [RFC5154]
section 3.3.
Figure 2: IEEE 802.16 transport of IPv4 Packets from MS to AR 4. IPv4 CS link in 802.16 Networks
4. IPv4-CS link in 802.16 Networks This document defines the IPv4 CS link as a point-to-point link
between the MS and the AR using a set of service flows consisting of
MAC transport connections between a MS and BS, and L2 tunnel(s)
between a BS and AR. It is recommended that a tunnel be established
between the AR and a BS based on 'per MS' or 'per service flow' (An
MS can have multiple service flows each of which are identified by a
unique service flow ID). Then the tunnel(s) for an MS, in
combination with the MS's MAC transport connections, forms a single
point-to-point link. Each MS belongs to a different link and is
assigned an unique IPv4 address per recommendations in [RFC4968].
In this document we have defined IPv4 CS link as a point-to-point To summarize:
link between the MS and the AR using a set of service flows
consisting of MAC transport connections between a MS and BS, and L2
tunnel(s) between between a BS and AR. It is recommended that a
tunnel be established between the AR and a BS based on 'per MS' or
'per service flow' (An MS can have multiple service flows each of
which are identified by a unique service flow ID). Then the
tunnel(s) for an MS, in combination with the MS's MAC transport
connections, forms a single point-to-point link. Each MS belongs to
a different link and is assigned an unique IPv4 address per
recommendations in [RFC4968]. In summary:
o IPv4-CS uses the IPv4 header fields to classify the packets and o IPv4 CS uses the IPv4 header fields to classify the packets and
map to appropriate CID. map to the appropriate CID.
o Point-to-point link between MS and AR is established. o A point-to-point link between MS and AR is established.
4.1. IPv4-CS link establishment 4.1. IPv4 CS link establishment
In order to enable the sending and receiving of IPv4 packets between In order to enable the sending and receiving of IPv4 packets between
the MS and the AR, the link between the MS and the AR via the BS the MS and the AR, the link between the MS and the AR via the BS
needs to be established. This section explains the link needs to be established. This section explains the link
establishment procedures following section 6.2 of [RFC5121]. Steps establishment procedures following section 6.2 of [RFC5121]. Steps
1-4 are same as indicated in 6.2 of [RFC5121]. In step 5, support 1-4 are same as indicated in 6.2 of [RFC5121]. In step 5, support
for IPv4 is indicated. In step 6, an initial service flow is created for IPv4 is indicated. In step 6, an initial service flow is created
that can be used for exchanging IP layer signaling messages, e.g. that can be used for exchanging IP layer signaling messages, e.g.
address assignment procedures using DHCP. address assignment procedures using DHCP.
skipping to change at page 6, line 39 skipping to change at page 6, line 27
+- -+ +- -+
| and | | and |
+- -+ +- -+
/ payload / / payload /
+- -+ +- -+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) | |CRC (optional) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: IEEE 802.16 MAC Frame Format for IPv4 Packets Figure 1: IEEE 802.16 MAC Frame Format for IPv4 Packets
H: Header Type (1 bit). Shall be set to zero indicating that it H: Header Type (1 bit). Shall be set to zero indicating that it
is a Generic MAC PDU. is a Generic MAC PDU.
E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
is encrypted. is encrypted.
R: Reserved. Shall be set to zero. R: Reserved. Shall be set to zero.
C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
EKS: Encryption Key Sequence EKS: Encryption Key Sequence
LEN: The Length in bytes of the MAC PDU including the MAC header LEN: The Length in bytes of the MAC PDU including the MAC header
and the CRC if present (11 bits) and the CRC if present (11 bits)
skipping to change at page 7, line 19 skipping to change at page 6, line 50
CRC: An optional 8-bit field. CRC appended to the PDU after CRC: An optional 8-bit field. CRC appended to the PDU after
encryption. encryption.
TYPE: This field indicates the subheaders (Mesh subheader, TYPE: This field indicates the subheaders (Mesh subheader,
Fragmentation Subheader, Packing subheader etc and special payload Fragmentation Subheader, Packing subheader etc and special payload
types (ARQ) present in the message payload types (ARQ) present in the message payload
4.3. Maximum Transmission Unit 4.3. Maximum Transmission Unit
The MTU value for IPv4 packets on an IEEE 802.16 link is The MTU value for IPv4 packets on an IEEE 802.16 link is
configurable. The default MTU for IPv4 packets over an IEEE 802.16 configurable. The default MTU for IPv4 packets over an IEEE 802.16
link SHOULD be 1500 bytes. In some deployments, BS and AR are link SHOULD be 1500 octets.
separate entities; an encapsulation may be used to transport IPv4
packets between the BS and AR. In those cases the overhead of
encapsulation may be considered in the link MTU configuration.
Note, if a deployment configures the 802.16 link MTU less than 1500, Per [RFC5121] section 6.3, the IP MTU can vary to be larger or
then 1500 byte packets from the MS will be dropped at the link-layer smaller than 1500 octets.
silently; the legacy IPv4 client implementations do not determine the
link MTU by default before sending packets, while the DHCP servers
are required to provide the MTU information only when requested.
Please see Appendix C. for the default MTU value in WiMAX [WMF]
deployed networks.
This document recommends that a deployment should ensure that no if an MS transmits 1500-octet packets in a deployment with a smaller
packet loss happens at the L2 level over IPV4 CS link-MTU, due to MTU, packets from the MS may be dropped at the link-layer silently.
mismatch in default MTU and the configured link MTUs. Unlike IPv6, in which departures from the default MTU are readily
advertised via the MTU option in Neighbor Discovery, there is no
similarly reliable mechanism in IPv4, as the legacy IPv4 client
implementations do not determine the link MTU by default before
sending packets. Even though there is a DHCP option to accomplish
this, DHCP servers are required to provide the MTU information only
when requested.
However, it is strongly recommended that an IPv4 CS client host Discovery and configuration of the proper link MTU value ensures
configure the link-MTU before initiating the IP-level packet adequate usage of the network bandwidth and resources. Accordingly,
exchange. The following paragraph discusses different approaches deployments should avoid packet loss due to a mismatch between the
through which the IPv4 CS client finds out the available link-MTU default MTU and the configured link MTUs.
value. The discovery and configuration of a proper link MTU value
ensures adequate usage of the network bandwidth and resource.
o The IEEE is currently revising 802.16 (see 802.16Rev2 [802_16REV2] Some of the mechanisms available for the IPv4 CS host to find out
) to reproduce capabilities to inform the Service Data Unit or MAC the link's MTU value and mitigate MTU-related issues are:
MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, such that future
IEEE 802.16 compliant clients can configure the negotiated MTU
size for IP-CS link. However, the implementation must communicate
the negotiated MTU value to the IP layer to adjust the IP Maximum
payload size for proper handling of fragmentation. Note that this
method is useful only when MS is directly connected to the BS.
o Configuration and negotiation of MTU size at the network-layer by o The IEEE is currently revising 802.16 (see 802.16Rev2
using DHCP interface MTU option [RFC2132]. [802_16REV2]) to (among other things) allow providing the Service
Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase,
such that future IEEE 802.16 compliant clients can infer and
configure the negotiated MTU size for the IPv4 CS link. However,
the implementation must communicate the negotiated MTU value to
the IP layer to adjust the IP Maximum payload size for proper
handling of fragmentation. Note that this method is useful only
when MS is directly connected to the BS.
o Configuration and negotiation of MTU size at the network layer by
using the DHCP interface MTU option [RFC2132].
This document recommends that all future implementations of IPv4 and This document recommends that all future implementations of IPv4 and
IPv4-CS clients SHOULD implement DHCP interface MTU option [RFC2132] IPv4 CS clients SHOULD implement the DHCP interface MTU option
in order to configure its interface MTU according to the access [RFC2132] in order to configure its interface MTU accordingly.
network in order to maximize the capacity of the bandwidth of the
network. Thus the IPv4 stack should have capability to adjust the
MTU value based on the DHCP response.
In the absence of DHCP MTU configuration, the client node (MS) has In the absence of DHCP MTU configuration, the client node (MS) has
two alternatives: 1) use the default MTU (1500 bytes) or 2) determine two alternatives: 1) use the default MTU (1500 bytes) or 2) determine
the MTU by the methods described in [802_16REV2]. the MTU by the methods described in [802_16REV2].
Additionally, the clients are encouraged to run PMTU[RFC 1191] or Additionally, the clients are encouraged to run PMTU [RFC1191] or
PPMTUD[RFC 4821]. However, PMTU mechanism has inherent problems of PPMTUD [RFC4821]. However, the PMTU mechanism has inherent problems
packet loss due to ICMP messages not reaching the sender and IPv4 of packet loss due to ICMP messages not reaching the sender and IPv4
routers not fragmenting the packets due to DF bit being set in the IP routers not fragmenting the packets due to the DF bit being set in
packet. The above mentioned path MTU mechanisms will take care of the IP packet. The above mentioned path MTU mechanisms will take
the MTU size between the MS and its correspondent node across care of the MTU size between the MS and its correspondent node across
different flavors of convergence layers in the WiMAX networks and different flavors of convergence layers in the access networks.
other types of IP networks.
5. Subnet Model and IPv4 Address Assignment 5. Subnet Model and IPv4 Address Assignment
The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is
based on the point-to-point link between MS and AR [RFC4968], hence based on the point-to-point link between MS and AR [RFC4968], hence
each MS shall be assigned an address with 32bit prefix-length or each MS shall be assigned an address with 32bit prefix-length or
subnet-mask. The point-to-point link between MS and AR is achieved subnet-mask. The point-to-point link between MS and AR is achieved
using a set of IEEE 802.16 MAC connections (identified by CIDs) and a using a set of IEEE 802.16 MAC connections (identified by CIDs) and
L2 tunnel (usually a GRE tunnel) per MS between BS and AR. If the AR an L2 tunnel (e.g., a GRE tunnel) per MS between BS and AR. If the
is co-located with the BS then the set of IEEE 802.16 MAC connections AR is co-located with the BS, then the set of IEEE 802.16 MAC
between the MS and BS/AR represent the point-to- point connection. connections between the MS and BS/AR represent the point-to- point
connection.
5.1. IPv4 Unicast Address Assignment and Router Discovery 5.1. IPv4 Unicast Address Assignment and Router Discovery
DHCP [RFC2131] SHOULD be used for assigning IPv4 address for the MS. DHCP [RFC2131] SHOULD be used for assigning IPv4 address for the MS.
DHCP messages are transported over IEEE 802.16 MAC connection to and DHCP messages are transported over the IEEE 802.16 MAC connection to
from the BS and relayed to the AR. In case DHCP server does not and from the BS and relayed to the AR. In case the DHCP server does
reside in the AR, the AR SHOULD implement DHCP relay Agent [RFC1542]. not reside in the AR, the AR SHOULD implement DHCP relay Agent
Please refer to the MTU section of this document for requirements of [RFC1542].
DHCP interface-MTU option for the new IPv4 CS MS implementation.
Although DHCP is the recommended method of address assignment, it is Although DHCP is the recommended method of address assignment, it is
possible that the MS could be a pure Mobile-IPv4 [RFC3344] device or possible that the MS could be a pure Mobile IPv4 [RFC3344] device
Wimax Mobile-IPv4 client which will be offered an IP-address from its which will be offered an IP address from its home network after
home-network after success-ful Mobile-IP [RFC3344] registration. In successful Mobile IP [RFC3344] registration. In such situations, the
such situation, the mobile-client implementation SHOULD use the mobile host SHOULD use the default link MTU in order to avoid any
default link MTU in order to avoid any link-layer packet loss due to link-layer packet loss due to larger than supported packet size in
larger than supported packet size in the IP CS link. the IP CS link.
Router discovery messages [RFC1256] contain router solicitation and Router discovery messages [RFC1256] contain router solicitation and
router advertisements. The Router solicitation messages (multicast router advertisements. The Router solicitation messages (multicast
or broadcast) are directly delivered to AR via BS from the MS through or broadcast) from the MS are delivered to the AR via the BS through
the point-to-point link. The BS SHOULD map the all-router multicast the point-to-point link. The BS SHOULD map the all-routers multicast
nodes or broadcast nodes for router discovery to the AR's IP-address nodes or broadcast nodes for router discovery to the AR's IP address
and delivered directly to the AR. Similarly for router-advertisement and deliver directly to the AR. Similarly a router advertisement to
to the all-node multicast nodes will be either unicasted to each MS the all-nodes multicast nodes will be either unicast to each MS by
by the BS separately or put onto a multicast connection to which all the BS separately or put onto a multicast connection to which all MSs
MSs are listening to. If no multicast connection exists, and the BS are listening to. If no multicast connection exists, and the BS does
does not have the capability to aggregate and de-aggregate the not have the capability to aggregate and disaggregate the messages to
messages from and to the MS hosts, then the AR implementation must and from the MS hosts, then the AR implementation must ensure that
take care of sending unicast messages to the corresponding individual unicast messages are sent to the corresponding individual MS hosts
MS hosts within the set of broadcast or multicast recipients. within the set of broadcast or multicast recipients. This
However, this specification simply assumes that the multicast service specification simply assumes that the multicast service is provided.
is provided. How the multicast service is implemented in IEEE 802.16 How the multicast service is implemented in an IEEE 802.16 Packet CS
Packet CS network, is out of scope of this document. deployment is out of scope of this document.
The 'Next-hop' IP-address of the IP CS MS is always the IP-address of The 'Next hop' IP address of the IP CS MS is always the IP address of
the AR, because MS and AR are attached with a point-to-point link. the AR, because MS and AR are attached via a point-to-point link.
5.2. Address Resolution Protocol 5.2. Address Resolution Protocol
The IP CS does not allow for transmission of ARP [RFC0826] packets. The IP CS does not allow for transmission of ARP [RFC0826] packets.
Furthermore, in a point-to-point link model, address resolution is Furthermore, in a point-to-point link model, address resolution is
not needed. not needed.
5.3. IP Multicast Address Mapping 5.3. IP Multicast Address Mapping
IPv4 multicast packets are carried over the point-to-point link IPv4 multicast packets are carried over the point-to-point link
between the AR and the MS (via the BS). The IPv4 multicast packets between the AR and the MS (via the BS). The IPv4 multicast packets
are classified normally at the IP CS if the IEEE 802.16 MAC are classified normally at the IP CS if the IEEE 802.16 MAC
connection has been setup with a multicast IP address as a connection has been set up with a multicast IP address as a
classification parameter for the destination IP address. The IPv4 classification parameter for the destination IP address. The IPv4
multicast address may be mapped into multicast CID defined in IEEE multicast address may be mapped into a multicast CID as defined in
802.16 specification, but the mapping mechanism at the BS or the IEEE 802.16 specification. The mapping mechanism at the BS or
efficiency of using multicast CID as opposed to simulating multicast the relative efficiency of using a multicast CID as opposed to
by generating multiple unicast messages are out of scope of this simulating multicast by generating multiple unicast messages are out
document. However, it has been studied that the use of multicast CID of scope of this document. For further considerations on the use of
for realizing multicast transmissions reduces transmission efficiency multicast CIDs see [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16].
when the multicast group is small, due to the nature of wireless
network(IEEE 802.16) [ETHCS].
6. Handling Multicast and Broadcast packets in IPv4 CS
In the IP-CS link model, two different approaches can work - 1) BS
maps the multicast or Broadcast IP-addresses into different multicast
CIDs of the MSs or 2) AR maps the multicast IP-addresses to different
unicast IP-addresses and send the packets directly to each MS
separately.
However as mentioned earlier, handling a mechanism of multicast or
broadcast IP CS packets are out of scope of this document. Please
refer to Appendix section for some thoughts and suggestions.
7. Security Considerations 6. Security Considerations
This document specifies transmission of IPv4 packets over IEEE 802.16 This document specifies transmission of IPv4 packets over IEEE 802.16
networks with IPv4 Convergence Sublayer and does not introduce any networks with IPv4 Convergence Sublayer and does not introduce any
new vulnerabilities to IPv4 specifications or operation. The new vulnerabilities to IPv4 specifications or operation. The
security of the IEEE 802.16 air interface is the subject of security of the IEEE 802.16 air interface is the subject of
[IEEE802_16]. In addition, the security issues of the network [IEEE802_16]. In addition, the security issues of the network
architecture spanning beyond the IEEE 802.16 base stations is the architecture spanning beyond the IEEE 802.16 base stations is the
subject of the documents defining such architectures, such as WiMAX subject of the documents defining such architectures, such as WiMAX
Network Architecture [WMF]. Network Architecture [WMF].
8. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgements 8. Acknowledgements
The authors would like to acknowledge the contributions of Bernard The authors would like to acknowledge the contributions of Bernard
Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil, Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil,
Paolo Narvaez, and Bruno Sousa for their review and comments. The Paolo Narvaez, and Bruno Sousa for their review and comments. The
working group members Burcak Beser, Wesley George, Max Riegel and DJ working group members Burcak Beser, Wesley George, Max Riegel and DJ
Johnston helped shape the MTU discussion for IPv4 CS link. Thanks to Johnston helped shape the MTU discussion for IPv4 CS link. Thanks to
many other members of the 16ng working group who commented on this many other members of the 16ng working group who commented on this
document to make it better. document to make it better.
10. References 9. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Madanapalli, "Transmission of IPv6 via the IPv6 Requirement Levels", BCP 14, RFC 2119, March 1997.
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
802.16 Problem Statement and Goals", RFC 5154, April 2008.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Based Networks", RFC 4968, August 2007. RFC 2131, March 1997.
10.2. Informative References 9.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
Discovery", RFC 4821, March 2007. September 1991.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple [RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
Encapsulation Methods Considered Harmful", RFC 4840, Encapsulation Methods Considered Harmful", RFC 4840,
April 2007. April 2007.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
August 2002. Based Networks", RFC 4968, August 2007.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
September 1991. Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[ETHCS] Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
over Ethernet over IEEE 802.16 Networks", April 2008, 802.16 Problem Statement and Goals", RFC 5154, April 2008.
<http://www.ietf.org/internet-drafts/
draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt>. [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16]
Riegel, M., Jeong, S., and H. Jeon, "Transmission of IP
over Ethernet over IEEE 802.16 Networks",
draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08 (work
in progress), January 2009.
[802_16REV2] [802_16REV2]
Johnston, D., "SDU MTU Capability Declaration", Johnston, D., "SDU MTU Capability Declaration",
March 2008, <http://www.ieee.org/16>. March 2008, <http://www.ieee.org/16>.
[IEEE802_16] [IEEE802_16]
"IEEE 802.16e, IEEE standard for Local and metropolitan "IEEE 802.16e, IEEE standard for Local and metropolitan
area networks, Part 16:Air Interface for fixed and Mobile area networks, Part 16:Air Interface for fixed and Mobile
broadband wireless access systems", October 2005. broadband wireless access systems", October 2005.
[WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3 [WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3
Release 1.2, Release 1.2,
http://www.wimaxforum.org/technology/documents", http://www.wimaxforum.org/technology/documents",
January 2008. January 2008.
Appendix A. Multiple Convergence Layers - Impact on Subnet Model Appendix A. Multiple Convergence Layers - Impact on Subnet Model
Two different MSs using two different convergence sublayers (e.g. an Two different MSs using two different Convergence Sublayers (e.g. an
MS using Ethernet CS only and another MS using IP CS only) cannot MS using Ethernet CS only and another MS using IP CS only) cannot
communicate at data link layer and requires interworking at IP layer. communicate at data link layer and requires interworking at IP layer.
For this reason, these two nodes must be configured to be on two For this reason, these two nodes must be configured to be on two
different subnets. For more information refer [RFC4840]. different subnets. For more information refer to [RFC4840].
Appendix B. Sending and Receiving IPv4 Packets Appendix B. Sending and Receiving IPv4 Packets
IEEE 802.16 MAC is a point-to-multipoint connection oriented air- IEEE 802.16 MAC is a point-to-multipoint connection oriented air-
interface, and the process of sending and receiving of IPv4 packets interface, and the process of sending and receiving of IPv4 packets
is different from multicast capable shared medium technologies like is different from multicast-capable shared medium technologies like
Ethernet. Ethernet.
Before any packets being transmitted, IEEE 802.16 transport Before any packets are transmitted, a IEEE 802.16 transport
connection must be established. This connection consists of IEEE connection must be established. This connection consists of IEEE
802.16 MAC transport connection between MS and BS and an L2 tunnel 802.16 MAC transport connection between MS and BS and an L2 tunnel
between BS and AR. This IEEE 802.16 transport connection provides a between BS and AR (if these two are not co-located). This IEEE
point-to-point link between MS and AR. All the packets originated at 802.16 transport connection provides a point-to-point link between
the MS always reach AR before being transmitted to the final the MS and AR. All the packets originated at the MS always reach the
destination. AR before being transmitted to the final destination.
IPv4 packets are carried directly in the payload of IEEE 802.16 IPv4 packets are carried directly in the payload of IEEE 802.16
frames when the IPv4 CS is used. IPv4 CS classifies the packet based frames when the IPv4 CS is used. IPv4 CS classifies the packet based
on upper layer (IP and transport layers)header fields to put the on upper layer (IP and transport layers) header fields to place the
packet on one of the available connections identified by the CID. packet on one of the available connections identified by the CID.
The classifiers for the IPv4 CS are source and destination IPv4 The classifiers for the IPv4 CS are source and destination IPv4
addresses, source and destinations ports, Type-of-Service and IP addresses, source and destinations ports, Type-of-Service and IP
protocol field. The CS may employ Packet Header Suppression (PHS) protocol field. The CS may employ Packet Header Suppression (PHS)
after the classification. after the classification.
The BS tunnels the packet that has been received on a particular MAC The BS optionally reconstructs the payload header if PHS is in use.
connection to the AR. BS reconstructs the payload header if the PHS It then tunnels the packet that has been received on a particular MAC
is in use before the packet is tunneled to the AR. Similarly the connection to the AR. Similarly the packets received on a tunnel
packets received on a tunnel interface from the AR, would be mapped interface from the AR, would be mapped to a particular CID using the
to a particular CID using IPv4 classification mechanism. IPv4 classification mechanism.
AR performs normal routing for the packets that it receives and
forwards the packet based on its forwarding table. However the DHCP
relay agent in the AR, MUST maintain the tunnel interface on which it
receives DHCP requests, so that it can relay the DHCP responses to
the correct MS. One way of doing this is to have a mapping between
MAC address and Tunnel Identifier.
Appendix C. Wimax IPCS MTU size AR performs normal routing for the packets that it receives,
processing them per its forwarding table. However, the DHCP relay
agent in the AR MUST maintain the tunnel interface on which it
receives DHCP requests so that it can relay the DHCP responses to the
correct MS. One way of doing this is to have a mapping between MAC
address and Tunnel Identifier.
WiMAX (Worldwide Interoperability for Microwave Access) forum has Appendix C. WiMAX IPCS MTU size
defined a network architecture[WMF] where IPV4 CS is supported for
transmission of IPV4 packets between MS and BS over the IEEE
802.16 link. The addressing and operation of IPV4CS described in
this document are applicable to the WiMAX networks as well. The
WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
However, it specifies that IP-payload in WiMAX architecture[WMF]
is 1400 bytes.
Hence if a IPV4-CS MS is configured with 1500 bytes it will have WiMAX (Worldwide Interoperability for Microwave Access) forum has
to be communicated by the access router(AR) about the default link defined a network architecture[WMF]. Furthermore, WiMAX has
MTU (1400 bytes) in WiMAX network. However, currently in IPv4 specified IPv4 CS support for transmission of IPv4 packets between MS
client architecture a node is not required to ask for MTU option and BS over the IEEE 802.16 link. The WiMAX IPv4 CS and this
in its DHCP messages nor an IPv4 router-advertisement can inform specification are similar. One significant difference, however, is
the node about the link MTU. An IPV4CS client is not capable of that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets
doing ARP probing either to find out the link MTU. Thus current [WMF] as opposed to 1500 in this specification.
specifications of WiMAX network access routers cannot communicate
its link MTU to the IPV4CS MS. On the other hand, it is
imperative for an MS to know the link MTU size if it is not the
default MTU value for de-facto standard in order to successfully
send packets in the network towards the first hop. Some
implementations with IEEE 802.16 layer 2 support, should be able
to sense IPV4CS WiMAX network and adjust their MTU size
accordingly, however this document does not make any assumptions on
this requirement.
Thus, WiMAX MS nodes should use this default (1400) MTU value per the Hence if an IPv4 CS MS configured with an MTU of 1500 octet enters a
current specification [WMF]. However, due to reasons specified in WiMAX network, some of the issues mentioned in this specification may
section 4.3 above, it is strongly recommended that future WiMAX MS arise. As mentioned in section 4.3, the possible mechanisms are not
nodes support a default MTU of 1500 bytes, and that they implement guaranteed to work. Furthermore, an IPv4 CS client is not capable of
MTU negotiation capabilities as mentioned in this document. doing ARP probing to find out the link MTU. On the other hand, it is
imperative for an MS to know the link MTU size. In practice, MS
should be able to sense or deduce the fact that they are operating
within a WiMAX network (e.g., given the WiMAX-specific
particularities of the authentication and network entry procedures),
and adjust their MTU size accordingly. This document makes no
further assumptions in this respect.
Appendix D. Thoughts on handling multicast-broadcast IP packets Appendix D. Thoughts on handling multicast-broadcast IP packets
Although this document does not directly specify details of multicast Although this document does not directly specify details of multicast
or broadcast packet handling, here are some suggestions: or broadcast packet handling, here are some suggestions:
While uplink connections from the MSs to the BS provide only unicast While uplink connections from the MSs to the BS provide only unicast
transmission capabilities, downlink connections can be used for transmission capabilities, downlink connections can be used for
multicast transmission to a group of MSs as well as unicast multicast transmission to a group of MSs as well as unicast
transmission from the BS to a single MS. For all-node IP-addresses, transmission from the BS to a single MS. For all-node IP addresses,
the AR or BS should have special mapping and the packets should be the AR or BS should have special mapping and the packets should be
distributed to all active point-to-point connections by the AR or by distributed to all active point-to-point connections by the AR or by
the BS. All-router multicast packets and any broadcast packets from the BS. All-router multicast packets and any broadcast packets from
a MS will be forwarded to the AR by the BS. If BS and MS are co- a MS will be forwarded to the AR by the BS. If BS and MS are co-
located, then the first approach is more useful. If the AR and BS located, then the first approach is more useful. If the AR and BS
are located separately then the second approach SHOULD be are located separately then the second approach should be
implemented. An initial capability exchange message should be implemented. An initial capability exchange message should be
performed between BS and AR (if they are not co-located) to determine performed between BS and AR (if they are not co-located) to determine
who would perform the distribution of multicast/broadcast packets. who would perform the distribution of multicast/broadcast packets.
Such mechansim should be part of L2 exchange during the connection Such mechansim should be part of L2 exchange during the connection
setup and is out of scope of this document. In order to save energy setup and is out of scope of this document. In order to save energy
of the wireless end-devices in the IEEE 802.16 wireless network, it of the wireless end devices in the IEEE 802.16 wireless network, it
is recommened that the multicast and broadcast from network side to is recommened that the multicast and broadcast from network side to
device side should be reduced. Only DHCP, IGMP, Router-advertisemnet device side should be reduced. Only DHCP, IGMP, Router advertisemnet
packets are allowed on the downlink for multicast and broadcast IP- packets are allowed on the downlink for multicast and broadcast IP
addresses. Other protocols using multicast and broadcast IP- addresses. Other protocols using multicast and broadcast IP
addresses should be permitted through local AR/BS configuration. addresses should be permitted through local AR/BS configuration.
Authors' Addresses Authors' Addresses
Syam Madanapalli Syam Madanapalli
Ordyn Technologies Ordyn Technologies
1st Floor, Creator Building, ITPL 1st Floor, Creator Building, ITPL
Bangalore - 560066 Bangalore - 560066
India India
skipping to change at page 16, line 4 skipping to change at line 580
USA USA
Email: samitac@ipinfusion.com Email: samitac@ipinfusion.com
Gabriel Montenegro Gabriel Montenegro
Microsoft Corporation Microsoft Corporation
Redmond, Washington Redmond, Washington
USA USA
Email: gabriel.montenegro@microsoft.com Email: gabriel.montenegro@microsoft.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 68 change blocks. 
297 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/