Hi, >> Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into >> one blob in -04? > > If you ignore the 6rd references it is describing prefix data type > defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix). Logically it > counts as one field.
Framed-IPv6-Prefix and your data type are different. Frames-IPv6-Prefix is of variable length, and requires to insert only those parts of the IPv6 address which are relevant for the prefix length. You can pad with more zeroes if you feel like it, but don't have to. (That in itself is a rather inconvenient construct, and I like yours more than that one actually.) Sure, if you opt to always pad with zeroes to the full 128 bit, even if not necessary, you get the same fixed length as your datatype requires. Still, you have introduced a new data type "almost-but-not-quite-Framed-IPv6-Address". If you consider it a good idea, then fine - I'm sure you have much more experience in terms of actual implementations than I do. From a design point of view, I'd consider a pair of (int,IPv6-Address) cleaner than an implicit struct. The "belong together" can be expressed in the RFC as "both of the sub-TLVs have to appear exactly once". Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
