-----Original Message-----
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 26 June 2024 21:32
To: Rick Taylor
Cc: Erik Kline; dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
Hi Rick,
On Wed, 26 Jun 2024, Rick Taylor wrote:
Hi Scott,
Thanks for the updated doc. I've been thinking through what I
understand is your use-case, and I wonder whether new RRTYPEs is really
the right way to go. As I see it, the less one has to update the DNS
infrastructure of the Internet the better,
I disagree with this assessment. RFC 6895 clearly lays out a policy for
the allocation of RRTYPEs that encourages the creation of same. I have
followed that policy to the letter, and produced all the necessary
documentation, including this draft which was forwarded to this WG as a
courtesy to the Transport AD. This is the cleanest and shortest path
forward to achieve the functionality I am looking for. Recently, a WALLET
RRTYPE was created to store crytocurrency wallet addresses. It did not
require an RFC or even an i-d, much less wg adoption or discussion.
The topic of this draft is wire and presentation encoding of two RRTYPEs,
and as such, discussion should be limited to that. It has already been
established that nothing in my RRTYPE requests nor draft will interfere
with any present DTN related drafts or standards. If you don't like my
proposal, simply do not use it in your networks, but please do not try to
derail what I have already set in motion outside the perview of this WG if
it does not meet _your_ needs, as it does meet mine. Again, one may
assign IPv6 addresses by means of DHCPv6, SLAAC, or manual assignment.
This is no different.
Any such 'update to the DNS infrastructure' would happen by DNS
implementers, as part of the normal update and release schedule. It is
notable that Mark Andrews from ISC, the organization responsible for
maintaining BIND, contributed to the technical verbiage of this draft
describing wire and presentation types for the RRTYPEs which have been
requested. I followed his recommendations as to encoding, which
presumably will make implementation work easier, as well as saving a few
bytes over textual encoding, which is only required for representations
of EID per RFC9171.
so would this alternative
mechanism work for you?:
No. I do feel that reverse DNS records for BP identifiers is a
useful pursuit, but is not critical to my application, and out of scope
as relates to the draft being discussed.
The IETF creates a subdomain of `ipn.arpa.` under which all ipn FQNNs in
text format (reversed) may be registered, much like public IP addresses
under `inet.arpa.`, e.g. ipn:1.2.x would be registered as
`2.1.ipn.arpa.`. This would allow any DNS capable host to resolve an
ipn FQNN to DNS name.
This will require a time consuming standards action from a work group
which, with all due respect, is well behind on milestones already. It will
simply take too long. It has already taken more man hours defending the
creation of these RRTYPEs (which is not part of the defined process) than
it took to perfect their additional documentation with DNSOP. The policy
governing RRTYPEs is deliberately liberal, to encourage fast innovation,
and this is, IMHO, the best way to expeditiously move forward, which is
what is required at this time.
Under this DNS name, one could have one or more regular SRV records of
the form "_service._protocol.name", e.g.
"_tcpcl._tcp.spacelypackets.com." that would allow an entity to discover
that TCPCL is available, and of course "spacelypackets.com." (more
correctly the target of the SRV record) can be resolved quite normally
via an A or AAAA record to your BPA's IP address.
I will note that I was personally admonished by the now former Transport
AD for using "real company names" when making an example on the DTN
mailing list.
Of course one can sprinkle PTR and CNAME records throughout to add
indirection and delegate authority, perhaps to ipn Allocators. Also the
"ipn.arpa." registration can be skipped altogether, and instead DNS-SD
or DHCP/RA options can be used to discover the corresponding SRV record
entries without requiring global registration.
Sorry. I prefer dedicated records, which is what I have requested from
IANA. Please feel free to develop whatever solution best meets your
needs.
This has the following advantages as I see it:
1. An ipn EID is now mapped to a Name that can be asserted using regular
DNS-name based certificate services.
My RRTYPE requests and subsequent draft do not address EIDs, and hence,
are seeking to achieve something different than your proposal.
2. Existing DNS software does not need to be updated. I can configure my
ancient BSD box with BIND to do this now.
If you keep your copy of BIND updated regularly, then you will notice no
difference when the new RRTYPEs are supported. If you don't keep it
updated, you do so at your own risk, as security fixes are pushed as
necessary with regular updates.
3. We don't need yet another binary encoding of ipn EIDs, it's just text.
There is no "new" binary encoding of EIDs; indeed, EID's are not treated
in my draft. Textual encoding for the (node-nbr) component was my
original plan, however, but it was pointed out that this would be
converted to a 64-bit inside the nameserver anyway, so we might as well
transmit it as such, and save 13 bytes on the wire.
However, I may have misunderstood your use-case, so this might not be
viable alternative.
Thoughts?
Per 'Note Well', I do not wish to further discuss my use case at this
time, but suffice it to say that those resources which I have requested to
be created by the proper procedure and in the proper venue are sufficient
to meet the needs of my use case, while proffered alternatives do not.
I feel that alternative efforts are worthwhile, and encourage their
further development and standardization. I see no conflict between any
proposed methods and those requests which I have made. Provision was
made
to support the draft you currently have under IESG review, such that, in
the event that it becomes RFC, no change will have to be made to the
RRTYPE. I see no legitimate reason, nor standing, per the agreed upon
procedure, to oppose the creation of these RRTYPEs.
ScottJ
Rick
P.S. I'm sure Brian Sipos has a more flexible solution using his EID Patterns
under the `ipn.arpa` TLD, but I don't want to muddy the waters by trying to
introduce it now
-----Original Message-----
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 26 June 2024 06:19
To: Rick Taylor
Cc: Erik Kline; dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
Hi All,
A new version of this draft (06) has been posted here:
https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/
This includes edits from Scott Burleigh, as well as edits based on the
feedback from Brian and Rick, but for the references to specs for existing
CLAs in use in the wild.
Happy to hear any further comments.
Thanks,
ScottJ
On Wed, 26 Jun 2024, Scott Johnson wrote:
Hi Rick,
On Tue, 25 Jun 2024, Rick Taylor wrote:
Hi Scott,
Thanks for publishing this doc, it looks really interesting.
You are welcome. Thanks for taking the time to review.
One thing I am unclear about is what is the purpose of having a DNS
record mapping a dtn or ipn Node ID to an IP address.
That is not exactly what is happening. I am mapping an IPN node number
to
domain name. That domain name may or may not have IPv4 or IPv6
addresses also mapped to it, but that is irrelevant.
Is it so that 'routing' lookups can be performed at BPAs when a next
hop for a particular EID is not known locally?
That is an interesting concept perhaps worth exploring further, but no,
that was not my intention.
It would be great to have the rationale described in the document.
Sure, but the whole thing might be out of scope for DTN WG; it addresses
application layer (outside the BPA) considerations.
Consider that what BP excels at in robustness and extensibility, it
lacks in standardized applications. One barrier to BP native
application authoring which has been identified is lack of an API. This
is being explored in multiple directions, including userspace and kernel
API implementations. It is highly useful, when operating over the
underlying Internet, for an application to be able to collect all
necessary connectivity data via DNS query.
A web browser, for example, does a DNS lookup before making a http
request. At a minimum, this means Node Number and available CLA(s) in
addition to IP address when making a BP connection. If BPSEC is
deployed, additional RRTYPES, such as a security context identifier
(CTX?) and public key (BSEC?) records might be appropriate to negotiate
such a connection, but they are out of scope for this draft.
If the application then transmits that information via an API to the
BPA, the BPA can take action in the contact graph to perfect the
connection. This draft, and the RRTYPEs it describes, enable a preferred
component of an API structure to encourage application development.
I'm also a wondering if there out to be references to the relevant
specifications for the CLA's in the RRTPE values: e.g. BSSP-v6 and
STCP-v4?
Sure, that would be great. I am not aware of specification documents
for many of these, and for IPND (which I know is not a CLA, but provides
a useful discrete automated Node Number and CLA signaling system)
there
is only the expired draft I posted last year. What I do have for all of
them is running code. I will dig about a bit for (perhaps archival)
spec documents on the other listed CLAs.
Thanks,
Scott
Cheers,
Rick
-----Original Message-----
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 25 June 2024 10:57
To: Erik Kline
Cc: dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle
Protocol RFC9171
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
_______________________________________________
dtn mailing list -- d...@ietf.org
To unsubscribe send an email to dtn-le...@ietf.org
