| Re: CAPWAP transport for IPv6 | <– Date –> <– Thread –> |
|
From: Puneet Agarwal (pagarwal |
|
| Date: Mon, 20 Aug 2007 17:46:08 -0700 (PDT) | |
Hi Abhijit,
UDPLite for IPv6 is a fine compromise (especially
when there are no firewalls between WTP and AC) for functionality without the
checksum computation expense.
Hence I am not OK with making UDP for IPv6
mandatory.
Thanks.
-Puneet
From: Abhijit Choudhury (achoudhu) [mailto:achoudhu [at] cisco.com]
Sent: Tuesday, August 07, 2007 1:59 PM
To: capwap
Subject: [Capwap] CAPWAP transport for IPv6
At the last
IETF, the transport A-Ds raised some interesting
issues
related to the use of UDP-Lite for IPv6. Specifically, the
issues
related to traversal of NAT, V4-V6 gateways, and firewalls
need some
serious consideration.
The choice
of UDP-Lite as the transport for IPv6 was based on
performance
reasons. Most ACs today do the 802.3-to-802.11
conversion
and encapsulation in hardware, and in our discussions
the consensus was that requiring checksum computation in
hardware
would be expensive. However, it seems that the
CAPWAP protocol
has serious issues related to traversal of NATs and
firewalls
when using IPv6 since such boxes don't typically
support UDP-Lite.
This means that we should make UDP the mandatory transport
for
IPv6. We could still allow for UDP-Lite when there are
translation
gateways and
firewalls present.
Thoughts/comments ?
Abhijit
p.s.
Proposed text for updating Section 3 is provided
below.
Other
minor changes will be needed to remove mention of UDP-Lite in
the
document.
---------------------- PROPOSED TEXT
----------------------------------
3. CAPWAP
Transport
Communication
between a WTP and an AC is established according to the
standard UDP client/server model. The CAPWAP protocol uses UDP as the
standard UDP client/server model. The CAPWAP protocol uses UDP as the
transport protocol for both IPv4 and IPv6. This section describes how
the CAPWAP protocol is carried over IP and UDP
protocols.
3.1. UDP
Transport
One of the
CAPWAP protocol requirements is to allow a WTP to reside
behind a firewall and/or Network Address Translation (NAT) device.
Since a CAPWAP session is initiated by the WTP (client) to the well-
known UDP port of the AC (server), the use of UDP is a logical
choice. For IPv4, the UDP checksum field in CAPWAP packets MUST be
behind a firewall and/or Network Address Translation (NAT) device.
Since a CAPWAP session is initiated by the WTP (client) to the well-
known UDP port of the AC (server), the use of UDP is a logical
choice. For IPv4, the UDP checksum field in CAPWAP packets MUST be
set to zero.
CAPWAP protocol
control packets sent from the WTP to the AC use the
CAPWAP control channel, as defined in Section 1.4. The CAPWAP
control port at the AC is the well known UDP port [to be IANA
assigned]. The CAPWAP control port at the WTP can be any port
selected by the WTP.
CAPWAP control channel, as defined in Section 1.4. The CAPWAP
control port at the AC is the well known UDP port [to be IANA
assigned]. The CAPWAP control port at the WTP can be any port
selected by the WTP.
CAPWAP protocol
data packets sent from the WTP to the AC use the
CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port
at the AC is the well known UDP port [to be IANA assigned]. The
CAPWAP data port at the WTP can be any port selected by the WTP.
CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port
at the AC is the well known UDP port [to be IANA assigned]. The
CAPWAP data port at the WTP can be any port selected by the WTP.
<DELETE Section
3.2>
-
CAPWAP transport for IPv6 Abhijit Choudhury (achoudhu), August 7 2007
- Re: CAPWAP transport for IPv6 Abhijit Choudhury (achoudhu), August 7 2007
- Re: CAPWAP transport for IPv6 Suds, August 7 2007
- Re: CAPWAP transport for IPv6 Puneet Agarwal, August 20 2007
-
Re: CAPWAP transport for IPv6 Rohit Suri (rsuri), August 20 2007
- Re: CAPWAP transport for IPv6 Abhijit Choudhury (achoudhu), August 21 2007
- Re: CAPWAP transport for IPv6 Puneet Agarwal, August 23 2007
- Re: CAPWAP transport for IPv6 Pat Calhoun (pacalhou), August 28 2007
Results generated by Tiger Technologies using MHonArc.