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

[Scott Johnson]

Hi Brian,

On Fri, 28 Jun 2024, Sipos, Brian J. wrote:
Scott et al, After mulling it over for a little bit, I think your 
CLA-visibility need might be met by using existing per-host SRV records. 
For what it's worth, I had the same logical issue with how the original 
IPND drafts parameterize and expose CLAs so my concern isn't specific to 
what you have drafted.

I actually considered using the numerical encoding (or a variant thereof) 
as the actual RDATA value for the CLA RRTYPE.  I kind of liked that simple 
numerical encoding, but perhaps that is because when I was making the IPND 
implementation draft compliant, that part already worked pretty well. I 
had to tussle with the SDNV part of it for a bit, but it worked out.

I specified ASCII (letters, numbers, hyphens only thanks to Mark) because 
for the purposes of the draft, that was sufficient, and left plenty of 
latitude to amend in the future if that is desired.  I am not married to 
the present notation, but I do need all three datatypes encoded if anyone 
wants to suggest a better option for CLA RRTYPE RDATA structure.


The question being answered by the "Zero-Configuration CLA Discovery" 
mechanism is really "where are the BP routers for my domain?" which I 
think is different than the question you are asking

correct

which, I believe, is 
"given a host

just one, per record.

or set of hosts in a DNS domain what, if any, CLAs are 
listening on the host?".

Bingo.

In fact, the zero-configuration section in the 
other draft might be better titled "Zero-Configuration Router CLA 
Discovery" to distinguish its purpose.

Sort of like Router Advertisement for IPv6?


Going back to what I think is your goal and question-to-be-answered, 
using a SRV record on a specific host name rather than either SRV or 
DNS-SD on an entire domain could get the information that you want in a 
way which is not so ambiguous as the IPND code points. Applying a SRV 
record to a host name rather than domain name is slightly off-label use, 
but I think it's still technically allowed by [RFC2782]. The point of 
this use is that the service applies to just the host, and they are not 
interchangeable between hosts in the same domain.

While this method certainly works, it is also much heavier; more 
bytes on the wire, and more opportunities for fat fingered administration 
at the end of a double shift breaking something critical.


For the example zone below, there are three BP nodes running on host 
names "host-a" "host-b" and "host-c" and a standard query on 
"host-b.example.com." will obtain both the host's available addresses

I only want to obtain the respective A or AAAA record for the host, 
depending on what version of IP the CLA is speaking.  This is because not 
all hosts will be dual stacked; some may be v4 or v6 only.  Those that are 
dual stacked may be listening for BP on only IPv4, or only IPv6, or both. 
They could be listening on both with a single BPA, or using multiple 
instances of the BPA, in which case they are effectively two different 
nodes.  I have nodes which listed on different node numbers via IPv4 vs 
IPv6 with a single BPA.  When I added IPv6 support to IONe, I designed in 
this granularity of discrete logical channels, as opposed to the usual 
dual stack approach. As I continue building more components of a larger 
vision, I like to use the features I already placed.

So, what happens when a node looks up a v4 address and tries to connect to 
a node that only has v6 CLAs running?

as 
well as the SRV records indicating what CLs are listening on which 
ports. You could do something similar with a custom RRTYPE, but in this 
case the SRV type will be directly usable with existing tooling and 
should not be confusing to anyone observing the domain contents.

I am actively doing this with a custom RRTYPE, that being the point of my 
draft.  If it is confusing to observers, I would call that a feature, not 
a bug.


As Rick mentioned recently, it is better to not use any unregistered CL types
in your profiling document, but [RFC2782] itself allows for private use
service names, as it defines the service part as "The symbolic name of the
desired service, as defined in Assigned Numbers [STD 2] or locally." So
specific private networks could use whatever agreed upon service names are
needed as long as they don't collide with any IANA-registered names.

This is a valid point, however there is running code in the wild for all 
of those CLAs.  My barrier of entry for that list was "will anyone be able 
to use this on running networks."  I concur that I need to add links to 
normative references to the table, but I would like to be as liberal as 
possible about what is allowed on that list.  References to expired drafts 
would be sufficient for inclusion, if there is running code, IMHO, despite 
said draft not having been able to run the gauntlet to RFC due to any of 
variety of factors not related to it's merit (author graduated, author 
job role changed, author defunded by congress, etc).

Thanks,
ScottJ




$ORIGIN example.com.
(
...
host-a  86400  IN  A  <IPv4>
_dtn-bundle._tcp.host-a  86400  IN  SRV  0  0  4556  host-a.example.com.
host-b  86400  IN  AAAA  <IPv6>
_dtn-bundle._tcp.host-b  86400  IN  SRV  0  0  4556  host-b.example.com.
_ltp-deepspace._udp.host-b  86400  IN  SRV  0  0  1113  host-b.example.com.
host-c  86400  IN  A  <IPv4>
host-c  86400  IN  AAAA  <IPv6>
_dtn-bundle._udp.host-c  86400  IN  SRV  0  0  4556  host-c.example.com.
)

[RFC2782] https://www.rfc-editor.org/rfc/rfc2782.html

-----Original Message-----
From: Rick Taylor <r...@tropicalstormsoftware.com>
Sent: Friday, June 28, 2024 8:16 AM
To: Scott Johnson <sc...@spacelypackets.com>
Cc: Erik Kline <ek.i...@gmail.com>; dnsop <dnsop@ietf.org>;
sburleig...@gmail.com; d...@ietf.org
Subject: [EXT] [dtn] Re: [DNSOP] RE: 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 Scott,

I think we are talking at cross-purposes.

I have no criticism of the valiant work you have done, and the circuitous
route
you have been forced to follow to get to this point.  The IETF needs more
people
with your 'can do' attitude, it will help all of us meet our endlessly
slipping WG
milestones.

The DTN Working Group, of which I am a member, was asked their opinion by
the DNSOPS folks and the DTN-WG AD to comment on your proposal, which I
have done.  My comments were never intended to be perceived as an attack on
you or your proposal.   The decision on registration of a RRTYPEs solely
rests
with the IANA and the Designed Experts of the registry.

I fully support the use of DNS with Bundle Protocol, and have been a strong
advocate for doing some kind of EID to CLA lookup, so I am extremely
grateful
you have put all this work in.

With that in mind, the summary of my 8 comments on this proposal are:

1.  I (personally) think a CBOR encoding would be more future proof, but it
is
your decision on whether that is important to you.

2.  In order to resolve a DNS name to an ipn FQNN, using DNS lookup, I
(personally) think that using a combination of SRV and TXT records will be
easier
to integrate into the current DNS ecosystem.  As Paul Vixie pointed out,
that
ecosystem involves more than just the nameservers.  But, again, it's your
decision whether that is an issue for you.

3.  I find the CLA RRTYPE enumerated values of the form [CLA protocol]-[IP
Version]-[BP version] confusing, but again, that might just be me.  TCPCL is
the
name of the convergence layer protocol used in the specifications, v4 is
defined
in RFC9174, v3 defined in RFC7242, both will operate over TCP/IPv4 and
TCP/IPv6.   I would prefer to see a definition of TCP-v4-v6, TCP-v4-v7,
TCP-v6-v7
pointing to the correct combination of versions, or better yet something
along
the lines of just TCPCLv4, TCPCLv3.   The same applies to LTP and UDP.  If I
was
to implement this, I would expect a reference to a protocol specification
that
can reasonably describe what an CLA implementation resulting from a lookup
is
declared to support.

4.  Why is the IP version included?  Perhaps I am missing a hidden
complexity of
DNS here, but as a user, given a DNS name, can't I just lookup the RRTYPE
for
the CLA, and then use A or AAAA records to get either/both IPv4 and IPv6
addresses via the same DNS name?  It seems like unnecessary doubling of
values
to me.

5.  Why is the BP version included? The relevant CLA specifications should
(maybe all do) include applicability statements for the various Bundle
Protocol
versions.  If you need a DNS based lookup mechanism to determine the version
of BP in use at a host, perhaps a third RRTYPE 'BPVER' would be preferable?
In
many cases the choices of BP version and CLA protocol to use are orthogonal.

6.  I assume STCP refers to the expired Simple TCP Convergence-Layer
Protocol
(https://datatracker.ietf.org/doc/draft-burleigh-dtn-stcp/).  This protocol
was
never adopted by the DTN WG, the draft expired in 2019, and the
functionality
superseded by TCPCLv4.  I would not recommend referencing this document or
even the protocol.

7.  I find the inclusion if IPND inconsistent.  The only IETF reference to
IPND that
I could find is an IRTF draft that expired in 2016
(https://datatracker.ietf.org/doc/draft-irtf-dtnrg-ipnd/), that describes a
peer
discovery mechanism, not a CLA.  Perhaps I have missed a reference (see
point
a), but I (personally) think that an RRTYPE called "CLA" should only contain
CLAs.

8.  I understand that ION implements all the CLA RRTYPEs you have described
above, which is great, but if this registration is specifically aimed at
declaring
implementation specific functionality, the document should state it.
Alternatively perhaps restrict the registered values to those backed by
publicly
accessible current specifications, and add a "Private Use" range?

Please feel free to ignore any or all of my comments if you disagree, they
are
meant to be constructive, not some kind of dictat.

Cheers,
Rick

-----Original Message-----
From: Scott Johnson [mailto:sc...@spacelypackets.com]
Sent: 28 June 2024 10:12
To: Rick Taylor
Cc: Erik Kline; dnsop; sburleig...@gmail.com; d...@ietf.org
Subject: Re: [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to
support Bundle Protocol RFC9171

Hi Rick,

As I have previously stated, I personally have lodged no objection to
using CBOR encoding of (node-nbr) in this case, and actually mentioned
the option myself.  Here is the situation as I see it:

I have requested the creation in the IANA database of the IPN and CLA
RRTYPEs, by the means detailed in RFC6895, section 3.1.1; to whit,
completed (twice, one for each) the form found in Appendix A. of same.
My requests meet the criteria of part 2 of 3.1.1.

I ran afound of section 3.1.2, point 1, as the Expert Reviewer
explained that I needed to designate wire and presentation formats for
the requested records, in Individual Informational internet-draft format.

I produced that document, and, as suggested by Expert Reviewer, sent
it to DNSOP for review.  There, I received guidance on verbiage and
optimal choice of formats from DNS expert Mark Andrews.  I also
consulted Scott Burleigh, first named author of RFC9171, for any
particular BP related concerns.  With the help of, and achieving
concensus with these two learned individuals who possess significant
specialized knowledge of the two systems we are integrating in the
above described standardized process, we arrived at a viable document in
several hours.

Upon request of Transport AD, I forwarded to DTN.  Of the productive
responses received, Brian Sipos pointed out an interoperability
problem with the notation I wove from whole cloth (based on the
notation used in
IPND) to describe CLAs, and you requested information concerning
motivations of the document.  Time being of the essense, I
incorporated changes to address the point Brian made and added a
section to text describing my motivation.  I did so in short order, as
I did previously with the consultations on DNSOP.

You raised technical challenges to the proposed 64-bit integer wire
encoding for IPN in this use case, citing RFC9171, and your own draft.
Section 4.2.5.1.2 clearly defines the rules for encoding of EIDs.
Only one component of EID is to be encoded in the RRTYPE, and hence,
not an EID.  Further, 64-bit integer is the preferred encoding of the
DNS experts, and Scott Burleigh has confirmed that this proposal
conforms to the encoding defined in your draft; an assertation which
has not been refuted.  It has also been confirmed that there is no
conflict between the registration of these RRTYPEs in the described
formats and the content of your draft.

This particular encoding is not for use inside bundles or by BPAs;
indeed, it will only appear (please correct me if i am wrong, DNSOP
participants) internally inside nameservers and resolvers and on the wire
between them.
Thus, these technical challenges seem to have been addressed.

An alternate proposal was put forward in theory, fulfilled in part by
an expired draft by Brian Sipos, who has indicated that he does not
have time to work on that solution at present.  I believe him; I
imagine his workplace is exceedingly busy of late.  I know mine is.

Having arrived at loose consensus with experts from both disciplines
involved, and lacking a good reason to further revise the draft which
is now before the Expert Reviewer for a decision as to the creation of
the RRTYPEs, I think the best course of action is to let the Expert
Reviewer do their job and approve or (hopefully not) deny the RRTYPE
reservations.
The IANA registry will likely reference my draft if approved, and I
will likely be requesting at least one more RRTYPE to hold BPSEC data.

If DTN WG wishes to take up this special purpose individual
informational draft instead of other pressing business it is chartered
for, it is free to do so.  It is in no way necessary to do so to
perfect my RRTYPE request procedure, and seems a waste of time to me.
If you want something for the WG to take up, I will be producing
another Informational draft soon which you will surely find
interesting concerning discrete DNS networks on different planetary
bodies interoperating by means of transiting IP request metadata
across the BP deep space network.  That, IMHO, is worthy of asking the
attention of the group here assembled.

Please understand; we are operating in an Adopt, Adapt, Author order
of preference when it comes to solving real world problems being faced
right now.  In this case, 'Adopt'ing new DNS RRTYPEs to distribute BP
information to IP speaking BP nodes fits the bill.  It "just works" in
a way that those who will use it will already understand, and is easy
to implement all the way around.  It may not be the best solution
possible, but it was the best one available.

Thanks,
Scott



On Thu, 27 Jun 2024, Rick Taylor wrote:

Hi Scott,

<chair hat on>

I absolutely sympathise with your need to "grab an RRTYPE and make
progress", but there is a process choice to be made here:

* Do DNSOPS want the RRTYPE registrations to integrate with the
wider work
of the DTN working group?  In which case discussion like this must
continue, and the document should be adopted by the WG.
* Or is everyone happy to register the RRTYPEs as "ScottJ and
colleagues
need some unique RRTYPEs for the solution they're working on - no
alignment with the wider work of the DTN WG implied"?  I would propose
calling the RRTYPE NODEID not IPN to make this clear, and not have the
reference specification be an IETF document.

I'm genuinely not trying to scupper this work.  I'm actually happy
with either
approach, I'm just trying to ensure moving fast doesn't accidently set
perceived standards that then consume WG cycles in the future to align
with current work.

But before we consume too much more of all of our time, a decision
needs to
be made on the approach, and I think Erik (DTN AD), the DNSOPS
Designated Experts/Chairs and Scott need to discuss their preferred
options.

We have "Naming and addressing" as part of the DTN WG charter, so
this
work could be adopted if the WG is willing, but that may not suit
Scott's timeline.

Cheers,
Rick
_______________________________________________
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