[Int-area] Re: [EXTERNAL] Re: Re: IP Parcels and Advanced Jumbos (AJs)

On 27-Sep-24 08:42, Templin (US), Fred L wrote: Hi Brian, -Original Message- From: Brian E Carpenter Sent: Thursday, September 26, 2024 1:22 PM To: Templin (US), Fred L ; Tom Herbert ; Tim Chown Cc: Internet Area ; IPv6 List Subject: Re: [Int-area] Re: IP Parcels and Advanced

[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

On 27-Sep-24 05:56, Templin (US), Fred L wrote: Hi Tom, I would like to gently suggest a new terminology. Rather than calling them "the multi-segment buffers managed by GSO and GRO", can we begin calling them "parcel buffers" or simply "parcels"? Not suggesting this in a self-serving manner -

Re: [Int-area] ICMP extension for node ID updated [draft-fenner-intarea-extended-icmp-hostid-01]

iff?doc_1=draft-fenner-intarea-extended-icmp-hostid&url_2=https://fenner.github.io/icmp-node-id/draft-fenner-intarea-extended-icmp-hostid.txt> shows the diff that I've made - so this document no longer talks about interface names except in the references to rfc5837.   Bill On

Re: [Int-area] ICMP extension for node ID updated [draft-fenner-intarea-extended-icmp-hostid-01]

Bill, et al, Re: "The interface name MUST be represented in the UTF-8 charset [RFC3629] using the Default Language [RFC2277]." draft-carpenter-6man-zone-ui is wending its way in 6man, and it's been suggested that we should clarify the allowed character set for RFC4007 zone identifiers, which a

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

On 23-Mar-24 03:40, Robinson, Herbie wrote: Legitimate reasons for a middle box to look at transport headers: Firewalls need to look at port numbers to perform their quite necessary job. Steve Bellovin pointed out in 1999 that such firewalls should be in the destination host**. That works ver

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

epted the limited domain model, which many in the IETF consider heresy. Brian Tom Fred -----Original Message- From: Int-area On Behalf Of Brian E Carpenter Sent: Thursday, March 21, 2024 11:59 AM To: int-area@ietf.org Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notifica

Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt

On 22-Mar-24 03:53, Robinson, Herbie wrote: I would say that, in theory, that’s not a show stopper, but in practice it is a lot of work to implement – enough to suggest that you wouldn’t get enough implementations to make it useable. I'll say it because nobody else has (recently). Why should

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

On 21-Mar-24 17:52, Tom Herbert wrote: On Wed, Mar 20, 2024 at 9:35 PM Toerless Eckert wrote: On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote: In other words, Destination Option Headers do not have fundamentally distinct processing requirements on the destination host examining it

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

On 21-Mar-24 17:20, Tom Herbert wrote: On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert wrote: Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet Protocol Number being an "IPv6 Extension Header" or not, the answer was that in his interpretation it is simply whether the h

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

raffic without any kind of DPI, exactly as a new Ethertype would. Regards Brian -- tony On Fri, Mar 31, 2023 at 9:00 PM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote: On 01-Apr-23 06:18, Ron Bonica wrote: > On second thought, if we had the new ethertype,

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

On 01-Apr-23 06:18, Ron Bonica wrote: On second thought, if we had the new ethertype, we wouldn’t need the new /16! They serve the same function However, a new special-purpose prefix is rather trivial to deploy compared with a new Ethertype. Brian  

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

On 30-Mar-23 21:00, Tony Przygienda wrote: +1 Joel AFAIS it's same effort to upgrade something to process SRH or to process new ethertype properly. And in a sense upgrade to something that drops ether type SRv6 if it's not supposed to be processed is no upgrade today, routers as per today will

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

Robert, On 30-Mar-23 01:10, Robert Raszuk wrote: Nope, that is completely not what I have in mind, Please remember that transit nodes are not SRv6 aware in closed or open domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink Only if the SRv6-carrying IPv6 packet is encapsu

Re: [Int-area] Jumbograms [was: Call for WG adoption of draft-templin-intarea-parcels-10]

clarification on RFC 2365 that it has been implemented for very specialized environments. I agree it does no harm to anyone who doesn’t use it. What is the application where it was implemented if you have a link would be greatly appreciated. Thanks Gyan On Sun, Jul 3, 2022 at 1:08 AM Brian E

[Int-area] Jumbograms [was: Call for WG adoption of draft-templin-intarea-parcels-10]

Hi Gyan, On 03-Jul-22 16:25, Gyan Mishra wrote: ... So bottom line is RFC 2675 would never come to fruition and should really be deprecated or made obsolete. Why? Firstly, it has come to fruition, as an earlier message in this thread said. Secondly, it was intentionally designed for very spe

Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic

Toerless, I've seen no evidence that nsap.int is used by anyone anywhere for anything. If there was any use for it, I'm sure it would have been migrated to nsap.arpa a long time ago. Regards Brian On 07-Apr-22 21:38, Toerless Eckert wrote: [ Disclaimer: Cc some more mailing list in the hop

Re: [Int-area] New draft: The IETF Will Continue Maintaining IPv4 (draft-schoen-intarea-ietf-maintaining-ipv4)

Hi, Please let us know if you have any questions after reading the draft. I have no questions. IMHO the draft is unnecessary and potentially harmful. It's a matter of common sense that the IETF will fix things that *need* fixing, even if they are specific to IPv4. It's a matter of fact that I

Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Toerless, I believe the closest we ever got to agreed definitions was in the IRTF RFC 6115: 6. A "locator" is a structured topology-dependent name that is not used for node identification and is not a path. Two related meanings are current, depending on the class of things

Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

On 26-Jan-22 08:30, Geoff Huston wrote: ... Tom, I think you may have missed my initial characterisation of IP addresses in your response: "we treat addresses as no more than temporary ephemeral _session_ tokens” i.e. the NAT model relies on session level stability of the NAT association. Ri

Re: [Int-area] Where/How is the features innovation happening?

On 20-Dec-21 22:35, Dirk Trossen wrote: Jumping into this late (due to a few days off), see inline. -Original Message- From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: 18 December 2021 20:51 To: Stewart Bryant ; Geoff Huston Cc: Int-area@ietf.org

Re: [Int-area] Where/How is the features innovation happening?

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 me

Re: [Int-area] Where/How is the features innovation happening?

On 18-Dec-21 23:00, Stewart Bryant wrote: ... What is important is that we play the cards we are dealt not the ones we were dealt in the last game. In other words we need to design for the Internet as it will be, not the Internet we designed before and not the Internet that we would wish for

Re: [Int-area] Where/How is the features innovation happening?

t 11:46 AM, Brian E Carpenter wrote: On 18-Dec-21 07:48, Geoff Huston wrote: ... So, to repurpose some graffiti from the 1970’s, we need globally unique addresses like fish need bicycles! :-) They have residual value for surveillance and possibly other forensic uses, which may of course be active

Re: [Int-area] Where/How is the features innovation happening?

On 18-Dec-21 07:48, Geoff Huston wrote: ... So, to repurpose some graffiti from the 1970’s, we need globally unique addresses like fish need bicycles! :-) They have residual value for surveillance and possibly other forensic uses, which may of course be actively harmful to the user. But on t

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

On 08-Dec-21 05:30, to...@strayalpha.com wrote: ... But you make another point which is pretty fundamental and foundational. Should data links be MTU-less, so to speak? And can they really do that. I won't hold my breath. I don’t know yet, but I do know that’s what I *want* and why it’s diffe

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

On 07-Dec-21 12:06, Tom Herbert wrote: On Mon, Dec 6, 2021 at 1:52 PM Dino Farinacci wrote: Last email was the main point I wants to get across. Now to answer your questions inline. On Dec 6, 2021, at 4:28 AM, Luigi Iannone wrote: Having said that, this is not caused by addressing itself,

Re: [Int-area] Expanding Assignable IPv4 Public Address Re: 202112030945.AYC

Abe mentions "more efficient and productive use of our resources" and I think we all wish for that. I think this WG should discuss the general question whether the minor wastage of IPv4 address space that this set of drafts addresses is an efficient and productive use of our resources. In othe

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

On 03-Dec-21 11:17, Dino Farinacci wrote: You missed the point maybe. Common functions should be performed at the waist so applications don’t have to duplicate functionality. Hmm. Logic compels me to offer an alternative: Common functions should be performed by a shared library so applications

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

On 14-Aug-21 06:49, Seth David Schoen wrote: > Carsten Bormann wrote: ... >> a cost that is better invested in accelerating the migration to IPv6. > > IETF could deny the community a forum in which to form a consensus > about how IPv4 can usefully evolve. "The IAB expects that the IETF will st

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

> My understanding is that IETF's role is as a > steward of network-wide value, which is why I thought this might > interest IETF. Not quite. The mission is "to make the Internet work better" and affecting the sales value of 32 bit numbers is not really the same thing, especially since 128 bit num

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

> As we > will describe in more detail in future posts, we expect these changes will > create enormous economic value, and they are not intended as an attack on > the IPv6 transition. Most of the consolidation of IPv4 usage by ISPs in recent years has been in the deployment of CGNs and aggressive

Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

), UCAM-CL-TR-849, ISSN 1476-2986. Regards Brian Carpenter On 14-Jul-21 10:25, Brian E Carpenter wrote: > On 13-Jul-21 17:57, Stewart Bryant wrote: >> An interesting draft Toerless. >> >> From a background POV it is worth noting ISO 8473 which is in deployment >> with

Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

On 13-Jul-21 17:57, Stewart Bryant wrote: > An interesting draft Toerless. > > From a background POV it is worth noting ISO 8473 which is in deployment with > multi-type variable length address. Pretty ugly and limited though, and as I understand it the major (unclassified) deployment, in the a

Re: [Int-area] I-D Action: draft-eckert-intarea-functional-addr-internets-00.txt

Hi all, I think there's a case to be made that layer 3 itself is the problem, not the details of an addressing scheme [1]. (That reference predated QUIC, but I think the main conclusions stand.) A more radical solution like NDN [2] may be needed. [1] https://doi.org/10.1145/2602204.2602215, a.k

[Int-area] Fwd: I-D Action: draft-carpenter-6man-rfc6874bis-01.txt

FYI, this will be discussed in 6MAN but may be of wider interest. It will also be mentioned in the ART Area meeting, and of course there needs to be some external liaison too. Brian Carpenter & Bob Hinden Forwarded Message Subject: I-D Action: draft-carpenter-6man-rfc6874bi

Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

Alexander, As the tracker shows, that RFC was published in the Independent Submission stream, not the IETF stream. There are indeed many cases of non-IETF protocols being published as Informational RFCs, but today that would always be in the Independent stream. The "status of this memo" section

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

On 25-Mar-21 03:41, Joseph Touch wrote: >> On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, > <mailto:vasilenko.edu...@huawei.com> <mailto:vasilenko.edu...@huawei.com>> >> wrote: > ... >> On Mar 23, 2021, at 8:47 PM, Brian E Carpenter > <mailto:brian

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

On 24-Mar-21 10:27, Mark Smith wrote: > > > On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, > wrote: > > Hi Joseph, > > __ __ > > Currently, vendors have chosen some undisclosed big numbers for the > reassembly buffer on the tunnel interface__

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

On 24-Mar-21 09:52, Vasilenko Eduard wrote: > The terms “source node” and “destination node” are used in RFC8200 but not > defined in Sec 2. They are clearly hosts that originate IPv6 packets and > hosts that consume IPv6 packets, respectively. In fact "destination node" is more than that, sinc

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

On 23-Mar-21 08:32, Vasilenko Eduard wrote: ... > What to do if one could not push the traffic source to decrease MTU because > it is already 1280 (minimum)? Nothing. Any tunnel MUST do whatever it has to do to carry a 1280 byte packet. That is by definition always the tunnel's problem and never

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

On 02-Mar-21 22:20, Toerless Eckert wrote: > Hi Brian, > > On Tue, Mar 02, 2021 at 09:08:10AM +1300, Brian E Carpenter wrote: >> There is work on supporting shorter address lengths in limited domains where >> that is sufficient. I don't think we have a viab

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

On 03-Mar-21 01:32, Stewart Bryant wrote: > > >> On 1 Mar 2021, at 20:08, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote: >> >> >> It would take but a minute to design a longer-address mechanism for IPv6, >> although I don't

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

Hi Toerless, On 02-Mar-21 04:33, Toerless Eckert wrote: > It is somewhat ironic to see how it was IP and IPv6 that where the protocols > that where > successfully enhanced with additional adress semantics not considered when > they where designed > (ok, at last IPv4, but arguably also in a more s

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

PM, Erik Kline > <mailto:e...@loon.com>> wrote: >> >> There's also the matter of whether allocating 114 for this doc would >> establish a precedent. >> >> On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>&

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

On 21-Sep-19 14:11, Joe Touch wrote: > FWIW, there are many registries with such “dead” entries. 114 is a bit special. By definition, all our normal traffic monitoring techniques will *never* see protocol 114 unless by chance they are installed on a layer 2 segment where it is in use. So even if

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

On 12-Sep-19 10:59, Bob Hinden wrote: > Fred, > >> On Sep 11, 2019, at 7:48 AM, Templin (US), Fred L >> wrote: >> >> Geoff, the 1280 MTU came from Steve Deering's November 13, 1997 proposal to >> the ipngwg. The exact message from the ipng archives is reproduced below. >> >> 1280 isn't just a re

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 09-Sep-19 16:11, Joe Touch wrote: > > >> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote: >> >> On 09-Sep-19 12:15, Joe Touch wrote: >>> >>> >>>> On Sep 8, 2019, at

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 09-Sep-19 12:15, Joe Touch wrote: > > >> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote: >> >>>> >>>> Wouldn't that require the middle box to become an architectural element? >>>

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 09-Sep-19 06:06, Joe Touch wrote: > > >> On Sep 8, 2019, at 6:16 AM, Fred Baker > > wrote: >> >> >> >>> On Sep 5, 2019, at 5:31 PM, Tom Herbert >> > wrote: >>> >>> I really wish the IAB would look at the issues of wide >>> spread mi

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

; doesn't exactly resolve Alissa's issue, I think it makes it clear that relying on fragmentation is a risky choice, whereas the MAY formulation makes it seem almost OK. Brian > > Yours, > Joel > > On 8/6/2019 8:55 PM, Brian E Carpenter wrote: >> On 07-Aug-19 12

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

On 07-Aug-19 12:11, Alissa Cooper wrote: > Hi Tom, > >> On Aug 6, 2019, at 5:41 PM, Tom Herbert wrote: >> >> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker >> wrote: >>> >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-intarea-frag-fragile-15: Discuss

[Int-area] Fwd: ID Tracker Stream Change Notice:

Hi, Since the Limited Domains draft has been discussed on this list, this is to let you know that we've now submitted it for publication as an Independent Submission RFC. Feedback is of course still very welcome. Regards Brian & Bing Forwarded Message Subject: ID Track

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-08.txt

Hi, We've updated this draft according to comments received. At the moment the authors plan to submit it to the Independent Submissions RFC stream. If anybody thinks it should be an IETF stream document, please let us know. Regards Brian & Bing Forwarded Message Subject: I

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt

Hi, Another update following recent comments. The main changes were moving the taxonomy to an appendix, some new examples, and editorial improvements. Please send any new comments that you may have. At the moment the authors plan to submit this draft soon to the Independent Submissions stream, bu

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

On 06-Mar-19 05:42, Tom Herbert wrote: > Hi Brian, > > On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter > wrote: >> >> Hi, >> > Hi Brian, > > Thanks for the comments! > >> This is an interesting draft, but I must say I have serious doubts about

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

On 06-Mar-19 04:55, Tom Herbert wrote: > On Tue, Mar 5, 2019 at 2:30 AM Stewart Bryant > wrote: >> >> >> On 05/03/2019 01:37, Brian E Carpenter wrote: >>> Hi, >>> >>> This is an interesting draft, but I must say I have serious doubts about >

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

Hi, This is an interesting draft, but I must say I have serious doubts about the IETF working on any significant update to IPv4 at the IP header level, or of any such updates ever making it into the operational network. On the other hand, I think the idea of a UDP encapsulation of extension heade

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

On 03-Mar-19 09:35, Tom Herbert wrote: > On Sat, Mar 2, 2019 at 11:50 AM Brian E Carpenter > wrote: >> >> On 03-Mar-19 06:35, Tom Herbert wrote: >>> On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter >>> wrote: >>>> >>>> On 02-Mar-

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

On 03-Mar-19 06:35, Tom Herbert wrote: > On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter > wrote: >> >> On 02-Mar-19 14:46, Tom Herbert wrote: >>> Hi Brain, >>> >>> One comment... >>> >>> >From the draft: >>> >>

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

ctively a domain split into various parts without needing a traditional VPN. Of course, there remains the bogeyman of making the Internet transparent to some new unknown option or extension header. I'm pessimistic about that. So far we have had poor success. Brian > > Thanks, >

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

A few small updates and fixes to references. Please comment; the authors are wondering about next steps for this draft. Brian + Bing Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-06.txt Date: Fri, 01 Mar 2019 17:04:37 -0800 From: internet-dra...@ietf

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

d, 30 Jan 2019 08:40:39 +1300 >> From: Brian E Carpenter >> To: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: >> draft-ietf-intarea-frag-fragile-06.txt >> Message-ID: <7bc33271-8cee-818a-036b-99d92d818...@gmail.com> >> Content-Type: text/plai

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

On 2019-01-31 03:13, Stewart Bryant wrote: >>> Add to section 7.3: >>> >>> "Routers SHOULD use IPv6 flow label for ECMP routing as described in >>> [RFC6438]." > > If we want to migrate to the FL then we really need to state that the FL MUST > be set by the sender. Without, that we are nev

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

Reviewing this version, I noticed the absence of one mitigation that we should probably be recommending. - in section 4.4. "Stateless Load Balancers" add the remark that balancers that use *only* the IPv6 Source Address, IPv6 Destination Address and IPv6 Flow Label (when it is non-zero) work pe

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

On 2019-01-15 11:04, Tom Herbert wrote: > Hello. I have a couple of comments: > >>From the draft: > "Middle boxes SHOULD process IP fragments in a manner that is > compliant with RFC 791 and RFC 8200. In many cases, middle boxes must > maintain state in order to achieve this goal." > > This requ

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-05.txt

An update following recent comments: Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-05.txt Date: Wed, 12 Dec 2018 11:26:16 -0800 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available

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

Hi, > 7.1. For Application Developers > >Protocol developers SHOULD NOT develop new protocols that rely on IP >fragmentation. However, they MAY develop new protocols that rely on >IP fragmentation when no viable alternative exists. > >Legacy protocols that depend upon IP fragme

Re: [Int-area] Stateless devices and IP fragmentation

behavior is acceptable to another network operator. Middle box vendors MUST > provide network operators with all of the information required to make > intelligent middle box deployment decisions. > >> -Original Message- >> From: Brian E Carpenter >> Sent: T

Re: [Int-area] Stateless devices and IP fragmentation

> These stateless middle boxes may perform > sub-optimally or process IP fragments in a manner that is not compliant with > RFC 791 or RFC 8200. That seems to skirt round the real concern. Middleboxes don't exist in the world assumed by RFC 791 or 8200, so those RFCs don't place any compliance re

Re: [Int-area] About limited domains (2)

On 2018-11-16 08:41, Tom Herbert wrote: > On Mon, Nov 12, 2018 at 4:22 PM Brian E Carpenter > wrote: >> >> Quoting the minutes on draft-carpenter-limited-domains-04: >> >>> RV: The hints that I'm hearing are that if you have well structured systems &g

Re: [Int-area] Stateless devices and IP fragmentation

On 2018-11-15 10:54, Tom Herbert wrote: > On Wed, Nov 14, 2018 at 1:25 PM, Brian E Carpenter > wrote: >> On 2018-11-15 10:02, Tom Herbert wrote: >>> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote: >>>> Tom, >>>> >>>> Please look inl

Re: [Int-area] Stateless devices and IP fragmentation

On 2018-11-15 10:02, Tom Herbert wrote: > On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica wrote: >> Tom, >> >> Please look inline for a little compromise and a little pushback. I hope >> that we can reach consensus in this round. >> >> Ron >> >> >>> -

Re: [Int-area] Stateless devices and IP fragmentation

On 2018-11-15 09:31, Ole Troan wrote: > Tom, > >> I don't believe this can be true. Not all protocols even have port >> numbers (e.g. ICMP, ESP) and yet we still expect them to be >> deliverable. Maybe your referring to ECMP, which does route based on >> flow (e.g. port information)? But, ECMP is

Re: [Int-area] Stateless devices and IP fragmentation

On 2018-11-13 13:27, Tom Herbert wrote: > On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote: >> Tom, >> >> OK. Let's see if the following text works any better for you. >> >> Ron >> >> 7.1. For Protocol Developers >> >>Protocol deve

[Int-area] About limited domains (2)

Quoting the minutes on draft-carpenter-limited-domains-04: > RV: The hints that I'm hearing are that if you have well structured systems > there are infinite ways to break the structure. If one allows people in the > wild to > do whatever they want, you get trends like this. It's not a trend you

[Int-area] About limited domains

Quoting the minutes on draft-carpenter-limited-domains-04: > EK: This looks like a way to get execptions for things you otherwise wouldn't > be allowed to do. Sometimes things jump domains. I don't think I agree > philiosophically that this is > a good idea. Unfortunately I wasn't on meetecho

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

On 2018-10-16 11:26, Tom Herbert wrote: > > > On Mon, Oct 15, 2018, 3:11 PM Fred Baker > wrote: > > > > > On Oct 15, 2018, at 1:50 PM, Ron Bonica > wrote: > > > > Exactly, but I didn't want to introduce and define the t

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

On 2018-10-16 09:35, Ron Bonica wrote: > Hi Tom, > > The examples in Sections 4.1-4.4 all refer to stateless devices. The problem > could be solved by making them all stateful. However, that may not be > practical because of: > > - price/performance concerns > - size of the installed base. > >

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-04.txt

Hi, We have significantly updated this draft, with some reorganization of existing material, and two new sections added: 6. The Scope of Protocols in Limited Domains 7. Functional Requirements of Limited Domains We suggest discussion on the int-area@ietf.org list. Brian + Bing Forw

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

Just picking on one part of Tom's excellent note: On 2018-09-13 11:14, Tom Herbert wrote: > IMO, IETF's strength and advantage is that it focuses on standardizing > protocols without standardizing network architecture. This provides > all the necessary freedom for to build networks as appropr

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

et protocols. I guess the > consequences of this is that if someone defines a protocol that only > operates in a limited domain, then the limited domain itself needs to > be clearly defined in normative language. I'd go a bit further - I think we need to standardize the mechanism

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

pecific >> layer 2 technologies will be developped to manage more Limited Domains, >> which will all need to be connected to the Internet in one way or another. >> >> At first, the connection to the Internet will be with a Gateway, and only >> then IP wi

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

New version, with a first draft of a taxonomy added. Discussion welcome. Brian + Bing Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-03.txt Date: Tue, 11 Sep 2018 20:18:56 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Getting back to the draft under discussion: On 2018-08-17 05:56, Tom Herbert wrote: > The requirement that "Protocols/applications SHOULD avoid IP level > fragmentation." already acknowledges and provides advice on the > realities of the current state of fragmentation support in the > network.

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Hi, Earlier I said: >>Application developers SHOULD NOT develop applications that rely on >>IPv6 fragmentation > > It isn't obvious to me that this is an algorithmic requirement. If the > application > runs over TCP, how does the developer ensure that TCP will use an MSS that > avoids t

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

Tom, Thanks for the comments. See in-line: On 15/08/2018 12:00, Tom Herbert wrote: > On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter >> > Hi Brian, thanks for the draft. > > A couple general points: > > * It's unclear to me what it means for a protoco

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

Updated following comments received at IETF102. Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-02.txt Date: Mon, 13 Aug 2018 18:42:27 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft i

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 01/08/2018 11:29, Tom Herbert wrote: > On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan wrote: >> Tom, >> >>> How is this story going to be different for IPv6? How do we ensure that >>> non-conformant implementation for IPv4 isn't just carried over so that >>> fragmentation, alternative protocols,

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

> The fallback is to only hash over addresses. Hashing over addresses+flow-label is fine too. If the flow label is zero, it's the same thing. If the flow label is set properly, it's a better hash. I believe this is covered in the various relevant RFCs already (6437, 6438 and 7098). Regards Br

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 28/07/2018 08:28, Ole Troan wrote: > > >> On 27 Jul 2018, at 22:12, Brian E Carpenter >> wrote: >> >> Fragmentation, (PL)PMTUD, extension headers, and innovative >> L4 protocols are very possibly not viable on the open Internet. >> At least, we can

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 28/07/2018 04:25, Fernando Gont wrote: > On 07/27/2018 05:15 PM, Tom Herbert wrote: >> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote: >> So has the ship sailed for out ability to ever use >> extension headers or any protocol other than TCP (and sometimes UDP)? > > It would seem th

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

+1 for adoption. However, I am a bit concerned about this key recommendation: >Application developers SHOULD NOT develop applications that rely on >IPv6 fragmentation It isn't obvious to me that this is an algorithmic requirement. If the application runs over TCP, how does the developer

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

On 25/07/2018 11:46, Tom Herbert wrote: > On Tue, Jul 24, 2018 at 3:54 PM, Templin (US), Fred L > wrote: >> I have an observation that I would like to see addressed in the document. >> Some applications >> (e.g., 'iperf3' and others) actually leverage IP fragmentation to achieve >> higher data r

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-01.txt

Hi, We've requested a short slot in the Intarea meeting for this draft. The topic is quite general but we think that Intarea is a good place to evaluate community interest. Brian + Sheng Forwarded Message Subject: I-D Action: draft-carpenter-limited-domains-01.txt Date: Sat,

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 12/05/2018 01:55, Joe Touch wrote: > Whether 6302 makes a strong recommendation or not, it is clearly aimed at > policy issues. > > I don’t think we need documents to explain how to implement software that > isn’t focused on supporting the protocols we specify. > > I prefer to have 6302 depr

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Joe, On 10/05/2018 03:02, Joe Touch wrote: > > >> >> From: Int-area > > on behalf of >> "mohamed.boucad...@orange.com " >> mailto:mohamed.boucad...@orange.com>> >> Date: Wednesday, May 9, 2018 at 7:26 AM >> To: Juan Carlos Z

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 02/05/2018 04:36, Dave O'Reilly wrote: > The IETF has a role in the governance of the Internet, That's news to me. I've never been completely sure what "governance of the Internet" actually means**, but in any case it isn't mentioned in the mission statement at https://tools.ietf.org/html

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 27/04/2018 21:15, Amelia Andersdotter wrote: > On 2018-04-27 04:00, Brian E Carpenter wrote: > i would have been slightly less annoyed had this not been the case. For > this reason: > >> This is not an area where anybody in authority gives a fig about what >> the

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On 27/04/2018 09:09, Amelia Andersdotter wrote: > On 2018-04-26 17:41, Dave O'Reilly wrote: >> As I mentioned yesterday, I think you are misrepresenting the scope of the >> ECJ judgement. >> >> > what it boils down to is that the extensive, long-term logging side of > the argument lost (legally a

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

(Bundling answers to two messages) On 26/04/2018 20:40, Dave O'Reilly wrote: ... >> IMHO we should say nothing that appears to be a recommendation >> about the duration of logging. We can say as a factual matter that >> logging is useful for operational purposes (fault diagnosis, abuse >> detection

  1   2   3   >