+1
> On Oct 31, 2022, at 8:37 AM, Michael Richardson wrote:
>
>
> Tero Kivinen wrote:
>> My understanding is that this draft (which I have not yet properly
>> read) is solving the situation where the tunnel does not get ICMP PTB
>> messages as they are forwarding packets with DF bit set to 0,
Hi, all,
FYI - there is also a UDP PLPMTUD draft in process that leverages the new UDP
options I’m currently developing, which might be useful to take a look at as
well:
draft-fairhurst-tsvwg-datagram-plpmtud
Joe
> On Jan 23, 2018, at 1:04 PM, Dan Wing wrote:
>
>
>> On Jan 23, 2018, at 9:5
On 4/26/2017 3:43 AM, Tero Kivinen wrote:
> Paul Wouters writes:
>> ...
>> So it should add an Updates: RFC-3947
> Not really.
... (basically points to other more appropriate RFCs to UPDATE)
I'll leave it to you and the IESG to determine what RFC this document
should be updated to correctly chan
On 4/25/2017 8:46 PM, Yoav Nir wrote:
> ...
>>> While it is the default port for HTTPS, that protocol can run on any
>>> port depending on the value in origin (RFC 6454).
>>
>> Yes, any protocol can run on any port number (as per above), as long
>> as the endpoints agree. But that's not what you'
Hi, Tommy,
On 4/25/2017 8:34 PM, Tommy Pauly wrote:
> I suggest that we can:
>
> - Clarify the text in section 2 (configuration) to say that the
> default port is TCP 4500, and that implementations may communicate
> other port options out of band as configuration. This is done for UDP
> as well.
First, correcting the subject line (sorry - that looks like an erroneous
paste on my part).
Also below...
On 4/25/2017 1:59 PM, Yoav Nir wrote:
> Hi, Joe
>
> I haven’t been involved with this draft, but I don’t believe that last
> statement is correct:
>
>> On 25 Apr 2017
Hi, Paul,
On 4/25/2017 12:04 PM, Paul Wouters wrote:
> On Tue, 25 Apr 2017, Joe Touch wrote:
>
>> Ports issues:
>>
>> Every bit pattern, including those using magic numbers, is already
>> owned and under the control of each assigned port. It is not
>> appro
Hi, all,
I'm providing this feedback at the request of the ADs.
The port information is based on my experience as IANA port review team lead.
The transport information is based on my experience in TSV-ART.
Joe
Ports issues:
Every bit pattern, including those using magic numb
On 9/12/2014 11:02 AM, Paul Wouters wrote:
> On Fri, 12 Sep 2014, Yaron Sheffer wrote:
>
>> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG
>> document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 19.
>
> This document confuses
On 10/27/2013 10:41 PM, Valery Smyslov wrote:
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).
Except that if you continue to allow IP fragmentation, you can't claim
your solution is robust to IP fragment poison
On 10/27/2013 11:20 PM, Yoav Nir wrote:
I guess the idea is that if the packet is still bigger than the PMTU,
then the IKE host gets back a "fragmentation needed" ICMP, and the IKE
daemon learns of that and resends packets with appropriately small size.
There are some issues with this:
You p
On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.
No, the timeouts are diff
On 10/23/2013 11:42 PM, Valery Smyslov wrote:
Hi Joe,
thank you for your suggestions. I still have some comments.
On 10/22/2013 11:25 PM, Valery Smyslov wrote:
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here a
On 10/22/2013 11:25 PM, Valery Smyslov wrote:
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here and why.
And you may consider PMTUD in IKE as simplified PLMTUD,
implemented according with Section 10.4 of RFC4821.
Hi, Valery,
On 10/22/2013 5:50 AM, Valery Smyslov wrote:
Hi Joe,
thank you for your review.
Please, see my comments inline.
Hi, all,
I've reviewed the following doc for TSVDIR:
draft-ietf-ipsecme-ikev2-fragmentation-04
Although this is not intended as a complete TSVDIR review, I have
checke
Hi, all,
I've reviewed the following doc for TSVDIR:
draft-amjads-ipsecme-ikev2-data-channel-00
Although this is not intended as a complete TSVDIR review, I have
checked for the typical issues.
Joe
---
draft-amjads-ipsecme-i
Hi, all,
I've reviewed the following doc for TSVDIR:
draft-ietf-ipsecme-ikev2-fragmentation-04
Although this is not intended as a complete TSVDIR review, I have
checked for the typical issues.
Joe
---
draft-ietf-ipsecme
On 8/25/2010 2:35 PM, Paul Hoffman wrote:
First off, Thomas gave the wrong pointer. The draft under discussion is
draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter
became RFC 4294.
At 12:55 PM -0700 8/25/10, Joe Touch wrote:
Hi, Tom,
On 8/25/2010 6:20 AM
18 matches
Mail list logo
