I said this at the mic, but I'm not sure there's anything really GRE-specific
here.
If you generalize it then my question is...
RFC 4213 has this algorithm as a "SHOULD employ":
> if (IPv4 path MTU - 20) is less than 1280
> if packet is larger than 1280 bytes
> Send ICM
I'm a co-author but I support adoption.
Just didn't want my silence to NOT imply consent :)
Dave
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Suresh
> Krishnan
> Sent: Wednesday, September 30, 2015 2:09 PM
> To: Internet Area
> Subject: [Int-area
I notice that currently RFC 4389 is not referenced at all.
It’s Experimental since there are many ways of proxying and it just describes
one of them,
but I still think it bears referencing informatively, especially since section
6 of that RFC is
very relevant to the discussion on loops in the doc
I just found a couple typos, and suggest one potential addition below…
Grammar issue in -02:
> Experiments on operational networks such as the IETF meeting network
> have shown that with the help of external data such as the publicly
> available IETF attendees list or other data sources such
Right. I think Windows even had an implementation of NIQ at one point.
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of
> Sent: Tuesday, March 28, 2017 1:40 PM
> To: Internet Area
> Subject: [Int-area] xping and IPv6 Node Information Queries
>
>
Section 2.1:
> If the Interface Identification Object identifies the probed
> interface by name, the object payload contains the human-readable
> interface name. The interface name SHOULD be the full MIB-II ifName,
> if less than 255 octets, or the first 255 octets of the ifName, if
> th
BTW, RFC 7564 is being updated by
https://tools.ietf.org/html/draft-ietf-precis-7564bis-09 which is in IESG
evaluation.
-Original Message-
From: Dave Thaler
Sent: Thursday, July 20, 2017 10:01 AM
To: 'Ron Bonica' ; int-area@ietf.org
Subject: RE: [Int-area] I-D Action: draft-ie
me than an interfacename.
-Original Message-----
From: Dave Thaler
Sent: Thursday, July 20, 2017 10:03 AM
To: 'Ron Bonica' ; 'int-area@ietf.org'
Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt
BTW, RFC 7564 is being updated by
https://tools.ietf.org/htm
urday, July 22, 2017 12:29 PM
> To: intarea-cha...@ietf.org; int-area@ietf.org; Dave Thaler
>
> Subject: FW: New Version Notification for draft-ietf-intarea-probe-02.txt
>
> Folks,
>
> I have updated draft-intarea-probe-02 to reflect Dave Thaler' s comment.
>
-Original Message-
From: dhcwg On Behalf Of tom petch
Sent: Friday, June 14, 2019 9:28 AM
To: Suresh Krishnan ; int-area ; 6man
; dhcwg ; V6 Ops List ;
ops...@ietf.org; softwi...@ietf.org
Subject: Re: [dhcwg] [Int-area] AD sponsoring draft-thaler-iftype-reg-02
Suresh
The concern
f Of Dave Thaler
Sent: Friday, July 5, 2019 12:17 PM
To: tom petch ; Suresh Krishnan ;
int-area ; 6man ; dhcwg ; V6
Ops List ; ops...@ietf.org; softwi...@ietf.org
Subject: Re: [Softwires] [Int-area] AD sponsoring draft-thaler-iftype-reg-02
-Original Message-
From: dhcwg mailto:dhcwg-
S. Moonesamy wrote:
> RFC 2863 is a Draft Standard which states that it specifies a protocol.
> draft-thaler-iftype-reg is about guidance for registration requests. The
> write-up
> does not explain why the intended status of the document is "Proposed
> Standard".
> That is an usual (intended)
In the ARTAREA and INTAREA meetings, I gave an announcement about the eBPF side
meeting on Thursday.
Time: 6pm London time
Duration: 1 hour
Zoom: https://us06web.zoom.us/j/83038515863?pwd=czQrWTdVcGlMWER2MGN6V2pOSFhGQT09
In person room: Mezzanine 12
The eBPF Foundation has entertained four possi
1) Section 3.2 should motivate better why Path MTU Discovery doesn't already
solve this problem. Certainly one issue is that the router has to communicate
a value larger than the link MTU in the IP-over-foo document, no question about
that. But once that is done, why do you need the ND probing
> -Original Message-
> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 11, 2008 12:34 PM
> To: Dave Thaler
> Cc: [EMAIL PROTECTED]
> Subject: Re: Comments on draft-van-beijnum-multi-mtu-02
>
> On 10 mrt 2008, at 23:17, Dave Thaler wro
> -Original Message-
> From: marcelo bagnulo braun [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2008 4:01 AM
> To: int-area@ietf.org
> Cc: Dave Thaler; Dan Wing; Jari Arkko; Iljitsch van Beijnum; Philip
> Matthews; Brian E Carpenter; Alberto García
> Subject:
ect: Re: [Int-area] practical issues with using v4-mapped addresses
> for nat64
>
> On Jul 22, 2008, at 5:25 PM, Dave Thaler wrote:
> > If you have a dual-IP-version
> > network and a host OS that supports both IPv4 and IPv6, why would
> > anyone disable IPv4 on the host? Tha
es.
-Dave
> -Original Message-
> From: Ted Lemon [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 22, 2008 5:35 PM
> To: Dave Thaler
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] practical issues with using v4-mapped addresses
> for nat64
>
> On Jul 22, 2008, at
[...]
> > I think you need to consider what scenario you're targeting NAT-PT
> for.
> > I would argue that a dual-stack OS with IPv4 disabled is not a common
> > scenario.
> why not?
> I thought this was one of the primary scenarios..
> I mean, i though we were targetting for the case when there ar
rcelo/Iljitsch try this on the
other OS's they're checking for comparison.
-Dave
> -Original Message-
> From: Ted Lemon [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 23, 2008 2:43 PM
> To: Dave Thaler
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] prac
> -Original Message-
> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2008 1:13 AM
> To: Dave Thaler
> Cc: marcelo bagnulo braun; int-area@ietf.org; Dan Wing; Jari Arkko;
> Philip Matthews; Brian E Carpenter; Alberto García
> Subject:
As far as I know, it is not an IANA-maintained registry.
The numbering space can only be extended by RFC.
-Dave
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Jari Arkko
> Sent: Monday, October 20, 2008 3:22 PM
> To: Internet Area
> Subject: [Int-a
Yeah they may be keeping track, but as noted there, there's nowhere that
authorizes IANA to assign any numbers.
-Dave
> -Original Message-
> From: Jari Arkko [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 20, 2008 3:42 PM
> To: Dave Thaler
> Cc: Internet Area
>
It's been pointed out several times in the past regarding class E
space that you cannot expect a host/app to work if you try to give
it a class E address.
So class E addresses can only be safely used in networks for which
you have complete control/confidence over all the devices/apps
in that netwo
Re
"Requests for new ar$op values are made through IETF Review or IESG
Approval"
Who decides which of these two is required? I assume it's the IESG,
but would be good to clarify.
Otherwise, looks ok to me.
-Dave
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] O
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Akira Nakagawa
> Sent: Monday, December 01, 2008 6:45 PM
> To: int-area@ietf.org
> Subject: [Int-area] ISP Shared Address QA
>
>
> All,
>
> This is Akira Nakagawa, Tokyo.
>
> Thank you very much for givi
Below with [DT]
-Original Message-
From: Marc Blanchet [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 6:41 AM
To: Dave Thaler
Cc: [EMAIL PROTECTED]; int-area@ietf.org
Subject: Re: [Int-area] ISP Shared Address QA
Dave Thaler a écrit :
>> -Original Message-
&
Joe Touch wrote:
> > I think it is clear that there are several hard questions in this
> space,
> > and we simply do not know whether, e.g., some of the mapping ideas
> > actually work well in real life. My belief is that finding out
> requires
> > not just implementation, but also well planned tri
> Some routers enable 6to4 [RFC3056] on their WAN link. 6to4 requires a
> publicly-routable IPv4 address. Enabling 6to4 behind a NAT causes a
> disconnected IPv6 island."
The last sentence above is incorrect. The second sentence is correct.
So one cannot "enable" 6to4 behind a NAT since one has
> -Original Message-
> From: Dan Wing [mailto:dw...@cisco.com]
> Sent: Monday, June 14, 2010 12:48 PM
> To: 'Templin, Fred L'; Dave Thaler; 'Matthew Ford'
> Cc: int-area@ietf.org; 'Brian E Carpenter'; draft-ford-shared-addressing-
> iss...
> -Original Message-
> From: Dan Wing [mailto:dw...@cisco.com]
> Sent: Monday, June 14, 2010 12:17 PM
> To: Dave Thaler; 'Matthew Ford'
> Cc: int-area@ietf.org; 'Brian E Carpenter'; draft-ford-shared-addressing-
> iss...@tools.ietf.org; 'Lorenzo
> -Original Message-
> From: Dan Wing [mailto:dw...@cisco.com]
> Sent: Monday, June 14, 2010 1:16 PM
> To: 'Bernard Aboba'; Dave Thaler; f...@isoc.org
> Cc: int-area@ietf.org; brian.e.carpen...@gmail.com; draft-ford-shared-
> addressing-iss...@tools.ietf.org;
--Original Message-
> From: Dan Wing [mailto:dw...@cisco.com]
> Sent: Monday, June 14, 2010 1:45 PM
> To: Dave Thaler; 'Bernard Aboba'; f...@isoc.org
> Cc: int-area@ietf.org; brian.e.carpen...@gmail.com; draft-ford-shared-
> addressing-iss...@tools.ietf.org; lore...@g
ublic IPv4 address is given to
multiple devices
(which changes the IP model in ways I warned about in the port restricted IP
issues doc)
then the standard "6to4" will break.
-Dave
From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Thursday, June 17, 2010 5:38 PM
To: Dave Thaler
Cc
Also related is DSTM
http://tools.ietf.org/html/draft-bound-dstm-exp-04
-Dave
-Original Message-
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of
CAUCHIE Grégory
Sent: Wednesday, June 15, 2011 6:17 AM
To: k.fleischha...@telekom.de
Cc: int-area@ietf.org
Subj
Mark Townsley wrote:
[...]
> Applications may not be all that forgiving to IPv4 coming and going either,
> e.g.,
> I have a popular mail client that has recently taken to crashing when I switch
> from wired to wireless and get a different IP address in the process. Some of
> the IM connections I k
, 2011 10:31 AM
> To: Cameron Byrne; Dave Thaler
> Cc: ppp...@ietf.org; int-area@ietf.org
> Subject: RE: [Int-area] IETF80 questions regarding "On demand IPv4 address
> provisioning in Dual-Stack PPP deployment" - Topic for WG?
>
> I'll second this. Most of the new
Putting on the list a comment I made in the meeting, and adding more info too...
Section 2 says:
> The REQUESTED port may be used as a source port if the application
> exclusively uses multicast messages. If any application messages are
> unicast, then a dynamic port should be used as the source p
38 matches
Mail list logo
