Re: CARD: Modification in resolution to issues #49 and #51

James Kempf wrote:

>It turns out there are some constraints imposed on the resolution of issues
>#49 and #51 by the fact that CARD messages are sent as options on Neighbor
>Discovery in IPv6, or Mobile IPv4 ICMP messages in IPv4. These constraints
>require modification to the recommended resolutions as follows:
>
>issue-#49: Length indicator for Router Certificate sub-option:
>
>The recommended resolution was to change all field lengths to 16 bits with
>units of octets, rather than 8 bits with units of 8 octets. It turns out
>that the length field is constrained by the ND options TLD format to be 8
>bits with units of octets, allowing a maximum of about 2K octets. This is
>not long enough for a general certificate chain. Most X.509 certs are rather
>long, typically on the order of about 1K, so more than on cert is unlikely
>to fit into a message.
>
>The following is a modification of the resolution to meet these constraints:
>
>- Change the Router Certificate suboption length units to 8 octets.
>
>- Drop the Context ID and require only a Address Option and L2-ID option in
>a message with a certificate.
>
>  
>
Why do you propose to drop the context-ID? It allows assignment of L2-ID 
with an IP address
sub-option and with a capability container. If a capability container 
for a CAR is transmitted in a
subsequent reply message (according to the mechanism proposed below, 
this allows the mobile
to identify which L2-ID, IP and Capability Container info belongs to 
which CAR.
If you propose to convey only information of one CAR in one CARD Reply 
message
and it's for sure that no further information for this CAR comes in 
subsequent reply messages,
the Context-ID can at least identify information that belongs together.
And if the cert in not sent in a reply message, multiple CARs' info can be
conveyed in one reply. Here you need the context-ID. So, you should not 
drop it.

>- If more than one certificate is required, the router sends multiple CARD
>Reply Messages.
>  
>

>- Add a flag indicating if the certificate is the last one to be sent. The
>host should be able to deduce this by whether the chain is complete.
>
>  
>
What's the rule here for setting sequence numbers in multiple CARD 
Replies? Should be the same
for all replies associated with one request, right?

>In addtion, the following modification is advisable, since X.500 names used
>for certificates can be long:
>
>- Modify the units for the Trusted Anchor option from octets to 8 octets.
>
>issue-#51: Version number needed.
>
>The TLV format of the ND options won't allow the version number to be put
>into the lower bits of the option type, since the type is assigned by IANA.
>
>The following is a modification of the resolution to meet these constraints;
>
>- Put the 3 bit version number immediately after the T and L fields, which
>are specified by RFC 2461.
>
>  
>
Why exactly 3 bit for the version number?  The first 32 bit will look like
Type(8bit), Length(8bit), version(3bit),reserved(5bit), P,C,A(flags, 
each 1bit), reserved(5bit)...

alternatively use 8 bit for the version number, which is redundant, but 
assigns a byte for
a nuber identifier. This would look like
Type(8bit), Length(8bit), version(8bit), P,C,A(flags, each 1bit), 
reserved(5bit)...

what do you think?
marco

>Comments?
>
>            jak
>
>
>
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>