On Thu, 22 Dec 2011, Stefan Winter wrote:
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".
There are a few areas implementors should take care to read the draft
carefully. I don't have a better idea.
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".
A IPv6 prefix describes one thing not a collection of related things
belonging together. You can't pull apart a prefix into pieces that mean
anything by themselves.
By convention a prefix is always expressed as a single field wherever it
is entered or displayed (fe80::/16)
A prefix does not contain an IP Address.
TLVs have no global type space. Elements of generally applicable
composite types must be redefined separately within each instance they are
used.
regards,
Peter
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
