> Le 26 juin 2024 à 20:11, Rick Taylor <r...@tropicalstormsoftware.com> a écrit > : > > 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, so would this alternative mechanism work for you?: > > 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. > > 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 like that better. No new RR. But I think DNS-SD is also very useful. Marc. > > 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. > > 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. > 2. Existing DNS software does not need to be updated. I can configure my > ancient BSD box with BIND to do this now. > 3. We don't need yet another binary encoding of ipn EIDs, it's just text. > > However, I may have misunderstood your use-case, so this might not be viable > alternative. > > Thoughts? > > 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 >>>>>> >>>>>> >>>>>> >>> > _______________________________________________ > 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
