You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For reasons discussed in elastic/elasticsearch#38064, the ip indexing cannot be adjusted to include support for the Zone ID. Stripping it out is a lossy option, which people are free to do.
But we need to add support for the cases where we want to retain the Zone ID information.
Section 11.3 of RFC 4007 shows a few example of the kind of data that can be expected in a Zone ID. It's mostly likely integers ("1" here: fe80::1234%1), or network device names ("interface10" here ff08::9abc%interface10).
So I suggest we add a sister .ip_zone field everywhere we support an .ip field. This field should be of datatype keyword, and I would have it be an extended field.
The text was updated successfully, but these errors were encountered:
For reasons discussed in elastic/elasticsearch#38064, the
ip
indexing cannot be adjusted to include support for the Zone ID. Stripping it out is a lossy option, which people are free to do.But we need to add support for the cases where we want to retain the Zone ID information.
Section 11.3 of RFC 4007 shows a few example of the kind of data that can be expected in a Zone ID. It's mostly likely integers ("1" here:
fe80::1234%1
), or network device names ("interface10" hereff08::9abc%interface10
).So I suggest we add a sister
.ip_zone
field everywhere we support an.ip
field. This field should be of datatypekeyword
, and I would have it be an extended field.The text was updated successfully, but these errors were encountered: