On Wed, 21 Dec 2011, Stefan Winter wrote:
I don't think this is correct. The extensions document describes a
*data type* 'TLV'. My suggestion simply leverages this type in the same
way IPv4 Address and IPv6 prefix type from existing RFCs are already
being leveraged.
If you implement extensions RFC in the future your implementation
supports the TLV data type giving you the ability to encode and decode
this attribute with configuration dictionaries. The wire format of
IPv6-6rd-Configuration was intentionally made to be the same as a TLV.
Ah! I'm just looking at the -04 with this extra context. It's certainly
close. I think there's only one thing which is not inline: 6rdprefixLen
and 6rdPrefix immediately follow each other. In a version
compatible/analogous to the radius-extensions draft, the former would be
of type integer, the latter of type IPv6Address, and each would have its
own (Subtype,SubLen) tuple.
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.
regards,
Peter
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
