Re: [Int-area] draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop"
From: Int-area on behalf of Warren Kumari Sent: 22 January 2024 14:39 Hi there all, I discovered that I'd somehow misnamed a draft that Juliusz Chroboczek , Toke Høiland-Jørgensen, and myself had written — somehow I'd managed to name it draft-chroboczek-int-v4-via-v6, instead of draft-chroboczek-intarea-v4-via-v6. Anyway, it is targeted at intarea, and so I renamed and submitted it, so that it will now actually show up in the IntArea list of documents… The document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. This isn't yet another "let's rewrite part of the header and override some bits", nor some new protocol / tunneling thing. It simply notes that routers only need to determine the outgoing interface (and usually MAC address) for a packet, and so it's perfectly acceptable for the next-hop for e.g 192.0.2.0/24<http://192.0.2.0/24> to be e.g 2001:db8::2342. The router don't care… While this may be initially surprising to many people, it's actually nothing "special", nor really groundbreaking - it's just how IP routing works. However, because it is surprising, it is not getting widely used — and that means that many interfaces need IPv4 addresses where they otherwise would not. In fact, this functionality is already supported in (at least!): Arista EOS (since EOS-4.30.1) The Babel protocol Linux (since kernel version 5.2) Mikrotik RouterOS (since before 7.11beta2) and the BGP protocol (see RFC8950 - "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop"). The BGP instantiation of this I have long known but have never quite got my mind around what an LSR such as OSPF has to offer here. OSPFv3, which some regard as IPv6, has been able to carry IPv4 prefix for some time and it crops up in e.g. ospf-sr-yang (although I do not think is as a particularly SR issue). It is complex in part because LSR has become an ever more tangled mesh of (sub-(sub-)...TLV and I find it hard to know what TLV are valid where. Also, the advertised prefix are associated with flags and OSPFv2 and OSPFv3 flags are different reflecting the different ideas of links and the like in IPv4 and IPv6 so if you are advertising an IPv4 prefix over an IPv6 transport, whose flags are relevant? Probably both as the transport might affect e.g. the flooding while the ultimate user needs the other set of flags. Like I say, I have yet to get my mind around this. Tom Petch So, if this already works, why are we writing a document?! A few reasons, including: 1: This behavior / capability is surprising to many people - this means that people are "forced" to use IPv4 addresses where they otherwise would not. 2: There should be an easy way to reference this type of behaviour/deployment - the genesis of this document that Babel supports this (RFC9229 - "IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol"<https://datatracker.ietf.org/doc/rfc9229/>), but had to describe the behavior because there was nothing to point at. 2: A large number of implementations don't currently support it (or, at least, the tooling / CLI / UI doesn't allow configurations like the above). 3: There are some unsettled questions around the ICMP behavior — e.g: if a router has to send an ICMP packet too big, and it doesn't have an IPv4 address, what should it do? We'd really appreciate review and feedback — again, this isn't documenting a major "change", but more noting this the design of command lines, tooling, etc should allow it. W ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] How long wasWhat is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Behcet Sarikaya Sent: 06 April 2023 16:48 On Thu, Apr 6, 2023 at 5:17 AM tom petch mailto:ie...@btconnect.com>> wrote: From: Robert Moskowitz mailto:rgm-i...@htt-consult.com>> Sent: 05 April 2023 18:58 The origin draft only was discussing SCHC as an IP Protocol Number. At IETF115, the attendees agreed that the draft needs to be expanded to also SCHC as an Ethertype and as a UDP Port Number. Thus the old draft name no longer reflects the new content. A very common state of affairs in the IETF. If the name changed for every semantic change then some I-D would go through a large number of names before making it to RFC which would make it hard for anyone to find out what has happened. I recall an AD losing track of what had been proposed because they did not realise that there had been a name change. The I-D title matters, that is there for the long haul. The I-D file name is a temporary identifier that should follow the requirements for an identifier, a key one of which is stability and a key one which is not is for the name to be updated if some part of the semantics change. And another key one is being subject to maximum of 55 characters Mmm I wonder. If the line length is 72 characters and the footing contains 'Internet-draft' and 'December 2922' then I do not think that there is room for 55 characters. I note that RFC7991 says 'If it is long (~40 characters), the "abbrev" attribute can be used to specify an abbreviated variant.' which suggests a lower limit yo me. Tom Petch I am happy to see protocol number as encompassing an Ethertype protocol number, a media type protocol number, an interface protocol number and so on so see no need to change. Wholeheartedly agree. We should not have to change the I-D file name. Behcet Tom Petch p.s. I could tell you about a scientific (in)discipline where a small group feed their egos by changing identifiers every few years thereby rendering the literature, where a name could appear a million times, hard to use for those of us who have been around for a while and ever more difficult to access for students in future (which is how to feed an ego) but I will leave that for another day. There is a mechanism when you submit a draft to link it to a prior draft so the draft history is properly maintained (it does not support linking to multiple prior drafts or splitting an old draft into multiple, for that you have to ask for human help). So the new draft name will reflect the new draft content. I just don't have enough time to get content into the new draft prior to Passover Holiday start. I hope to get it done during the middle days, say Sunday. Stay tuned. Pascal Thubert is helping me with the new content. Particularly the specific content needed to liason with IEEE 802 on the Ethertype. Bob On 4/5/23 11:49, tom petch wrote: > From: Int-area mailto:int-area-boun...@ietf.org>> > on behalf of Robert Moskowitz > mailto:rgm-i...@htt-consult.com>> > Sent: 05 April 2023 12:22 > > I am in the process of reving draft > > draft-ietf-intarea-schc-ip-protocol-number > > and adding support for schc as an ethertype and tcp/udp port number as I > said I would do back in Nov. Sigh. > > So what to name the new draft? > > > If you are producing a new version of > draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it > draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other > logical choice. > > Tom Petch > > > > draft-ietf-intarea-schc-protocol-numbers > > ?? > > Alternatives? > > Thanks and now back to my writing as I really want to get an update out > today before Holidays... > > Bob > > ___ > Int-area mailing list > Int-area@ietf.org<mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Robert Moskowitz Sent: 05 April 2023 18:58 The origin draft only was discussing SCHC as an IP Protocol Number. At IETF115, the attendees agreed that the draft needs to be expanded to also SCHC as an Ethertype and as a UDP Port Number. Thus the old draft name no longer reflects the new content. A very common state of affairs in the IETF. If the name changed for every semantic change then some I-D would go through a large number of names before making it to RFC which would make it hard for anyone to find out what has happened. I recall an AD losing track of what had been proposed because they did not realise that there had been a name change. The I-D title matters, that is there for the long haul. The I-D file name is a temporary identifier that should follow the requirements for an identifier, a key one of which is stability and a key one which is not is for the name to be updated if some part of the semantics change. I am happy to see protocol number as encompassing an Ethertype protocol number, a media type protocol number, an interface protocol number and so on so see no need to change. Tom Petch p.s. I could tell you about a scientific (in)discipline where a small group feed their egos by changing identifiers every few years thereby rendering the literature, where a name could appear a million times, hard to use for those of us who have been around for a while and ever more difficult to access for students in future (which is how to feed an ego) but I will leave that for another day. There is a mechanism when you submit a draft to link it to a prior draft so the draft history is properly maintained (it does not support linking to multiple prior drafts or splitting an old draft into multiple, for that you have to ask for human help). So the new draft name will reflect the new draft content. I just don't have enough time to get content into the new draft prior to Passover Holiday start. I hope to get it done during the middle days, say Sunday. Stay tuned. Pascal Thubert is helping me with the new content. Particularly the specific content needed to liason with IEEE 802 on the Ethertype. Bob On 4/5/23 11:49, tom petch wrote: > From: Int-area on behalf of Robert Moskowitz > > Sent: 05 April 2023 12:22 > > I am in the process of reving draft > > draft-ietf-intarea-schc-ip-protocol-number > > and adding support for schc as an ethertype and tcp/udp port number as I > said I would do back in Nov. Sigh. > > So what to name the new draft? > > > If you are producing a new version of > draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it > draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other > logical choice. > > Tom Petch > > > > draft-ietf-intarea-schc-protocol-numbers > > ?? > > Alternatives? > > Thanks and now back to my writing as I really want to get an update out > today before Holidays... > > Bob > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 05 April 2023 12:22 I am in the process of reving draft draft-ietf-intarea-schc-ip-protocol-number and adding support for schc as an ethertype and tcp/udp port number as I said I would do back in Nov. Sigh. So what to name the new draft? If you are producing a new version of draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other logical choice. Tom Petch draft-ietf-intarea-schc-protocol-numbers ?? Alternatives? Thanks and now back to my writing as I really want to get an update out today before Holidays... Bob ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 08 September 2022 14:03 On 9/8/22 08:31, Pascal Thubert (pthubert) wrote: > Hello Joel: > > SCHC could be used to compress IP option headers and the residue be stored in > a SCHC option, which a next header points at uncompressed transport (e.g., > encrypted, uncompressible). > Additionally, finding the SCHC context may require metadata that could also > be found in a SCHC option. Over one hop in LPWAN that is all implicit but > over IP it might not be. > > SCHC is layered depending on which endpoint talks to which. E.g., you > compress a tunnel with inner that is already SCHC-compressed, you do > security, etc... > So you could have SCHC options one after the other. We have not defined the > option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs. > > But since we're at it, let's do both in one RFC. > Note that we'll also need a value for IPv6-Compression-Protocol Types, see > https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations. > I cannot find this IANA registry. Can someone please provide the URL. Perhaps https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29 IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field Assignments Group on the IANA website as set up by RFC1332. Tom Petch And this is why I have been instructed, and have adhered to, including IANA URLs as informative references in my drafts. Like in draft-moskowitz-intarea-schc-ip-protocol-number! Bob ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 07 September 2022 03:43 As was discussed at the INTAREA meeting at IETF 114, I request that a call for WG adoption of this draft. I have made draft name change and edits per Bob Hinden. I am sorry you have made this change. The draft name only has meaning for the life of the draft; it needs to be unique, it needs to guide readers as to its content, it does not have to be semantically and syntactically perfect. The document title, on the other hand, lives for ever and so its value matters - change the draft name just makes it harder for everyone to track what has and is happening. Tom Petch As I said earlier, there is a lot of work which will cascade in other areas once this is one its way. thanks Bob Forwarded Message Subject:New Version Notification for draft-moskowitz-intarea-schc-ip-protocol-number-00.txt Date: Tue, 06 Sep 2022 19:40:41 -0700 From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: Stuart W. Card <mailto:stu.c...@axenterprize.com>, Adam Wiethuechter <mailto:adam.wiethuech...@axenterprize.com>, Robert Moskowitz <mailto:r...@labs.htt-consult.com>, Stuart Card <mailto:stu.c...@axenterprize.com> A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-intarea-schc-ip-protocol-number Revision: 00 Title: Internet Protocol Number for SCHC Document date: 2022-09-06 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/ Html: https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number Abstract: This document requests an Internet Protocol Number assignment for SCHC so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] YANG was Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic
From: Int-area on behalf of Michael Sweet
Sent: 07 April 2022 15:11
Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure
domains to historic
Michael
I am well familiar with the work of IPP in the IETF. You mention MIBs which I
know of. Is there anything similar in YANG?
Tom Petch
Toerless,
> On Apr 7, 2022, at 5:38 AM, Toerless Eckert wrote:
> ...
> 2.) RFC1528 from Experimental to Historic
>
> I am not aware of a better, interoperable standard solution for remote
> printing (or should
> i say Internet FAX ?). Instead it feels to me as if every printer vendor has
> started
> its own proprietary remote-printing cloud-service. I hope i am wrong
> (pointers please),
> but if not, then i fear this decade old experiment is still the best we have ?
I don't know if this was meant as serious? But FWIW the IETF published the
Internet Printing Protocol (STD 92) more than 2 decades ago, and it is used by
nearly every network printer ("billions of printers") and most "cloud" printing
services (including Microsoft's Azure-based Universal Print Service). Any
printer with "AirPrint", "IPP Everywhere", "Mopria", or "Wi-Fi Direct" on the
box supports IPP.
The Printer Working Group (who is the current steward of IPP and the variable
SNMP printing MIBs) has also defined numerous IPP extensions, including
standards for cloud printing and Internet fax using a streamable subset of PDF.
So, assuming somebody doesn't just email you a file you can print it quite
easily using a single, standard protocol.
[But of course telephone-based fax still hasn't died - boggles the mind...]
Michael Sweet
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Where/How is the features innovation happening?
From: Int-area on behalf of Alexandre Petrescu Sent: 20 December 2021 20:28 Le 18/12/2021 à 23:47, Brian E Carpenter a écrit : > On 19-Dec-21 11:34, Dino Farinacci wrote: >>> From a user perspective, the choice is clear: privacy and security are >>> top requirements. We know that payload encryption goes a long way, and >>> hopefully encryption of the transport layer headers will become >>> dominant so that intermediate nodes will stop meddling and ossifying >>> the transport layer. But not everything can be encrypted, the IP >>> addresses for instance, so providing real security and privacy at the >>> plaintext network layer should be on the list of features to support >>> user requirements. >> >> Definitely agree Tom. >> >> But what if we sent a packet where the source address was encrypted? >> Then you could have global unique addresses (if you wanted them). Of >> course key exchange and rekeying parameters would have to be setup >> prior to sending a single packet. > > It's called SNA (Sourceless Network Architecture): > https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf Wasnt SNA an IBM acronym for an architecture? Silly Names and Acronyms as I recall; YMMV Tom Petch Alex > > Brian > >> Maybe its just simpler to randomize addresses. >> >> Dino >> > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] 110 mi utes
Looking at the materials page for IETF110 for Intarea at the minutes, they would appear to be in two parts, the first of which relates to 12mar2021, the second of which starts with Codimd INTAREA at IETF 109 Bob Hinden Good Morning ... Thoughts? Tom Petch ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always?
From: Int-area on behalf of Bob Briscoe Sent: 27 June 2021 22:22 James, [First apologies to everyone for asking the question then not following up on the answers until now - I went off line for a while.] See inline tagged [BB]... On 10/06/2021 13:09, James Bensley wrote: > On Wed, 9 Jun 2021 at 15:57, Derek Fawcus > wrote: >> On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote: >>> On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: >>>> Re BT specifically (and again my info is outdated and may be >>>> mis-remembered) the 20C network used L2TP, and I think it’s an option on >>>> 21C for handoff to smaller ISPs. Should all be in the SINs somewhere? >>> I work in the UK ISP sector. I can confirm that L2TP is in wide spread >>> use for wholesale services by all major ISPs (except Liberty). I think >>> the real question here (unless I've misunderstood) is not "is L2TP >>> being used" but "is L2TP being used AND sequencing is being used >>> and/or enforced?" - is that understanding correct? >> Yes. > In that case - sequencing isn't used for BT Wholesale services. [BB] Thank you. It sounds like you have some reason for your certainty here. Can you elaborate on what makes you so certain sequencing isn't used? Perhaps a coincidence or perhaps not, but an I-D has just been posted Author : Yogesh Nautiyal Filename: draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt which uses L2TP sequencing, I note the author has an affiliation of Juniper. The draft would need a fair bit of work. Tom Petch Bob > Cheers, > James. > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- Bob Briscoe http://bobbriscoe.net/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [Apn] A new draft on APN for your review, thank you!
From: Int-area on behalf of Pengshuping (Peng Shuping) Sent: 22 January 2021 02:08 Dear authors, We have updated the APN BoF Proposal as attached. The suggestions in your draft and the Whatever APN may stand for! I looked at the I-D and the Abstract uses APN with no explanation of what it is:-( It needs expanding on first use and while I could read on and perhaps find an explanation yet the idea is that the Abstract tells readers whether or not this is of interest to them and this Abstract does not. The rest of the I-D may be clearer but I am not gong to spend time finding out:-) Tom Petch discussions with you offline inspired us a lot. The support of the user/app group is explicitly shown in the text although it was implicitly included. We have made a lot of efforts on clarifying the scope of the work, introducing the basic solution, and describing the concrete use case. Please advise whether we are clear now and how we can improve further, especially on the privacy concerns. Thank you! This posted draft, https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis, would be able to give you more complete information. Please also refer to the recent discussions in the archives https://mailarchive.ietf.org/arch/browse/apn/ if you have not subscribed the APN mailing list yet. Based on discussions and suggestions we received, we will update this draft accordingly. Your reviews and comments will be very much appreciated. Thank you! Best regards, Shuping From: Apn [mailto:apn-boun...@ietf.org] On Behalf Of Pengshuping (Peng Shuping) Sent: Tuesday, December 15, 2020 11:12 AM To: a...@ietf.org; rt...@ietf.org Subject: [Apn] A new draft on APN for your review, thank you! Dear all, A new draft on APN has been posted, https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis. In this draft, we clarified the scope of the APN work in IETF, introduced an example use case and the basic solution. Moreover, we compared with the existing “similar” work/solutions and did corresponding gap analysis. Your review and comments are very much appreciated. Thank you! Best regards, Shuping A new version of I-D, draft-peng-apn-scope-gap-analysis-00.txt has been successfully submitted by Shuping Peng and posted to the IETF repository. Name: draft-peng-apn-scope-gap-analysis Revision: 00 Title: APN Scope and Gap Analysis Document date: 2020-12-16 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-peng-apn-scope-gap-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/ Htmlized: https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis Htmlized: https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-00 Abstract: The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an identifier to allow for implementing fine-grain user-, application-, and service-level requirements at the network layer. This document describes the scope of the APN work and the solution gap analysis. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Evaluate impact of MAC address randomization to IP applications
From: Int-area on behalf of Eric Vyncke (evyncke) Sent: 23 September 2020 15:02 In another century, DECnet phase 4 was also changing the MAC address (and if not mistaken IBM SNA also) but flipping the universal/local bit of the MAC address Not so much SNA as token ring which almost always used configured local addresses (which made management so much easier). SNA did not care much about layer 2 as long as it was fast and reliable. SNA over DIX Ethernet or over 802.3 I would expect to see using universal (burnt-in) addresses. Tom Petch -éric From: Int-area on behalf of Stewart Bryant Date: Wednesday, 23 September 2020 at 12:38 To: Andy Smith Cc: "int-area@ietf.org" Subject: Re: [Int-area] Evaluate impact of MAC address randomization to IP applications So I am curious, and probably out of touch. MAC addresses are supposed to be unique hardware device addresses that ultimately come from a registry administered by IEEE and are supposed to be allocated exactly once to one hardware entity. Is MAC address randomisation something that IEEE approve of, in which case how does the registry work, or are we at risk of working on a problem that results in an interSDO dispute? - Stewart On 22 Sep 2020, at 21:22, Andy Smith mailto:ajsph...@gmail.com>> wrote: Yiu- I’d like to help here. Is the problem that residential devices can’t be reliably tracked for purposes of policy enforcement? Or is it an IP address depletion issue? I noticed iOS 14 does allow for disabling of random MAC addresses. Andy Sent with emacs for iOS On Sep 22, 2020, at 15:50, Lee, Yiu mailto:yiu_...@comcast.com>> wrote: Hi team, We proposed a BoF. The agenda is in https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the proposal is in https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. You can also find the draft here https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01. At this stage, we are looking for inputs for more use cases and interests of working together in this domain. Please post your comments in the mailing list. Thanks ___ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
From: Int-area on behalf of Colin Perkins Sent: 01 July 2020 10:57 On 30 Jun 2020, at 01:59, Eric Rescorla mailto:e...@rtfm.com>> wrote: > This 3rd WGLC is limited to the following two topics: > Whether or not to proceed with a request for RFC publication > of the draft. The decision on whether or not to proceed will > be based on rough consensus of the WG, see RFC 7282. Publish. Operators need help in understanding the impact of emerging technology on their ability to operate a network. This may not be easy to understand but it does at least provide something to stick out and alert them. Tom Petch > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > strong views that this draft should not be published – those > concerns have not been resolved and are carried forward to > this WGLC. This email message was an attempt to summarize > those concerns: > > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ > > Further explanation from both Eric Rescorla and David Schinazi > is welcome and encouraged to ensure that their concerns are > clearly understood. Well, I'll try again, but I'm not sure that I can do better than I have before. For reasons that are laid out in RFC 7258, the trend in protocol design in IETF is towards encrypting more and more. I agree, but also note that RFC 7258 is clear that some network monitoring can be beneficial and that “an appropriate balance” has to be found between mitigating pervasive monitoring and supporting network management. This draft is intended to highlight issues to be considered by transport protocol designers, to help them find that balance. And, to be clear, if transport protocol designers consider the issues and decide that all the metadata in their transport protocol must be encrypted, that’s fine. We're not pushing for a particular outcome; rather that the issues be considered and discussed when making a decision on what to encrypt. The last two transport protocols that were designed and widely deployed (SCTP over DTLS and QUIC) both encrypt the vast majority of the protocol metadata. This document advertises itself as "considerations" for design of such protocols: The transport protocols developed for the Internet are used across a wide range of paths across network segments with many different regulatory, commercial, and engineering considerations. This document considers some of the costs and changes to network management and research that are implied by widespread use of transport protocols that encrypt their transport header information. It reviews the implications of developing transport protocols that use end-to-end encryption to provide confidentiality of their transport layer headers, and considers the effect of such changes on transport protocol design, transport protocol evolution, and network operations. It also considers some anticipated implications on application evolution. This provides considerations relating to the design of transport protocols and features where the transport protocol encrypts some or all of their header information. However, as I said above, the new transport protocols that are actually being designed already feature metadata encryption and as far as I can tell, there is no prospective protocol new transport protocol design project for which these issues might be live. The issues highlighted in the draft were certainly considered in the design of QUIC, especially in the discussions around the spin bit and operational aspects. I cannot envisage that they won’t also be considered in the design of future transports. In that context, it's hard not to read this document with its long litany of practices which are impacted by metadata encryption as a critique of the decisions by SCTP/DTLS and QUIC to encrypt most of the metadata. I tend to regard critiques of protocol design as a good thing, but then we maybe have a different interpretations of that term. Certainly there are implications of the decision to encrypt transport metadata. There are benefits to it, but also costs. It’s important to understand both, to make an informed judgement on what to encrypt. This impression is reinforced by the description of the actual practices themselves, which focuses almost entirely on practices which appear to be benignly motivated (e.g., performance monitoring, troubleshooting, etc.) However, we also know that metadata is widely used for practices in which the network operator is adversarial to the user, for instance: - Blocking traffic based on TCP port, IP address, SNI, etc. - Performance-based traffic class discrimination - Monitoring the user's behavior via indicia like the ones above or via traffic analysis (see [0]) Yes, I understand that the authors explicitly disclaim judgement on these practices, and the document does briefly touch on the
Re: [Int-area] AD sponsoring draft-thaler-iftype-reg-02
Suresh The concern I have is that it muddies the waters further on the standing of tunnels so while I think that its proposals for ifType per se are fine, I would like it to make explicit that tunnels are out-of-scope at this time. I have been trying to reconcile the workings of softwire, in creating a tunnel YANG module, with the existing IANA structure and failing. I believe that is because the current status of tunnels is unclear. Thus the softwire I-D refers to a registry that does not exist (as such) although the URL that the softwire I-D does. I think the timing unfortunate in that IMHO the softwires I-D will get pressed ahead before this work can complete, so quite what this I-D then says about tunnels will be coloured by what then exists for tunnels. So this I-D should make clear what a tunnel is, when it is not an interface, but otherwise declaring tunnels out-of-scope, for a future I-D to do a comparable job for tunnels, setting up a tunnel registry from which MIB modules, YANG modules and anything else can be derived (as long as the relevant data is supplied - SMI needs integers, YANG does not, which I-Ds do not always recognise although the Designated Experts can take care of that). Finally, when I first encountered this I-D I asked on NETCONF and NETMOD WG lists if anyone knew of it, where it was being worked on and got no reply - which surprised me. I note that you have not copied them although they were involved in making the interface type registry what it currently is when creating the YANG module for interface types. I wonder if other WG have an interest, CCAMP or TEAS perhaps. I agree that int-area is the WG best equipped to work on it and that it needs working on. Tom Petch - Original Message - From: "Suresh Krishnan" To: "int-area" ; "6man" ; "dhcwg" ; "V6 Ops List" ; ; Sent: Wednesday, June 12, 2019 7:22 PM Hi all, I would like to AD sponsor the following draft that provides guidelines for definition of new interface types in the IANA IfType registries https://tools.ietf.org/html/draft-thaler-iftype-reg-02 If you have any concerns either with the contents of the draft, or about me AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potentially interested in this work. If you think I have missed out some WG(s) please let me know. > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] registering tunnel types
- Original Message - From: To: "tom petch" ; Sent: Monday, October 29, 2018 10:42 AM Hi Tom, all, In order to provide a full context, below some precisions: * draft-ietf-softwire-yang DOES NOT create a new registry for maintaining tunnel types nor changes the procedure to assign new code points. Such register does already exist: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbe rs-6. * draft-ietf-softwire-yang creates a YANG module which **maintained by IANA**; that is, upon assignment of a new code by IANA, the module is updated automatically by IANA. * draft-ietf-softwire-yang augments the interface YANG module with aplusp specific nodes. To do so, it requires the tunnel type to be set to aplusp. Med I think that there is a little more to it than that. There is indeed an existing tunnel type registry in the SMI Group for use by MIB modules. The I-D requests an addition to the tunnel type registry. I think that all previous such requests in an RFC have come along with a MIB and then a subset of the MIB information has been added to the related YANG module. Here the process is reversed and so we are implicitly updating the MIB module (adding a new numeric value which YANG does not have - I assume that the designated expert will assign a value). It should work but is a new and different process. The IANA Considerations in this I-D seem to neglect the need to update, the impact on, the tunnel MIB module. The I-D does say 'The name of the "identity" is the same as the corresponding enumeration in the IANAifType-MIB. ' which is wrong - we are dealing with tunnelType not ifType here. More widely, should we cater for a definition which is YANG only, or is it still right to keep the MIB and YANG modules in line? Does the NETMOD WG have a view on this? Is the Designated Expert for the MIB module ok to take over the responsibility for making additions to a YANG Module? And I think that the current reference to RFC4087 for tunnelType in IANA needs updating. To me, there are a number of ramifications spreading out across the IETF and I doubt if I can see them all. Tom Petch Cheers, Med > -Message d'origine- > De : Int-area [mailto:int-area-boun...@ietf.org] De la part de tom petch > Envoyé : vendredi 26 octobre 2018 14:05 > À : int-area@ietf.org > Objet : [Int-area] registering tunnel types > > I am not sure where tunnels have a home in the IETF but for anyone with > an interest in them, draft-ietf-softwire-yang, having completed IETF > Last Call two weeks ago, has since acquired a YANG module for tunnel > types, based on the Tunnel MIB, RFC4087, which seems not to have been > turned into a YANG module before. > > I am unsure where the place to discuss such a topic is; softwires, which > owns the I-D containing the module, would be the place for aplusp but > perhaps not for the others. I have forwarded this to 6man thinking that > they would have an interest. > > The I-D has been revised five times since Last Call completed and I have > suggested that it needs to go back to softwires for them to agree this > is really what they want before the I-D goes any further. > > Tom Petch > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] registering tunnel types
I am not sure where tunnels have a home in the IETF but for anyone with an interest in them, draft-ietf-softwire-yang, having completed IETF Last Call two weeks ago, has since acquired a YANG module for tunnel types, based on the Tunnel MIB, RFC4087, which seems not to have been turned into a YANG module before. I am unsure where the place to discuss such a topic is; softwires, which owns the I-D containing the module, would be the place for aplusp but perhaps not for the others. I have forwarded this to 6man thinking that they would have an interest. The I-D has been revised five times since Last Call completed and I have suggested that it needs to go back to softwires for them to agree this is really what they want before the I-D goes any further. Tom Petch ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
