Subject: Re: [Capwap] CAPWAP transport for IPv6

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Oct 2007 17:03:06 -0400

<chair hat="off">

This would also make sense to me, personally.

Margaret

On Aug 22, 2007, at 1:13 AM, Abhijit Choudhury (achoudhu) wrote:

> I am okay with Rohit's suggestion of keeping UDP-Lite as
> the mandatory transport over IPv6 for the data channel
> and adding the ability to negotiate UDP for the datapath
> in case middle-boxes are present.  For this to work, we
> would need UDP to be mandatory for the control channel.
>
>
> This seems like a fine compromise to me.  This retains the
> performance benefits of UDP-Lite for most deployments, and
> allows us to handle deployment scenarios where NATs, firewalls, and  
> V4-V6
> translators.
>
> In summary, we will have UDP as mandatory for the control channel
> for both IPv4 and IPv6. UDP will be mandatory for the data channel
> for IPv4, and for IPv6, UDP-Lite will be mandatory, and UDP optional.
>
> Thanks,
> Abhijit
>
>
>
>
> From: Rohit Suri (rsuri)
> Sent: Monday, August 20, 2007 5:55 PM
> To: Puneet Agarwal; Abhijit Choudhury (achoudhu); capwap
> Subject: RE: [Capwap] CAPWAP transport for IPv6
>
> I agree with Puneet. Abhijit correctly pointed out,
> "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,V4-V6 gateways and  
> firewalls
> when using IPv6 since such boxes don't typically support UDP-Lite"
>
> I think it does not make sense to sacrifice performance just to  
> handle the
> scenario where there may be V4-V6 gateways deployed in the future.
> Instead, in such network configurations, we should allow the
> protocol to negotiate the use of UDP  data transport in IPv6 networks.
> The default should remain UDP-Lite as that will give most performance
> for common network deployments.
>
> In order to have support for both UDP and UDP-Lite, CAPWAP control
> should always use UDP and for CAPWAP data UDP/UDP-Lite should be
> negotiated. This negotiation can be easily completed as part of CAPWAP
> config request/response.
>
> This solution ensures that performance is not compromised
> for the majority of deployments where there is no need to
> run CAPWAP over NAT, firewalls or V4-V6 gateways by running CAPWAP  
> data
> over UDP-Lite.  At the same time, it incorporates the flexibility
> to negotiate UDP for the data path, if NATs, firewalls and V4-V6  
> translators
> are present.
>
> Regards
> Rohit
>
> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Monday, August 20, 2007 5:46 PM
> To: Abhijit Choudhury (achoudhu); capwap
> Subject: Re: [Capwap] CAPWAP transport for IPv6
>
> 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:[email-masked]]
> 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
>    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
>    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 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.
> <DELETE Section 3.2>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 3 Oct 2007 17:04:27 -0400

<chair hat="off">

Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 Oct 2007 13:31:57 -0700

Can we call this "rough consensus"?

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 2:04 PM
To: Abhijit Choudhury (achoudhu)
Cc: capwap
Subject: Re: [Capwap] CAPWAP transport for IPv6

<chair hat="off">

Margaret

On Aug 22, 2007, at 1:13 AM, Abhijit Choudhury (achoudhu) wrote:

> I am okay with Rohit's suggestion of keeping UDP-Lite as the mandatory

> transport over IPv6 for the data channel and adding the ability to 
> negotiate UDP for the datapath in case middle-boxes are present.  For 
> this to work, we would need UDP to be mandatory for the control 
> channel.
>
>
> This seems like a fine compromise to me.  This retains the performance

> benefits of UDP-Lite for most deployments, and allows us to handle 
> deployment scenarios where NATs, firewalls, and
> V4-V6
> translators.
>
> In summary, we will have UDP as mandatory for the control channel for 
> both IPv4 and IPv6. UDP will be mandatory for the data channel for 
> IPv4, and for IPv6, UDP-Lite will be mandatory, and UDP optional.
>
> Thanks,
> Abhijit
>
>
>
>
> From: Rohit Suri (rsuri)
> I agree with Puneet. Abhijit correctly pointed out, "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,V4-V6 gateways and firewalls when using IPv6 since such boxes 
> don't typically support UDP-Lite"
>
> I think it does not make sense to sacrifice performance just to handle

> the scenario where there may be V4-V6 gateways deployed in the future.
> Instead, in such network configurations, we should allow the protocol 
> to negotiate the use of UDP  data transport in IPv6 networks.

> config request/response.
>
> This solution ensures that performance is not compromised for the 
> majority of deployments where there is no need to run CAPWAP over NAT,

> firewalls or V4-V6 gateways by running CAPWAP data over UDP-Lite.  At 
> the same time, it incorporates the flexibility to negotiate UDP for 
> the data path, if NATs, firewalls and V4-V6 translators are present.
>
> Regards
> Rohit
>
> firewalls between WTP and AC) for functionality without the checksum 
> computation expense.
> 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.
>
> 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
>
> the document.
>    Communication between a WTP and an AC is established according to 
> the
>    standard UDP client/server model.  The CAPWAP protocol uses UDP as 
> the
>    transport protocol for both IPv4 and IPv6.  This section describes 
> how

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 11 Oct 2007 13:25:05 -0700

In 4.6.26 of draft-07, there is a File Size field that is 16 bits in
length.  It is not clear what this value represents.  Is it in bytes?
If so, it is not large enough.  Is it in 1024-byte blocks?  This should
be made clear in the spec.

 -Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 12 Oct 2007 09:02:08 -0700

Issue 17 created

PatC 

-----Original Message-----
From: Bob O'Hara (boohara) 
Sent: Thursday, October 11, 2007 1:25 PM
To: capwap
Cc: Pat Calhoun (pacalhou)
Subject: Image file size ambiguity

 -Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 12 Oct 2007 12:53:22 -0700

Proposed text below:

<Proposed Text>
4.6.29.  Image Information

   The Image Information message element is present in the Image Data
   Response message sent by the AC to the WTP and contains the following
   fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           File Size                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   26 for Image Information

   Length:   18

   File Size:   A 32-bit value containing the size of the file, in
      bytes, that will be transfered by the AC to the WTP.

</Proposed Text>

PatC 

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Friday, October 12, 2007 9:02 AM
To: Bob O'Hara (boohara); capwap
Subject: Re: [Capwap] Image file size ambiguity

Issue 17 created

PatC 

-----Original Message-----
From: Bob O'Hara (boohara)
Sent: Thursday, October 11, 2007 1:25 PM
To: capwap
Cc: Pat Calhoun (pacalhou)
Subject: Image file size ambiguity

 -Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025