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 <sc...@spacelypackets.com>
Sent: Tuesday, June 25, 2024 5:57 AM
To: Erik Kline <ek.i...@gmail.com>
Cc: dnsop <dnsop@ietf.org>; sburleig...@gmail.com; d...@ietf.org
Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171

APL external email warning: Verify sender forwardingalgori...@ietf.org 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 <sc...@spacelypackets.com>
wrote:
     Hi Mark,

     On Tue, 25 Jun 2024, Mark Andrews wrote:



On 25 Jun 2024, at 16:36, Scott Johnson
     <sc...@spacelypackets.com> 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
     <sc...@spacelypackets.com> 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, sburleig...@gmail.com 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 <sc...@spacelypackets.com>
Sent: Monday, June 24, 2024 8:26 PM
To: Mark Andrews <ma...@isc.org>;
     sburleig...@gmail.com
Cc: dnsop <dnsop@ietf.org>
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
     <sc...@spacelypackets.com> 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
     <sc...@spacelypackets.com> 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 -- dnsop@ietf.org To
     unsubscribe send an email
to dnsop-le...@ietf.org

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET:
     ma...@isc.org

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org To
     unsubscribe send an email to
dnsop-le...@ietf.org


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET:
     ma...@isc.org



_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET:
     ma...@isc.org

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET:
     ma...@isc.org

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to
     dnsop-
leave@ietf.org_______________________________________________
     DNSOP mailing list -- dnsop@ietf.org
     To unsubscribe send an email to dnsop-le...@ietf.org



_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

_______________________________________________
dtn mailing list -- d...@ietf.org
To unsubscribe send an email to dtn-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to