Subject: [Cbor] CBOR Tag for IP address

From: Sean Leonard <[email-masked]>
Date: Thu, 21 Jul 2016 08:38:09 -0700

Hello:

Shall there be a CBOR tag for IP addresses?

I would propose that one tag be allocated, <<I>>; right now I’m thinking in the range of 40-255. If the byte string is 4 bytes, then it’s IPv4; if it’s 16 bytes, it’s IPv6; if it’s > 16, then it’s some IPvFuture.

And if people need arrays or maps of IP addresses, we can talk about that too. Not sure if people need subnet masks.

I recall that some hallway discussions in the past 2-3 IETFs suggested that it should be done. However, it has not been added to draft-bormann-cbor-tags-oid, or to any other draft, yet.

I have been reviewing draft-ietf-core-yang-cbor-02, and noted that while the example in Section 5.12 is “interesting”, it’s quite inefficient for ipv4-address and ipv6-address. Rather than having huge regular expression patterns, you can just transmit the octets, you know, the way that IP itself transmits them.

Regards,

Sean

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 03:48:48 +1200

I'm not convinced. I have running code based on (in CDDL)

ipv4-address = bytes .size 4
ipv6-address = bytes .size 16

with no particular problems.

    Brian

On 22/07/2016 03:38, Sean Leonard wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 21 Jul 2016 08:52:11 -0700

Semantic tagging is (almost) always optional. Whether you “need” it or not depends on the higher-level protocol.

RFC 7049:
2.4.  Optional Tagging of Items

   In CBOR, a data item can optionally be preceded by a tag to give it
   additional semantics while retaining its structure.  
...
   Their
   primary purpose in this specification is to define common data types
   such as dates.  A secondary purpose is to allow optional tagging when
   the decoder is a generic CBOR decoder that might be able to benefit
   from hints about the content of items.

So actually, I think your example proves the point...of how easy it is to specify IP addresses in a 4 or 16 byte string.

Sean

> On Jul 21, 2016, at 8:48 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 21 Jul 2016 09:31:15 -0700

Actually I should have rearranged my original e-mail. It was not meant to advocate for a particular outcome, but rather to generate discussion of a perceived problem and a possible solution:

One proposal could go as follows: one tag be allocated, <<I>>; right now I’m thinking in the range of 40-255. If the byte string is 4 bytes, then it’s IPv4; if it’s 16 bytes, it’s IPv6; if it’s > 16, then it’s some IPvFuture.

(From the CoRE/YANG perspective, typedef-ing IP addresses differently could also work.)

Regards,

Sean

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 19:44:12 +0200

We might take a page out of draft-ietf-anima-grasp-06.txt
  ipv4-address = bytes .size 4
  ipv6-address = bytes .size 16

Grüße, Carsten

Sean Leonard wrote:
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 07:30:03 +1200

>   ipv6-address = bytes .size 16

And to expand a bit on that, once one of those has emerged from
cbor.loads() as for example b, you do something like this (in Python):

if len(b) == 16:
    a = ipaddress.IPv6Address(b)
elif len(b) == 4:
    a = ipaddress.IPv4Address(b)
else:
    # error handling

and what you'd feed into cbor.dumps() would be a.packed

The advantage of having a defined tag and appropriate
support in dumps() and loads() would be to avoid that if
statement and simply use an object of class ipaddress.

   Brian