Hi, added softwires cc. This really belongs on the mailing list.
> My understanding there already was agreement on format. Recommend > maintaining current -04 format instead of these changes. I suggested this on the softwires mailing list because it has a number of advantages. Right now there are at least two drafts which need to encode structured information. There is one agreed model how to encode this, it's the extended type TLV. If both drafts have their own complex encoding, it's double work: everyone needs to write their own parser for their own attribute. As time goes by, there will be more drafts needing to encode some complex information. Consolidation of such complex types into a common format is a good thing IMHO. OTOH, using the new TLVs, only one parser needs to be written, *and* that code is reusable for future attributes with complex encoding needs with no extra effort. >> IPv6-6rd-Configuration Attribute >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Extended-Type |M| Flag | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Suboptions | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Type 245, extended-type TBD. > > Using Extended-Type means you would have to wait for the extensions > draft to be an RFC in order to be assigned an Extended-Type. That's right. It is the only drawback. If you choose to go the custom-encoding way, you avoid a bit of waiting time at the expense of extra, non-reusable code in every 6rd implementation. > Compromised solution I originally suggested (Currently > draft-ietf-softwire-6rd-radius-attrib-04) sought to avoid dependencies > on other drafts while at the same time providing maximum compatibility > with existing and future systems. It requires an implementer to write one parser specifically for the 6rd-attribute, with no code re-use for other attributes that will be defined in the future. The code needs to be maintained separately from the a generic extended-attributes parser. That sounds rather short-sighted to me and goes contrary to the claim of "compatibility with future systems". I'm not sure what "compatibility with existing systems" should mean. Existing systems can't make anything out of the IPv6-6rd-Configuration attribute, because they can't parse the content. All they can do is ignore the attribute. They can do that with an extended-type attribute just as well. Greetings, Stefan Winter > >> IPv4MaskLen suboption >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sub-Type | Length | IPv4MaskLen | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Subtype 1 > >> 6rdPrefix suboption >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | sub-Type | Length | 6rdPrefixLen | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + >> | | >> + 6rdPrefix + >> | | >> + + >> | | >> + +-+-+-+-+-+-+-+-+ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Subtype 2 > > Prefix attribute was implemented a decade ago in RFC 3162 2.3. 1-octet > reserved field before prefix length is required. > > regards, > Peter -- 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
