---- On Thu, 02 Aug 2018 15:06:50 +0100 Herwin <notificati...@github.com>
wrote ----
> @herwinw commented on this pull request.
>
> In print-radius.c:
> > @@ -569,6 +597,8 @@ static struct attrtype { { "Digest-HA1",
> NULL, 0, 0, print_attr_string }, { "SIP-AOR",
> NULL, 0, 0, print_attr_string }, { "Delegated-IPv6-Prefix",
> NULL, 0, 0, print_attr_netmask6 },+ { "MIP6-Feature-Vector",
> NULL, 0, 0, print_attr_vector64 },+ { "MIP6-Home-Link-Prefix",
> NULL, 0, 0, print_attr_netmask6 }, fun fact: freeradius and
> wireshark both use the same format as Framed-IPv6-Prefix and
> Delegated-IPv6-Prefix for this structure. This might require some "be
> liberal in what you accept" to make it work.
The IANA RADIUS Types registry currently lists 6 types with the "ipv6prefix"
type:
```
170 Route-IPv6-Information [RFC6911]
152 PMIP6-Visited-HN-Prefix [RFC6572]
151 PMIP6-Home-HN-Prefix [RFC6572]
125 MIP6-Home-Link-Prefix [RFC5447]
123 Delegated-IPv6-Prefix [RFC4818]
97 Framed-IPv6-Prefix [RFC3162]
```
The type 125 (MIP6-Home-Link-Prefix) is the only one that has the encoding
clearly different from the rest. This is how RFC 5447 defines it, and the
current list of errata for this RFC does not concern this difference, which
looks intentional as Section 4.2.4 of the spec says: "The MIP6-Home-Link-Prefix
AVP (AVP Code 125) is of type OctetString" and the IANA Considerations section
does not mention the type explicitly.
It looks like the allocation in the IANA registry was done incorrectly for type
125, perhaps because the attribute has "prefix" in its name. Then, if the
authors of respective Wireshark and FreeRADIUS code took the attribute type
from the registry and did not check it thoroughly in RFC 5447, that would
explain why that code (incorrectly) handles MIP6-Home-Link-Prefix as an IPv6
prefix attribute (whereas it is OctetString) -- it just copies the error in the
registry allocation.
I do not see a good way to accept both encodings for this attribute, given the
way each encoding is defined. Are you aware of any other code that has copied
this error, especially in the network devices firmware?
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
