[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AD review of draft-ietf-shim6-proto -- section 5
Continuing with the review:
Substantial:
> The following options are defined for this message:
>
> Responder Validator: Variable length option. Typically a hash
> generated by the responder, which the responder uses
> together with the Responder Nonce value to verify that
> an I2 message is indeed sent in response to a R1
> message, and that the parameters in the I2 message are
> the same as those in the I1 message.
(Appears in multiple places in the document).
Is the use of this option mandatory? What about its copying
on the other side, if it is present? Please clarify.
> Locator List Generation: 32-bit unsigned integer. Indicates a
> generation number which is increased by one for each
> new locator list. This is used to ensure that the
> index in the Locator Preferences refer to the right
> version of the locator list.
Are there requirements on keeping this generation counter
unique across reboots, or would rolling back not cause
a problem? Is there a window that one should be following?
Are generation counters unique per context tag?
> +-------+----------+
> | Value | Method |
> +-------+----------+
> | 0 | Reserved |
> | | |
> | 1 | HBA |
> | | |
> | 2 | CGA |
> | | |
> | 3-255 | Reserved |
> +-------+----------+
I'm reading on, but what if it is the kind of
a combined HBA and CGA as described in the shim6-hba
draft? Presumably you indicate HBA if the locator
is in the fixed set and CGA if its in the dynamic,
but it would be good to clarify this.
> This option contains the CGA Parameter Data Structure (PDS). When
> HBA is used to verify the locators, the PDS contains the HBA
> multiprefix extension. When CGA is used to verify the locators, in
> addition to the PDS option, the host also needs to include the
> signature in the form of a CGA Signature option.
The Parameter Data Structure contains more than the
multiprefix extension, e.g., the public key, the
random bits instead of a public key for HBAs, and
any options unrelated to Shim6 that the CGA might
have. I would remove the second sentence above or
reword it to make sure that you really do include
the FULL CGA Parameter Data Structure.
Editorial:
> included, the packet would become larger than 1280 bytes.Another
s/[.]/. /
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Next Header | Hdr Ext Len |0| Type |Type-specific|0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Checksum | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> | Type-specific format |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Fields:
>
> Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59).
>
> Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in
> 8-octet units, not including the first 8 octets.
>
> P: Set to zero. A single bit to distinguish this from
> the Shim6 payload extension header.
>
> Type: 7-bit unsigned integer. Identifies the actual message
> from the table below. Type codes 0-63 will not
> trigger R1bis messages on a missing context, while 64-
> 127 will trigger R1bis.
>
> 0: A single bit (set to zero) which allows Shim6 and HIP
> to have a common header format yet telling Shim6 and
> HIP messages apart.
Here I got confused about the two 0's. The first one is P in the list,
the other one is "0". Maybe you need to set one of the zeroes in the
picture to something else (P or R), or add some text to make this
clearer.
Jari