[Int-area] IP broadcast and multicast protocol considerations

Hi, we just posted a draft that discusses considerations for IP broadcast/multicast protocol designers: https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-00 We presented this work briefly during the last meeting in Yokohama in a 1 minute pitch during the chairs presentation

Re: [Int-area] IP broadcast and multicast protocol considerations

sec 5 and 6. Joe On 1/18/2016 4:07 AM, Rolf Winter wrote: Hi, we just posted a draft that discusses considerations for IP broadcast/multicast protocol designers: https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-00 We presented this work briefly during the last meeting in Y

Re: [Int-area] IP broadcast and multicast protocol considerations

Am 1/25/16 um 10:54 PM schrieb Joe Touch: On 1/25/2016 1:47 PM, Rolf Winter wrote: Hi Joe, The document focusses right now on observed behaviour of dominant protocols by a) volume/message frequency and b) content that gives away privacy relevant information. Some of these are (popular

Re: [Int-area] IP broadcast and multicast protocol considerations

Am 1/26/16 um 1:10 AM schrieb Christian Huitema: On Monday, January 25, 2016 2:16 PM, Rolf Winter wrote: Am 1/25/16 um 10:54 PM schrieb Joe Touch: On 1/25/2016 1:47 PM, Rolf Winter wrote: Hi Joe, The document focusses right now on observed behaviour of dominant protocols by a) volume

Re: [Int-area] IP broadcast and multicast protocol considerations

Am 1/26/16 um 2:01 AM schrieb Christian Huitema: On Monday, January 25, 2016 4:37 PM, Rolf Winter wrote: Am 1/26/16 um 1:10 AM schrieb Christian Huitema: ... Rolf, I appreciate that you are trying to improve network privacy, but I wonder whether a generic abstract draft is the best way to

Re: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-02.txt

Rolf Winter Filename: draft-ietf-intarea-hostname-practice-02.txt Pages : 10 Date: 2016-05-10 Abstract: Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet

Re: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-03.txt

the IETF. Title : Current Hostname Practice Considered Harmful Authors : Christian Huitema Dave Thaler Rolf Winter Filename: draft-ietf-intarea-hostname-practice-03.txt Pages : 11

Re: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02

Eliot, thanks for the review. Please find comments inline: Am 8/27/16 um 9:29 AM schrieb Eliot Lear: Juan Carlos, I like the idea of this document being published as an informational document, but I wonder if the document needs another rev or two first. While it is important to have privacy c

Re: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02

13 PM schrieb Eliot Lear: Rolf, Thanks. Please see below. On 8/29/16 8:57 PM, Rolf Winter wrote: What is needed are specific recommendations or even the strengthening of a generalized mechanism, the obvious candidate being mDNS/DNS-SD. What specific recommendations would the authors make

Re: [Int-area] Remarks on draft-winfaa-intarea-broadcast-consider-02

Hi Stephane, thanks for the review. We just posted a new version incorporating your comments (see inline). We currently work on another version incorporating examples as suggested. https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-03 Am 9/9/16 um 3:02 PM schrieb Stephane Bo

[Int-area] New Version Notification for draft-intarea-broadcast-consider-02

Hi, we just posted version 02 of the broadcast/multicast considerations draft. We believe we have now addressed the review comments that the document has received during last call. Could commentors please check? Best, Rolf ___ Int-area mailing lis

Re: [Int-area] New Version Notification for draft-intarea-broadcast-consider-02

Hi, me again... that of course should read: "during the adoption call". Best, Rolf Am 10/31/16 um 10:10 AM schrieb Rolf Winter: Hi, we just posted version 02 of the broadcast/multicast considerations draft. We believe we have now addressed the review comments that the document ha

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename: draft-ietf-intarea-broadcast-consider-01.txt Pages : 10 Date: 2016-10-31 Abstract: A number of

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

particular? Regards Brian Carpenter On 01/11/2016 03:08, Rolf Winter wrote: Hi, Apologies, but I screwed up the draft naming convention and just uploaded the 00 and a 01 version with correct naming. The 00 version is the one that was adopted by the WG, the 01 version now addresses the comments made by

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

is important in the Internet architecture. Joe On 11/2/2016 3:34 AM, Rolf Winter wrote: Hi Brian, great that you found the document useful. Since the 00 version a lot has changed, and you might want to look at it again. We will look at RFC 5374 and see where it should be mentioned in the

Re: [Int-area] Kathleen Moriarty's Yes on draft-ietf-intarea-hostname-practice-04: (with COMMENT)

Hi, Randomized hostnames might have implications in places we do not even think about for now, so why not take this as a mere example. Also, it seems that the randomization might not be the problem but the time between changes of a name, if tracking is the only use case. How about: There are

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-02.txt

protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename: draft-ietf-intarea-broadcast-consider-02.txt Pages : 11 Date: 2017-02-13 Abstract: A number of

Re: [Int-area] WGLC for draft-ietf-intarea-broadcast-consider

Dear chairs, I am not aware of any IPR related to this document. Best, Rolf Am 3/6/17 um 10:09 PM schrieb Juan Carlos Zuniga: Dear Int-Area WG, A review of draft-ietf-intarea-broadcast-consider has been published. Since there was good support for this document from the beginning and the new

Re: [Int-area] WGLC for draft-ietf-intarea-broadcast-consider

Tom, see inline. Am 3/9/17 um 6:13 PM schrieb t.petch: I wonder if the mix of SHOULD and should is intentional. And I cannot recall seeing RFC2119 as an Informative Reference before. Will be fixed. s.1 / entierly/ entirely/ thanks, will be fixed, too. And I am surprised at the lack

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-03.txt

the Internet Area Working Group of the IETF. Title : Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-04.txt

Internet-Drafts directories. This draft is a work item of the Internet Area Working Group WG of the IETF. Title : Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath

Re: [Int-area] Call for support: IPmix I-D (was IPv10)

Hi, I am quite strongly opposed to assign any further IETF ressources to this work. This has gone on too long for my taste. In April (!!, https://www.ietf.org/mail-archive/web/int-area/current/msg05634.html) the WG has already determined that it does not want to pursue this work any further.

Re: [Int-area] IoT-dir early review of draft-ietf-intarea-broadcast-consider

Hi, thanks for the review and sorry for the belated reply. Please see comments inline. Am 26.09.17 um 00:57 schrieb Nancy Cam-Winget (ncamwing): Reviewer: Nancy Cam-Winget Review result: On the right track *General Comments* There are actual distinctions that need to be made from a general

Re: [Int-area] Intdir early review of draft-ietf-intarea-broadcast-consider-04

Carlos, thanks for the review and sorry for the belated reply. Please inline: Am 24.09.17 um 09:32 schrieb Carlos Bernardos: Reviewer: Carlos Bernardos Review result: Ready with Nits The document is well written and clear to follow. I have not found any major issue. I have some recommendations

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-05.txt

: Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename: draft-ietf-intarea-broadcast-consider-05.txt Pages : 13

Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

Carlos, thanks for the review. Comments below: Am 14.01.18 um 05:20 schrieb Carlos Pignataro: Reviewer: Carlos Pignataro Review result: Not Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-re

Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

nataro (cpignata): Hi, Rolf, On Jan 16, 2018, at 4:53 AM, Rolf Winter <mailto:rolf.win...@hs-augsburg.de>> wrote: Carlos, thanks for the review. Comments below: Thanks to you for the quick response, and for the document. Please see inline. Am 14.01.18 um 05:20 schrieb Carlos Pignatar

Re: [Int-area] Warren Kumari's Discuss on draft-ietf-intarea-broadcast-consider-08: (with DISCUSS and COMMENT)

Warren, I think I understand the issue you have with that bit of text. draft-perkins-intarea-multicast-ieee802 discusses a bunch of bcast/mcast management features that certain classes of APs provide. We have one example of this in the draft (and should point to draft-perkins-intarea-multicas

Re: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

Hi, these pointers are very useful. Thanks. I would add one more: https://tools.ietf.org/html/rfc8386 We know for a fact that there are protocols out there, even at the application layer, that would thwart efforts to randomize MAC addresses. Of course you'd have to be connected to the same L2

[Int-area] Reverse Traceroute draft

Dear Intarea WG, we have just submitted a 00 version of a reverse traceroute mechanism relying on ICMP. You can find the document here. https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-00 The mechanism that is described there has been implemented in eBFP (server)

[Int-area] Reverse Traceroute - running code

Dear Intarea WG, in the not so distant future, we will make an update to our internet draft on a reverse traceroute mechanism, that you can find here: https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-00 Feedback welcome! We now also have publicly available runnin

[Int-area] Reverse Traceroute - update

Dear Int-area folks, we have updated our reverse traceroute draft. As always, we appreciate comments and feedback on the document. You can find the new version here: https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-01 Also, our implementation has progressed. Both

Re: [Int-area] New Draft - ICMPv6 Loopback

Hi Tal, I don't think your assessment that a new type is required really holds for every case. I think the key point is, the requests get _reflected_. So if you expect something else in you response (e.g. Echo Request would expect a different type in the Echo Response), then you can distinguis

Re: [Int-area] New Draft - ICMPv6 Loopback

eaner. Cheers, Tal. On Wed, Jun 21, 2023 at 12:39 PM Rolf Winter wrote: Hi Tal, I don't think your assessment that a new type is required really holds for every case. I think the key point is, the requests get _reflected_. So if you expect something else in you response (e.g. Echo Request woul

[Int-area] Reverse Traceroute Alternative

Dear Int-Area WG, the last time we presented Reverse Traceroute a comment was made that ICMP as being used today usually does not keep state around. We still believe that it does no real harm in this case but, as an alternative that does not need state, we have written up a stateless alternati

[Int-area] Re: Reverse Traceroute Alternative

ation). Thanks, Rolf Am 03.06.24 um 18:16 schrieb Dan Wing: This is a great design and the statelessness also reduces amplification attack. -d On May 31, 2024, at 11:17 AM, Rolf Winter wrote: Dear Int-Area WG, the last time we presented Reverse Traceroute a comment was made that ICMP as being

[Int-area] Re: Reverse Traceroute Alternative

Hi Ron, you raise a valid point, which however is not specific to reverse traceroute but applies to regular traceroute just as well, since we perform the exact same operation. One way to deal with this is assign a port for this purpose just as for regular traceroute: https://www.iana.org/ass

[Int-area] Re: Reverse Traceroute Alternative

Hi Ron, to your first point: in reality, it is actually slightly more complicated than this. If I run e.g. traceroute on my Mac, it will per default use UDP (Windows tracert e.g. would use ICMP Echo Requests) and it will have a little bit of payload (12 bytes all 0). It will use the same sour

[Int-area] new version of stateless reverse traceroute

Dear IntArea WG, we have submitted a new version of our stateless reverse traceroute draft. https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless The biggest change is that we have added an ICMP multi-part extension for adding padding bytes to the request in o

[Int-area] Re: Some comments on draft-heiwin-intarea-reverse-traceroute-stateless

Dear Eric, thank you for your comments. I inlined my replies. Am 21.07.24 um 16:51 schrieb Eric Vyncke (evyncke): Dear authors, Without any hat (i.e., feel free to ignore), in preparation for the IETF-120 I have read your I-D and here are some comments. As always, reviews note the things to

[Int-area] v03 Stateless Reverse Traceroute

Dear Int-Area WG, we just updated the Stateless Reverse Traceroute document. https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless-03 The changes are: - changed "TTL" to "TTL/Hop Limit" throughout the text, as was requested. We also changed the name of the "T

[Int-area] Re: v03 Stateless Reverse Traceroute

4 at 05:18:49PM +0200, Rolf Winter wrote: Dear Int-Area WG, we just updated the Stateless Reverse Traceroute document. https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless-03 The changes are: - changed "TTL" to "TTL/Hop Limit" throughout the t

[Int-area] Re: v03 Stateless Reverse Traceroute

4884 for details. You can avoid this problem by using the ICMP Extended Echo Request and Extended Echo Reply instead. See Sections 2 and 3 of RC 8335 for details.   Ron Message: 1 Date: Wed, 28 Aug 2024 17:18:49 +020

[Int-area] Re: v03 Stateless Reverse Traceroute

 Ron Juniper Business Use Only *From:* Rolf Winter *Sent:* Wednesday, October 2, 2024 3:15 PM *To:* Ron Bonica; int-area@ietf.org *Subject:* Re: [Int-area] Re: v03 Stateless Reverse Traceroute Hey Ron, please see inline

[Int-area] Reverse Traceroute - with or without state

Hi, during the last IETF meeting I presented Stateless Reverse Traceroute (https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless) and mentioned, that I personally would leave it to the implementation to decide whether it will use state or not. Keeping a litt

[Int-area] Re: v03 Stateless Reverse Traceroute

Hey Ron, please see inline: Am 02.10.24 um 17:06 schrieb Ron Bonica: Rolf, Please keep in mind that we are not talking about a new ICMPv6 message. This message was defined in RFC 8335. RFC 8335 was published in 2018. There are multiple implementations .

[Int-area] Re: Presentation on analog MTU that fell off of the Int-Area agenda

Having larger MTUs and machinery around it so it works reliably also with the installed base is an applaudable goal. Not sure if an IETF document can convice the IEEE to spec this out, but it is definately worth trying. Am 06.11.24 um 16:09 schrieb Matt Mathis: The deck is pretty much self exp

[Int-area] Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)

I don't want to drag this unneccisarily long but RFC 792 also states that Echo is (type 0, code 0) and (type 8, code 0) whereas we propose (type 0, some code != 0) and (type 8, some code != 0). Just to be clear, we do not change the semantics of standard Echo _definded by the type/code combinat

[Int-area] Reverse Traceroute - Open Issue 1: Encoding

Hi, I would like to use the energy from the meeting to get closure on the two issues I presented at the meeting. I will use two separate Email threads, one for each issue. Here, I'd like to come back to the encoding question - or going with ICMP Echo or Extended Echo. As I said, the authors

[Int-area] Reverse Traceroute - Open Issue 1: Stateful vs. stateless

As promised, the second Email: The question is to go either fully stateless for the server, fully stateful or let the implementation decide. We - the authors - believe that letting the implementation decide is the right thing to do. If anybody would like to reliably offer RTT estimates or "adv

[Int-area] Re: Fw: Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)

PM *To:* Rolf Winter *Subject:* Re: [Int-area] Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter) Rolf, Inline [RB]                        Ron *From:* Rolf Winter *Sent:* Wednesday, November 6, 2024 1:18 PM

[Int-area] Re: Fw: Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)

Continuing inline: Am 07.11.24 um 00:03 schrieb Ron Bonica: Including the WG Juniper Business Use Only *From:* Ron Bonica *Sent:* Wednesday, November 6, 2024 4:01 PM *To:* Rolf Winter *Subject:* Re: [Int-area] Re

[Int-area] Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)

Ron, see inline. Am 06.11.24 um 18:12 schrieb Ron Bonica: Rolf, I do not think that legacy middlebox behavior is a good reason to change existing PDU semantics. The following are rationale: 1. We may be subverting the purpose of the middle box. Some middleboxes are firewalls. Assum