Scott, I see two major issues with your current proposal. The first is that a CLA is more than just a specific transport, it is also a profile and likely a whole protocol above that transport. For example, there are multiple versions of "TCPCL" which behave differently and have different capabilities. So just saying "I support TCP-over-IPv6" falls short of indicating what a node is actually capable of and whether or not I can expect to successfully make contact and transfer bundles with that peer.
The second is that I think it's actually more appropriate to use DNS Service
Discovery (DNS-SD) as a mechanism to register CLAs over DNS. I have drafted a
profile of this in [1] which does not even require any new code point
allocations; the existing DNS-SD and service name registries [2] already have
what is needed for a node to register listening CLAs as services. The DNS-SD
also works for both unicast and multicast DNS. In the specific profile of [1]
there is a requirement that only BP routers register themselves, but that is
more of a convenience than a strict necessity.
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 <[email protected]>
> Sent: Tuesday, June 25, 2024 5:57 AM
> To: Erik Kline <[email protected]>
> Cc: dnsop <[email protected]>; [email protected]; [email protected]
> Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
> Protocol RFC9171
>
> APL external email warning: Verify sender [email protected] 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 <[email protected]>
> > wrote:
> > Hi Mark,
> >
> > On Tue, 25 Jun 2024, Mark Andrews wrote:
> >
> > >
> > >
> > >> On 25 Jun 2024, at 16:36, Scott Johnson
> > <[email protected]> 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
> > <[email protected]> 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, [email protected] 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 <[email protected]>
> > >>>>> Sent: Monday, June 24, 2024 8:26 PM
> > >>>>> To: Mark Andrews <[email protected]>;
> > [email protected]
> > >>>>> Cc: dnsop <[email protected]>
> > >>>>> 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
> > <[email protected]> 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
> > <[email protected]> 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 -- [email protected] To
> > unsubscribe send an email
> > >>>>>>>>> to [email protected]
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Mark Andrews, ISC
> > >>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > >>>>>>>> PHONE: +61 2 9871 4742 INTERNET:
> > [email protected]
> > >>>>>>>>
> > >>>>>>>> _______________________________________________
> > >>>>>>>> DNSOP mailing list -- [email protected] To
> > unsubscribe send an email to
> > >>>>>>>> [email protected]
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Mark Andrews, ISC
> > >>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > >>>>>> PHONE: +61 2 9871 4742 INTERNET:
> > [email protected]
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> DNSOP mailing list -- [email protected]
> > >>>>> To unsubscribe send an email to [email protected]
> > >>>
> > >>>
> > >>> --
> > >>> Mark Andrews, ISC
> > >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > >>> PHONE: +61 2 9871 4742 INTERNET:
> > [email protected]
> > >>>
> > >>> _______________________________________________
> > >>> DNSOP mailing list -- [email protected]
> > >>> To unsubscribe send an email to [email protected]
> > >
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET:
> > [email protected]
> > >
> > > _______________________________________________
> > > DNSOP mailing list -- [email protected]
> > > To unsubscribe send an email to
> > dnsop-
> [email protected]_______________________________________________
> > DNSOP mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> >
> >
> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
