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-numbers
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.
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.
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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
