Subject: [Capwap] Proposed text for issue 247: MAC Addresses can be larger than 6 octets

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 19 Mar 2007 09:11:01 -0700

All,

As agreed upon during the IETF meeting in Prague, we wish to support MAC
Addresses that are greater than 6 octets in length. This was believed to
provide us with the most flexibility in terms of supporting future
protocols. During the meeting we discussed a few optoins and agreed on
using a variable length field, with an explicit length. However, I was
informed that the IEEE already has assigned explicit names for the 48
and 64 octet MAC Address fields (see
http://en.wikipedia.org/wiki/MAC_address for more information).
Therefore, it seemed prudent to rely on these IEEE MAC Address format
types, and use an enum instead of a length field.

One will note that the optional Radio MAC Address header already
included a length in order to allow for 64 bit MAC Addresses. That
header's length field was motified to a type field. 

Since IEEE 802.11 only uses 48 bit MAC Addresses, there is no point in
making changes to the binding specification. All changes below only
apply to the base protocol.

4.2.  CAPWAP Header
[...]

   Radio MAC Address:  This optional field contains the MAC address of
      the radio receiving the packet.  This is useful in packets sent
      from the WTP to the AC, when the native wireless frame format is
      converted to 802.3 by the WTP.  This field is only present if the
      'M' bit is set.  The HLEN field assumes 4 byte alignment, and this
      field MUST be padded with zeroes (0x00) if it is not 4 byte
      aligned.

      The field contains the basic format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |                  MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type:  The format of the MAC Address field.  The following values
         are supported:

         1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

         2 -   EUI-64 [19] which is a 64 bit MAC Address.

      MAC Address:  The MAC Address of the receiving radio.

4.5.7.  Add MAC ACL Entry

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   7 for Add MAC ACL Entry

   Length:   >= 8

   Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   MAC Addresses to add to the ACL.

4.5.8.  Add Station
[...]
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  VLAN Name...
     +-+-+-+-+-+-+-+-+

   Type:   8 for Add Station

   Length:   >= 8

   Radio ID:   An 8-bit value representing the radio

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   The station's MAC Address

4.5.9.  Add Static MAC ACL Entry

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   9 for Add Static MAC ACL Entry

   Length:   >= 8

   Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   MAC Addresses to add to the permanent ACL.

4.5.15.  Decryption Error Report

[...]

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |Num Of Entries |      Type       |MAC Address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   15 for Decryption Error Report

   Length:   >= 9

   Radio ID:   The Radio Identifier refers to an interface index on the
      WTP.

   Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   MAC addresses of the station that has caused
      decryption errors.
 
4.5.17.  Delete MAC ACL Entry

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   17 for Delete MAC ACL Entry

   Length:   >= 8

   Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   An array of MAC Addresses to delete from the ACL.

4.5.18.  Delete Station

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |      Type       |       MAC Address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   18 for Delete Station

   Length:   >= 8

   Radio ID:   An 8-bit value representing the radio

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   The station's MAC Address

4.5.19.  Delete Static MAC ACL Entry

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   19 for Delete Static MAC ACL Entry

   Length:   >= 8

   Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   An array of MAC Addresses to delete from the static
      MAC ACL entry.

4.5.21.  Duplicate IPv4 Address

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Status    |      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   21 for Duplicate IPv4 Address

   Length:   >= 12

   IP Address:   The IP Address currently used by the WTP.

   Status:   The status of the duplicate IP address.  The value MUST be
      set to 1 when a duplicate address is detected, and 0 when the
      duplicate address has been cleared.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   The MAC Address of the offending device.

4.5.22.  Duplicate IPv6 Address

[...]

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Status    |      Type       |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   23 for Duplicate IPv6 Address

   Length:   >= 24

   IP Address:   The IP Address currently used by the WTP.

   Status:   The status of the duplicate IP address.  The value MUST be
      set to 1 when a duplicate address is detected, and 0 when the
      duplicate address has been cleared.

   Type:  The format of the following MAC Address field.  One of the
      following values are supported:

      1 -   MAC-48 or EUI-48 [18], which is a 48 bit MAC Address.

      2 -   EUI-64 [19] which is a 64 bit MAC Address.

   MAC Address:   The MAC Address of the offending device.

16.3.  Informational References

[...]

   [18]  IEEE, "Guidelines for use of a 48-bit Extended Unique
         Identifier", Dec 2005.

   [19]  IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
         REGISTRATION AUTHORITY".

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 28 Mar 2007 14:15:28 -0700

Hi Pat,

It would seem to me that the right thing to do would be to have a
length(8 bits), a type (8bits) and then the MAC-address followed by the
padding (if any).

In your proposal, the "type" implies the "length" - which does not seem
the right approach (especially if one wants to encode it like a TLV).

Hence I would propose the following for supporting >6 byte MAC addr
(though one could flip the order of length/type):
******************

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Length     |    Type       |       MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length:  The number of bytes in the MAC Address field.  The length
         field is present since some technologies (e.g., IEEE 802.16)
         use 64 bit MAC addresses.

**********************
Thanks.

-Puneet  

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 9:11 AM
To: [email-masked]
Subject: [Capwap] Proposed text for issue 247: MAC Addresses can be
larger than 6 octets

All,

4.2.  CAPWAP Header
[...]

        0                   1                   2                   3

4.5.7.  Add MAC ACL Entry

[...]

      0                   1                   2                   3

   Length:   >= 8

4.5.8.  Add Station
[...]
      0                   1                   2                   3

   Type:   8 for Add Station

   Length:   >= 8

[...]

      0                   1                   2                   3

   Length:   >= 8

[...]

      0                   1                   2

   Length:   >= 9

 

[...]

      0                   1                   2                   3

   Length:   >= 8

4.5.18.  Delete Station

[...]

      0                   1                   2                   3

   Length:   >= 8

[...]

      0                   1                   2                   3

   Length:   >= 8

[...]

      0                   1                   2                   3

   Length:   >= 12

[...]

      0                   1                   2                   3

   Length:   >= 24

[...]

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 29 Mar 2007 07:01:19 -0700

Length and Type are redundant. The Type implies the length, as EUI-48
and EUI-64 have a fixed length. Furthermore, it's not clear that the
IEEE will have new types in the future. A one octet length then limits
you to a 255 address size, and if IEEE were to cook up something new,
who knows what the length would be. CAPWAP would not be able to support
excessively large MAC address lengths. The current proposal allows us to
handle 255 different IEEE MAC Address types, which seems like infinity
to me. 

Pat Calhoun

> From: Puneet Agarwal [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2007 2:15 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Proposed text for issue 247: MAC 
> Addresses can be larger than 6 octets
> 
> Hi Pat,
> 
> length(8 bits), a type (8bits) and then the MAC-address 
> followed by the padding (if any).
> 
> In your proposal, the "type" implies the "length" - which 
> does not seem the right approach (especially if one wants to 
> encode it like a TLV).
> 
> Hence I would propose the following for supporting >6 byte 
> MAC addr (though one could flip the order of length/type):
> ******************
> 
> Subject: [Capwap] Proposed text for issue 247: MAC Addresses 
> can be larger than 6 octets
> 
> All,
> 
> As agreed upon during the IETF meeting in Prague, we wish to 
> support MAC Addresses that are greater than 6 octets in 
> length. This was believed to provide us with the most 
> flexibility in terms of supporting future protocols. During 
> the meeting we discussed a few optoins and agreed on using a 
> variable length field, with an explicit length. However, I 
> was informed that the IEEE already has assigned explicit 
> names for the 48 and 64 octet MAC Address fields (see 
> Therefore, it seemed prudent to rely on these IEEE MAC 
> Address format types, and use an enum instead of a length field.
> 
> One will note that the optional Radio MAC Address header 
> already included a length in order to allow for 64 bit MAC 
> Addresses. That header's length field was motified to a type field. 
> 
> Since IEEE 802.11 only uses 48 bit MAC Addresses, there is no 
> point in making changes to the binding specification. All 
> changes below only apply to the base protocol.
> 
> 
> 4.2.  CAPWAP Header
> [...]
>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 29 Mar 2007 11:13:56 -0700

Hi Pat,

(a) One of the reasons that one wants to decouple length from type is
for backward/forward compatibility.
When "type" implies length, it has the side-effect that everyone must
understand the "type" to derive the "length". This implies that if one
does not understand "type" (typically a type not yet implemented by the
device under question), then one cannot even parse the rest of the
packet. This is typically a bad thing as it renders current
implementations useless once a newer "type" is introduced (even though
that "type" element may be an optional element that can be skipped).
This is especially true for data plane (and to some extend for optional
control plane elements as well).

If we have the "length" field (along with the "type"), then an
implementation that understands only types 1 and 2 for example, can
still safely parse packets containing type 3 by skipping the relevant
"length" bytes.

(b) To your other point about length of 255 being too small - I beg to
differ. We are talking about 255 bytes whereas the current type 1 and
type 2 MACs are 6 and 8 bytes respectively. Hence there is plenty of
room to grow for newer MACs and 255 bytes seems like infinity.

Decoupling type and length is an integral part of robust protocol
design.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 7:01 AM
To: Puneet Agarwal; [email-masked]
Subject: RE: [Capwap] Proposed text for issue 247: MAC Addresses can be
larger than 6 octets

Pat Calhoun

> Subject: RE: [Capwap] Proposed text for issue 247: MAC Addresses can 
> be larger than 6 octets
> 
> Hi Pat,
> 
> length(8 bits), a type (8bits) and then the MAC-address followed by 
> the padding (if any).
> 
> In your proposal, the "type" implies the "length" - which does not 
> seem the right approach (especially if one wants to encode it like a 
> TLV).
> 
> As agreed upon during the IETF meeting in Prague, we wish to support 
> MAC Addresses that are greater than 6 octets in length. This was 
> believed to provide us with the most flexibility in terms of 
> supporting future protocols. During the meeting we discussed a few 
> optoins and agreed on using a variable length field, with an explicit 
> length. However, I was informed that the IEEE already has assigned 
> explicit names for the 48 and 64 octet MAC Address fields (see 

> CTO, Wireless Networking Business Unit Cisco Systems

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 29 Mar 2007 14:51:01 -0700

Still disagree. If you don't recognize the type, then chances are you
do not support the relevant binding anyhow - so the binding never should
have been advertised, and you should never see these packets.

So two differing opinions. Any other comments from others?

Pat Calhoun

> Sent: Thursday, March 29, 2007 11:14 AM
> (a) One of the reasons that one wants to decouple length from 
> type is for backward/forward compatibility.
> When "type" implies length, it has the side-effect that 
> everyone must understand the "type" to derive the "length". 
> This implies that if one does not understand "type" 
> (typically a type not yet implemented by the device under 
> question), then one cannot even parse the rest of the packet. 
> This is typically a bad thing as it renders current 
> implementations useless once a newer "type" is introduced 
> (even though that "type" element may be an optional element 
> that can be skipped).
> This is especially true for data plane (and to some extend 
> for optional control plane elements as well).
> 
> If we have the "length" field (along with the "type"), then 
> an implementation that understands only types 1 and 2 for 
> example, can still safely parse packets containing type 3 by 
> skipping the relevant "length" bytes.
> 
> (b) To your other point about length of 255 being too small - 
> I beg to differ. We are talking about 255 bytes whereas the 
> current type 1 and type 2 MACs are 6 and 8 bytes 
> respectively. Hence there is plenty of room to grow for newer 
> MACs and 255 bytes seems like infinity.
> 
> Decoupling type and length is an integral part of robust 
> protocol design.
> 
> Thanks.
> 
> -Puneet
> 
> Length and Type are redundant. The Type implies the length, 
> as EUI-48 and EUI-64 have a fixed length. Furthermore, it's 
> not clear that the IEEE will have new types in the future. A 
> one octet length then limits you to a 255 address size, and 
> if IEEE were to cook up something new, who knows what the 
> length would be. CAPWAP would not be able to support 
> excessively large MAC address lengths. The current proposal 
> allows us to handle 255 different IEEE MAC Address types, 
> which seems like infinity to me. 
> 
> Pat Calhoun
>         3
> Address format 
>         3
> >      |                          IP Address                  
>          |
> >      |                          IP Address                  
>          |
> >      |                          IP Address                  
>          |
> >      |                          IP Address                  
>          |
> >      |                          IP Address                  
>          |