Candidate Access Router Discovery (CARD)

Note: This ballot was opened for revision 08 and is now closed.

(Allison Mankin) Yes

Comment (2004-03-30 for -)
No email
send info
Jim Kempf is addressing Thomas/Ted comments by putting the ICMP in one exper type
for all mobile expers - separate i-d.  I have cleared a worry I had about transport
congestion because the protocol is only inter-router.  Here is some information about
addressing the Sec ADs' concerns:

Date:    Mon, 22 Mar 2004 16:21:08 -0500
From:    Russ Housley <>
To:      "James Kempf" <>,
         "Steve Bellovin" <>
cc:      <>,"Kempf" <>

Resolves my concerns .....


At 12:58 PM 3/12/2004 -0800, James Kempf wrote:
>Hi Steve and Russ,
>With reference to your discuss comment on
>8&rfc_flag=0, 2004-2-18), I rewrote the Security Considerations section to
>address the comments. I've attached the revised section and a copy of the
>old section for your reference, and would like to get comments about whether
>you think it adequately addresses your concerns. In particular, I took
>Steve's suggestion to use the SEND SA for the router to host authentication,
>and Russ's points about lack of attention to key distribution on the router
>to router SA. I also fixed a bunch of other issues that I think needed
>Please let me know if this is acceptable, or if further work is necessary.
>             jak

(Steven Bellovin) (was Discuss) No Objection

(Margaret Cullen) No Objection

(Ned Freed) No Objection

Comment (2004-02-12 for -)
No email
send info
Nit: (date) in copyright boilerplate

Question: Is the IPR section on this document the right thing to have under the
new rules?

(Ted Hardie) (was No Record, Discuss) No Objection

Comment (2004-02-18 for -)
No email
send info
This seems to be a very large consumption of IANA resources for an experimental protocol:

  The protocol described in this document requires a new ICMP type to 
   be assigned by the IANA for the CARD protocol main header (Section 
   5.1.1). Furthermore, two new ICMP option types (Section 5.1.2) are 
   to be assigned for the protocol operation between a Mobile Node and 
   its current Access Router for the Mobile IP Fast Handover Protocol 
   [Kood03] and for the standalone use of CARD between the MN and AR. 
   The protocol also requires a UDP port number to be assigned for the 
   inter-Access Router CARD protocol operation (Section 5.2.1). To 
   uniquely identify specific access technologies in the L2-Type field 
   of a CARD L2 ID sub-option, the IANA should also set up a registry 
   to assign fixed numbers for well-known access technologies (Section Initially, values for IEEE802.11a, IEEE802.11b and 
   IEEE802.11g should be assigned. To allow MNs receiving unsolicited 
   CARD Reply messages only in case they are of interest to them, a 
   well-known multicast IP address for IPv4 and IPv6 (link-local) needs 
   to be assigned by IANA for that purpose (section 7).   
Are there ways to offload this during the experimental phase so that
some of the effort is spared and some of the values not permanently
burned during the testing?

I have to say that the overall design seems quite heavyweight for the purpose,
especially in the expectation that each AR will maintain the tables of both
L2 to IP mappings and capabilities.  I'd be curious to hear more about the
environments where this is expected to see deployment (especially where
the unsolicited multicast "reply" messages are expected to be useful, since
they seem to get to be large table dumps in some of the deployments I
could imagine).

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-02-18)
No email
send info
  Expand 'AP' and 'PCF' the first time they are used.

  In section 3.2: s/optimized handover/optimal handover/

(David Kessens) No Objection

(Thomas Narten) (was Discuss) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) (was Discuss) No Objection