[DNSOP] Re: [dtn] Re: [EXT] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

[Scott Johnson <[e-mail]>]

Hi Marc,

> I agree with using DNS-SD instead. I for one, also suggested that years 
> ago.

Of course, you are free to use DNS-SD instead.  What you choose to publish 
in your zone files is your administrative perogative.  One can presently 
use either SLAAC or DHCPv6, or manual assignment to deploy IPv6 addresses, 
right?  I see no difference here in principle.  That said, I am not sure I 
have "years ago" to wait for a solution, and this one both meet my (and 
likely many others) needs, and is almost done (about a month in-progress) 
including a supplementary Individual Informational draft to clarify 
presentation and wire formats upon request, per the rules of RFC6895 
governing this registry.

Thanks,
Scott

>
> Marc.
>
>>
>> One possible extension to the DNS-SD profile is to define a service parameter ("bpnodeid" or similar) which would allow exposing the node's administrative EID in the DNS-SD registration. This opens the door to some security considerations about authenticating ownership of that EID, but it is a possible mechanism on a closed and trusted network.
>>
>> Another possibility is to use existing CERT RR [3] to store certificates asserting ownership of one or more EIDs, which are already defined as a PKIX profile in RFC 9174 [4]. My main concern with just having a bare EID (or part of an EID in this case, just the IPN node number) in DNS is that there is no way to assign a chain of trust to some authority of BP node naming.
>>
>> Thanks for consideration of this feedback,
>> Brian S.
>>
>> [1] https://www.ietf.org/archive/id/draft-sipos-dtn-edge-zeroconf-01.html#section-3
>> [2] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>> [3] https://www.rfc-editor.org/rfc/rfc4398.html
>> [4] https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2
>>
>>> -----Original Message-----
>>> From: Scott Johnson <[e-mail]>
>>> Sent: Tuesday, June 25, 2024 5:57 AM
>>> To: Erik Kline <[e-mail]>
>>> Cc: dnsop <[e-mail]>; [e-mail]; [e-mail]
>>> Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
>>> Protocol RFC9171
>>>
>>> APL external email warning: Verify sender [e-mail] before
>>> clicking links or attachments
>>>
>>> Hi Erik,
>>>
>>> Cross posted to DTN list for any such discussion, if they so desire.
>>> The draft in question is here:
>>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>
>>> Thanks,
>>> ScottJ
>>>
>>> On Tue, 25 Jun 2024, Erik Kline wrote:
>>>
>>>> Speaking as the responsible AD for DTN, I think the DTN working group
>>>> should probably have a discussion about what it wants to do (if
>>>> anything) vis. DNS RRs.
>>>>
>>>> On Tue, Jun 25, 2024 at 08:27 Scott Johnson <[e-mail]>
>>>> wrote:
>>>>      Hi Mark,
>>>>
>>>>      On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>
>>>>>
>>>>>
>>>>>> On 25 Jun 2024, at 16:36, Scott Johnson
>>>>      <[e-mail]> wrote:
>>>>>>
>>>>>> Hi Mark,
>>>>>>
>>>>>> Noted and changed.  Good stuff, thanks.  Updated draft
>>>>      (04) at datatracker using that verbiage:
>>>>>>
>>>>      https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>
>>>>>> Is it appropriate to add an acknowledgments section or
>>>>      co-authors at this point?
>>>>>
>>>>> I’m not fussed either way.
>>>>
>>>>      (05) of the draft adds a "Contributors" section.
>>>>
>>>>>
>>>>>> As well, should I be asking for WG adoption (DNSOP or
>>>>      DTN WG), or as an Informational document, is Individual
>>>>      submission sufficient?
>>>>>
>>>>> I’ll leave that for the chairs to answer.
>>>>
>>>>      Ack.  Thank you so much for your time and attention to this
>>>>      document.
>>>>
>>>>      ScottJ
>>>>
>>>>>
>>>>>> Thanks,
>>>>>> ScottJ
>>>>>>
>>>>>>
>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>>
>>>>>>> Made the IPN description more specific.
>>>>>>>
>>>>>>>
>>>>>>>                                          Wire format
>>>>      encoding shall
>>>>>>> be an unsigned 64-bit integer in network order.
>>>>      Presentation format, for these
>>>>>>> resource records are either a 64 bit unsigned decimal
>>>>      integer, or two 32 bit
>>>>>>> unsigned decimal integers delimited by a period with
>>>>      the most significant 32 bits
>>>>>>> first and least significant 32 bits last.  Values are
>>>>      not to be zero padded.
>>>>>>>
>>>>>>>> On 25 Jun 2024, at 15:22, Scott Johnson
>>>>      <[e-mail]> wrote:
>>>>>>>>
>>>>>>>> Hi Scott,
>>>>>>>>
>>>>>>>> Wire format of 64 bit unsigned integer it is for IPN.
>>>>>>>> Updated draft (03) incorporating all changes posted
>>>>      at:
>>>>>>>>
>>>>      https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>>
>>>>>>>> Let me know if you see anything else, Mark, and
>>>>      thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>> ScottJ
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 24 Jun 2024, [e-mail] wrote:
>>>>>>>>
>>>>>>>>> I've lost lock on the ipn-scheme RFC, but my own
>>>>      assessment is that always sending a single 64-bit unsigned
>>>>      integer would be fine.  The application receiving the
>>>>      resource can figure out whether or not it wants to condense
>>>>      the value by representing it as two 32-bit integers in
>>>>      ASCII with leading zeroes suppressed and a period between
>>>>      the two. Internally it's always going to be a
>>>>      64-bitunsigned integer, from which a 32-bit "allocator"
>>>>      number can be obtained by simply shifting 32 bits to the
>>>>      right; if the result is zero then we're looking at an
>>>>      old-style IPN node number.
>>>>>>>>>
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Scott Johnson <[e-mail]>
>>>>>>>>> Sent: Monday, June 24, 2024 8:26 PM
>>>>>>>>> To: Mark Andrews <[e-mail]>;
>>>>      [e-mail]
>>>>>>>>> Cc: dnsop <[e-mail]>
>>>>>>>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support
>>>>      Bundle Protocol RFC9171
>>>>>>>>>
>>>>>>>>> Hi Mark,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 25 Jun 2024, at 10:32, Scott Johnson
>>>>      <[e-mail]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Mark,
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote:
>>>>>>>>>>>
>>>>>>>>>>>> An obvious correction “LTP--v6” -> “LTP-v6”
>>>>>>>>>>>
>>>>>>>>>>> Aha!  Good eye.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For IPN why isn’t the wire format two network 64
>>>>      bit integers?  That is 16 bytes.  Also 2^64-1 is 20
>>>>      characters so 2 64-bit numbers separated by “." is 41
>>>>      characters.  It’s not clear where then 21 comes from.
>>>>>>>>>>>
>>>>>>>>>>> EID is the basic unit of IPN naming, which is
>>>>      indeed two 64 bit integers separated by a ".". We are
>>>>      seeking to represent only the node-nbr component of an EID,
>>>>      as the service-nbr component is loosely analagous to a UDP
>>>>      or TCP port, for which there is one publicly defined
>>>>      service in the registry, and a collection of space agencies
>>>>      who lay claim to another chunk of them:
>>>>>>>>>>>
>>>>      https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-
>>> num
>>>>>>>>>>> bers As such, there is no gain in including the
>>>>      second 64-bit
>>>>>>>>>>> integer, representing service-nbr in the DNS
>>>>      records, and indeed, a loss of utility on the application
>>>>      level.
>>>>>>>>>>>
>>>>>>>>>>> The node-nbr component is presently, under RFC7116,
>>>>      a 64 bit unsigned integer.  There is a draft from the DTN
>>>>      WG currently making it's way through the IESG which will
>>>>      amend the IPN naming scheme. Perhaps I should add it to
>>>>      normative references?
>>>>>>>>>>>
>>>>      https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
>>>>>>>>>>>
>>>>>>>>>>> In effect it splits the node-nbr component into
>>>>      two-32 bit integers; Allocator Identifier and Node Number
>>>>      in the "Three-Element Scheme-Specific Encoding" of Section
>>>>      6.1.2 over the above.  Section 6.1.1 describes the
>>>>      "Two-Element Scheme-Specific Encoding" method which retains
>>>>      the use of a single 64-bit integer.  Thus, a single 64 bit
>>>>      integer (20 characters) or two 32-bit integers (10
>>>>      characters each) delimited by a "."
>>>>>>>>>>> makes 21 characters maximum.  This preserves
>>>>      forwards compatibility with the proposed amended scheme,
>>>>      and does no harm if the scheme fails to achieve
>>>>      standardization.
>>>>>>>>>>
>>>>>>>>>> Or just 8 bytes on the wire with both possible input
>>>>      formats described.
>>>>>>>>>> Machines using the records will just be converting
>>>>      ASCII values to a
>>>>>>>>>> 64 bit integer.  We may as well transmit it as
>>>>      that.  Input validation
>>>>>>>>>> will need to do the conversion anyway to ensure both
>>>>      fields will fit
>>>>>>>>>> into 32 bits in the “.” separated case and 64 bits
>>>>      in the single value case.
>>>>>>>>>> Length along is not sufficient to prevent undetected
>>>>      overflows.  The
>>>>>>>>>> only thing you need to determine is which format is
>>>>      the initial
>>>>>>>>>> canonical presentation format.  That can be changed
>>>>      with a later
>>>>>>>>>> update if needed.
>>>>>>>>>
>>>>>>>>> I am tagging in Scott Burleigh, co-author of RFC9171
>>>>      on this point for clarification.
>>>>>>>>> Section 4.2.5.1.2 of same indicates:
>>>>>>>>>
>>>>>>>>> "Encoding considerations:
>>>>>>>>> For transmission as a BP endpoint ID, the
>>>>      scheme-specific part of a URI of the ipn scheme SHALL be
>>>>      represented as a CBOR array comprising two items. The first
>>>>      item of this array SHALL be the EID's node number (a number
>>>>      that identifies the node) represented as a CBOR unsigned
>>>>      integer.
>>>>>>>>> The second item of this array SHALL be the EID's
>>>>      service number (a number that identifies some application
>>>>      service) represented as a CBOR unsigned integer. For all
>>>>      other purposes, URIs of the ipn scheme are encoded
>>>>      exclusively in US-ASCII characters."
>>>>>>>>>
>>>>>>>>> Having already established that we are transmitting
>>>>      the node-nbr component only, and not a full EID, I am not
>>>>      sure we are restricted to using only US-ASCII.  ScottB,
>>>>      your opinion?  CBOR might also be an option, but that would
>>>>      place a higher burden upon implementers, I think.  Integer
>>>>      notation for wire format is fine by me.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Limit CLA characters to Letter Digit Hyphen rather
>>>>      than the full ASCII range.
>>>>>>>>>>>
>>>>>>>>>>> It is possible for a node to support multiple CLAs
>>>>      on the same IP
>>>>>>>>>>> address and node number.  Will this change allow
>>>>      multiple, comma
>>>>>>>>>>> delimited values to be expressed in the CLA
>>>>      record?  If so, can you
>>>>>>>>>>> point me to an example so I can get the verbiage of
>>>>      the draft right?
>>>>>>>>>>> If not, what do you recommend (in addition to my
>>>>      defining that in the
>>>>>>>>>>> draft)?  I like the idea of limiting the usable
>>>>      characters.
>>>>>>>>>>
>>>>>>>>>> Personally I would just use a TXT record wire format
>>>>      with the
>>>>>>>>>> additional constraint that the values are restricted
>>>>      to Letter, Digits
>>>>>>>>>> and interior Hyphens.  The input format matches the
>>>>      TXT record with
>>>>>>>>>> the above character value constraints.  The
>>>>      canonical presentation
>>>>>>>>>> form is space separated, unquoted, unescaped ASCII.
>>>>      This allow for
>>>>>>>>>> long records to be split over multiple lines.
>>>>      Descriptive comments in the zone file.
>>>>>>>>>> This take one extra octet over using comma separated
>>>>      values.
>>>>>>>>>
>>>>>>>>> Sold to the man from ISC :)  This part works great;
>>>>      thank you!  Updated draft pushed to datatracker at
>>>>      https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> e.g.
>>>>>>>>>>
>>>>>>>>>> example inputs
>>>>>>>>>>
>>>>>>>>>> @ CLA ( TCP-V4 ; TCP over IPv4
>>>>>>>>>>   TCP-V6 ) ; TCP over IPv6
>>>>>>>>>>
>>>>>>>>>> @ CLA “TCP-V4” TCP-V6
>>>>>>>>>>
>>>>>>>>>> Wire
>>>>>>>>>>
>>>>>>>>>> 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’
>>>>      ‘6’
>>>>>>>>>>
>>>>>>>>>> Canonical presentation
>>>>>>>>>>
>>>>>>>>>> @ CLA TCP-V4 TCP-V6
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mark
>>>>>>>>>>>>
>>>>>>>>>>>>> On 25 Jun 2024, at 08:19, Scott Johnson
>>>>      <[e-mail]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> After reading the recent discussion about WALLET,
>>>>      I am hesitant to jump into the fray here, but this plainly
>>>>      is the correct group to help me get my logic and syntax
>>>>      right, so here goes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I submitted requests to IANA for IPN and CLA
>>>>      RRTYPEs, these representing the missing datasets necessary
>>>>      to make a BP overlay network connection from data found by
>>>>      DNS queries.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For those not familiar, BP is a store and forward
>>>>      mechanism generally used in high latency situations where
>>>>      there does not exist constant end-to-end connectivity.  It
>>>>      was designed for deep space networking, however has network
>>>>      segments and application uses which overlay the terrestrial
>>>>      Internet.  There will arise similar use cases on the Moon
>>>>      (in the reasonably near future) and Mars whereby low
>>>>      latency, constant connectivity exists, thereby making use
>>>>      of DNS in these situations viable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My Expert Reviewer asked for an i-d, to clarify
>>>>      the requests, and that said i-d be sent to this list for
>>>>      review.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please find the approptiate draft here:
>>>>>>>>>>>>>
>>>>      https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Relevant IANA requests:
>>>>>>>>>>>>>
>>>>      https://tools.iana.org/public-view/viewticket/1364843
>>>>>>>>>>>>>
>>>>      https://tools.iana.org/public-view/viewticket/1364844
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have the BP community also reviewing this, but
>>>>      they are generally in agreement as to use.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Scott M. Johnson
>>>>>>>>>>>>> Spacely Packets, LLC
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> DNSOP mailing list -- [e-mail] To
>>>>      unsubscribe send an email
>>>>>>>>>>>>> to [e-mail]
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Mark Andrews, ISC
>>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>>>>>>> PHONE: [phone]              INTERNET:
>>>>      [e-mail]
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> DNSOP mailing list -- [e-mail] To
>>>>      unsubscribe send an email to
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mark Andrews, ISC
>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>>>>> PHONE: [phone]              INTERNET:
>>>>      [e-mail]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> DNSOP mailing list -- [e-mail]
>>>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mark Andrews, ISC
>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>>> PHONE: [phone]              INTERNET:
>>>>      [e-mail]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> DNSOP mailing list -- [e-mail]
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>>
>>>>> --
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: [phone]              INTERNET:
>>>>      [e-mail]
>>>>>
>>>>> _______________________________________________
>>>>> DNSOP mailing list -- [e-mail]
>>>>> To unsubscribe send an email to
>>>>      dnsop-
>>> [e-mail]_______________________________________________
>>>>      DNSOP mailing list -- [e-mail]
>>>>      To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>
>> _______________________________________________
>> DNSOP mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> dtn mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]