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

Scott Johnson <scott@spacelypackets.com> Sat, 29 June 2024 11:09 UTC

Return-Path: <scott@spacelypackets.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B030DC151992; Sat, 29 Jun 2024 04:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL55I4GTeDT5; Sat, 29 Jun 2024 04:09:46 -0700 (PDT)
Received: from www.spacelypackets.com (www.spacelypackets.com [IPv6:2602:fdf2:bee:feed::ee]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DBBC151989; Sat, 29 Jun 2024 04:09:43 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1sNVwr-0000c6-1g; Sat, 29 Jun 2024 11:08:53 +0000
Date: Sat, 29 Jun 2024 11:08:53 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980273739B7C@tss-server1.home.tropicalstormsoftware.com>
Message-ID: <6b854319-3cd9-4282-7855-6237902b0427@spacelypackets.com>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com> <0910E1D8-C678-498C-BAB5-AC3AA4C75750@isc.org> <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org> <6ff67491-30cf-cdc0-5e19-c1122465386c@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F9802737395E2@tss-server1.home.tropicalstormsoftware.com> <8b864323-a43d-3861-17e6-9f422b2d4592@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739B7C@tss-server1.home.tropicalstormsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-ID-Hash: LHSIOPZLOPHZRTVX2VKZHD7Z3IGK6F6N
X-Message-ID-Hash: LHSIOPZLOPHZRTVX2VKZHD7Z3IGK6F6N
X-MailFrom: scott@spacelypackets.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QRiicpsbbzMaJc_-oW-9UlOBWi0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Rick,

On Fri, 28 Jun 2024, Rick Taylor wrote:

> 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.

It has it's place in terrestrial BP network segments, to be sure.

>
> 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.

If we can bitshift two 32 bit integers into a 64 bit int, we can probably 
bitshift two 16s and a 32 into a 64, eh?  Or two 64s into a 128, when that 
is commonplace?

>
> 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.

Using SRV and TXT might be so fractionally easier than requesting RRTYPEs 
that it could potentially be measurable, yes.  On the other hand, that 
course might be harder; it would require a standards action.  It might 
also be harder in other ways, such as for network operators deploying 
these records in their zones.

>
> 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.

Hit me with something better, while preserving the three elements to be 
encoded.

> 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 described the problem with not disambiguating IP version in my response 
to Brian.  There are lots of clever things one can do while engineering 
networks with IPv4 and IPv6 as discrete logical channels to the BPA, 
including some capabilities enabled on the IP networking side.

> 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.

I agree normative references need to be added to the table.


>
> 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?

Yep, but you need to know which one to use.  As I said to Brian, the BPA 
may be be speaking only IPv4, or only IPv6, notwithstanding how the host 
itself is addressed and represented by A or AAAA records.  Two different 
BPAs may exist, one speaking IPv4 and the other speaking IPv6.  One BPA 
may speak both IPv4 and IPv6 but using different node numbers in their 
EIDs.  It is necessary to disambiguate how the CLA interfaces.


> 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.

This was to address Brian's point that BPv6 and BPv7 CLAs don't always 
interoperate correctly.

>
> 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.

IIRC, this is in use in the wild.  That is why I included it.

>
> 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/)

I refreshed that draft when I completed updating the implementation to be 
compliant with it.
https://datatracker.ietf.org/doc/draft-johnson-dtn-ipnd/

> that 
> describes a peer discovery mechanism, not a CLA.

Agreed, but it is a mechanism that allows fully automated distribution of 
correct CLA information, as well as EID information.  It also can be 
configured to listen on only IPv4 or IPv6, or both for beacons.  Let me 
ask you this:  are you aware of any other extant mechanism to enable 
opportunistic BP connections?  While it has it's flaws, as Brian pointed 
out when I re-introduced the draft, it can be 'Adapt'ed to provide a 
requested capability while attending to those flaws, or 'Adopt'ed to do 
the job as is, with the flaws being mitigated externally by other means.

> Perhaps I have missed 
> a reference (see point a), but I (personally) think that an RRTYPE 
> called "CLA" should only contain CLAs.

I look at it like assigning an IP address to a NIC with DHCP vs manually 
assigning it.  If I say:

iface eth0 inet dhcp

then I don't need to add the address, netmask, gateway, etc declarations 
in my 'interfaces' file.  This is the same concept, applied to BP 
connection information over IP networks.

>
> 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.

It is not.  Are there CLAs which operate over IP which are not represented 
here, and there is running code for?

> Alternatively perhaps restrict the 
> registered values to those backed by publicly accessible current 
> specifications, and add a "Private Use" range?

This is not an unreasonable way to address the problem, listing all 
combinations of (letter, number, interior hyphen) as within private use, 
but for those ennumerated in the list.

>
> 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.


Thanks,
Scott


>
> Cheers,
> Rick
>
>> -----Original Message-----
>> From: Scott Johnson [mailto:scott@spacelypackets.com]
>> Sent: 28 June 2024 10:12
>> To: Rick Taylor
>> Cc: Erik Kline; dnsop; sburleig.sb@gmail.com; dtn@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-leave@ietf.org
>