Re: [Int-area] Fwd: I-D ACTION:draft-bagnulo-cga-ext-00.txt

["James Kempf" <[e-mail]>]

FWIW, I presented an extension of CGAs, called multikey CGAs, that can be 
used in cases where more than one node can legitimately claim an address to 
Mobopts (draft-kempf-mobopts-ringsig-ndproxy-02.txt) in Paris, for example, 
multicast, anycast or Proxy ND. This would require an extension to the CGA 
Parameters field.

            jak

----- Original Message ----- 
From: "marcelo bagnulo braun" <[e-mail]>
To: "Thomas Narten" <[e-mail]>
Cc: "Internet Area" <[e-mail]>
Sent: Tuesday, December 06, 2005 9:24 AM
Subject: Re: [Int-area] Fwd: I-D ACTION:draft-bagnulo-cga-ext-00.txt


Hi Thomas,

El 06/12/2005, a las 15:09, Thomas Narten escribió:

> marcelo bagnulo braun <[e-mail]> writes:
>
>> El 02/12/2005, a las 12:16, Francis Dupont escribió:
>
>>>  In your previous mail you wrote:
>>>
>>>    This is a very simple and short draft that defines a format for CGA
>>>    extensions.
>>>
>>> => IMHO the main interest of the document is its IANA consideration
>>> section, isn't it?
>>>
>
>> indeed
>
>> the draft defines a namespace for cga extensions that is to be managed
>> so that if multiple extensions are defined they can be recognized and
>> can be used together without interfering with each other
>
> This I don't quite understand. It sounds to me like you are trying to
> associate random extensions with a particular CGA Message Type Name
> Space (which may well be OK).
>

i don't think this is what is done in this draft...

> But exactly what protocols would carry such extensions? And wouldn't
> _those_ protocols need to define the type field (as I think it would
> be relative to that protocol)?
>

but the extensions defined are to be included in the CGA parameter data
structure i.e. as part of the hash input (as opposed to part of a
protocol message) see below...

> What this document seems to be doing is defining a TLV option space,
> but the TLV numbering space isn't associated with any specific
> protocol.

right

>   I don't understand how that would be used. Can you give an
> example of a specific protocol where the TLV option would be carried?
>

Well, the first example that i can point out is the HBA multiprefix
extension for CGAs defined in draft-ietf-shim6-hba-01
The multiprefix extension of HBA defines an extension for CGAs in order
to include information about multiple prefixes in the input of the hash
which output is included in the interface identifier part of the
resulting CGA addresses. This multiprefix extension is used by the
shim6 protocol (draft-ietf-shim6-proto-02)

Now, at the time of the design of the HBAs, one issue that was
discussed was whether the HBAs were to be defined as an extension of
the CGAs or as a different kind of addresses (i.e. not related to
CGAs). (I mean, it was possible to define the HBas as addresses that
contained the hash of the prefix set in the iid part of the addresses
but not respecting the CGA parameter data structure, or its
generation/verification procedures, nor considering the possibility of
including a public key as input in the hash).
The decision was to define the HBAs as an extension of the CGA i.e.
define the multiprefix extension in order to generate the HBAs. The
reason for that was two-folded: i) on one hand it should be noted that
both the HBAs and the CGAs use the same bits of the iid to store
information (in one case the hash of a public key and in the other case
the hash of a prefix set). If we define HBAs and CGAs as different
things, it wouldn't be possible to use the protocols the use CGAs and
the protocols that use HBAs simultaneously e.g. it wouldn't be possible
to use SeND (that uses CGAs) and SHIM6 (that uses HBAs) with the same
address. ii) on the other hand, it was useful for the shim6 protocol to
have addresses that provide the CGA and HBA capabilities simultaneously
(but this is a shim6 story that is not really relevant for this
discussion)

But in any case, the bullet i) above may provide some insight why the
extensions are needed. Two protocols, SeND and SHIM6, need to include
information in the iid part of the address in the form of a hash. If we
use non-unified approaches to include the different informations, then
we end up not being able to use a single address for the different
protocols, which seems highly undesirable (i.e. having to choose if we
prefer SHIM6 or SeND for a given communication).
The problem of CGAs and HBAs was solved by defining the HBAs as CGA
extensions. But suppose now that another protocol X need to include
other information in the iid part of the addresses how would this be
done? Probably, the approach would be to define another CGA extension
extension X, so that the resulting address can carry CGA information,
and the X information. Probably, we also want to be able to run the new
protocol X and SeND and SHIM6 with the same addresses right? (i.e. that
a host does not need to have protocol-specific addresses)
In order to do that we will need to generate the iid part of the
address as the output of the hash with input the CGA parameter data
structure, the mutliprefix extension (HBA) and the X extension, right?

The problem is that there is no defined format for the CGA extensions,
no it is not obvious that there is no collisions in the way that the
CGA extensions are defined, and it is not obvious to recognize the
different extensions defined for CGA. Hence the need for defining a TLV
CGA extension format.

If such standard format for CGA extensions is not defined it is
possible that two different extensions end up with the same bit pattern
for their extensions, making its simultaneous usage impossible since it
wouldn't be possible to differentiate them.

makes sense?

regards, marcelo




> Tomas
>


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area 


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area