Re: [Int-area] Fw: IPv10, KRP (RRP) IDs.

You probably want to read the RFCs and NOTE WELL about contributions to the IETF. On 6 June 2017 at 00:10, Khaled Omar wrote: > > > Original Message > Subject: IPv10, KRP (RRP) IDs. > From: Khaled Omar > To: ietf > CC: > > > Hi everyone, > > I still didn't get any response from

Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

Ron, Related to this section, at the mic I was suggesting perhaps including some simple text recommending that network operators SHOULD take efforts to make sure the MTU(s) on their network(s) are "fit for purpose", i.e. sized to avoid fragmentation to the extent possible. I'm not sure yet how to

Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

I think in that case it's just ensuring the MTU given to the customer via their access link can be carried through their network without, or which a minimum of, fragmentation. I finally found some text to which I was referred, in 3GPP TS 29.060 (GTP) v15.2.0 section 13.2: All backbone links s

Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

> Most network providers abide by the policy that you describe. If all of their > interior links support an MTU of N, their access links support an MTU of N > minus M, where M is the highest possible encapsulation overhead. Ah, well, if they already do this then perhaps there doesn't need to be

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

Where do they want to use this, and why not request a new protocol value? (What did i...@iana.org say?) On Thu, 19 Sep 2019 at 08:07, Eric Vyncke (evyncke) wrote: > The authors of https://tools.ietf.org/id/draft-zhu-intarea-gma-03.txt > would like to use IP protocol 114 as it is described as “A

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

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 wrote: > 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

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

> > It may be folly to try to modify IPv4 implementations at this point. I > have no objections if you wish to try pushing this big rock up hill, but I > doubt you will be successful. > BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation? In other words, if some box "decided

Re: [Int-area] GPS over wifi for underground locations -- submitted draft RFC.

Rob, As you may well know there was once a working group (geopriv ) where many similar topics were discussed. That's concluded now, but I wonder if your document would be more appropriate for consideration in artarea or even gendispatch. On Mon, Ja

Re: [Int-area] GPS over wifi for underground locations -- submitted draft RFC.

he ART area on this type of work. >> >> Regards, >> Brian >> >> On 1/20/20 4:01 PM, Erik Kline wrote: >> > Rob, >> > >> > As you may well know there was once a working group (geopriv >> > <https://datatracker.ietf.org/wg/geopriv/about/&

Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

Iain, Overall, LGTM. Questions and notes: [ section 3.2 ] * Does "IPENC" need to be officially recorded in an official registry somewhere? Or has this already been done and a link to it can be included in this draft? I wasn't able to find this word in the APRS PDF linked to in the references.

Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

On Sat, May 23, 2020 at 2:24 PM Erik Kline wrote: > > Iain, > > Overall, LGTM. > > Questions and notes: > > [ section 3.2 ] > > * Does "IPENC" need to be officially recorded in an official registry > somewhere? Or has this already been done and a link t

Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

> >> [ section 5 ] > >> > >> * Can you explain more about the limitations on non-NULL encryption? > >> > >> My intuition would be that ESP with non-NULL encryption provides > >> privacy only on the IP links between tunnel endpoints. A packet that > >> failed to decrypt properly would not be transm

Re: [Int-area] IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

I concur with Nick Hilliard's comments on the v6ops thread: I really think you should have a sample implementation. A github repo with Linux kernel patches and some client and server apps that actually cause IPv10 packets to be sent on the wire would be a good starting point. Patches for tcpdump/

Re: [Int-area] Still need to know what has changed.... Re: IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

As noted before: RFCs 6052, 6146, 6147, 6877, 7915, and others comprise the solution deployed to literally hundreds of millions if not billions of mobile devices and numerous access networks worldwide. On Fri, Sep 18, 2020 at 5:24 AM Khaled Omar wrote: > >> Who are these “many people”, and what

Re: [Int-area] Still need to know what has changed.... Re: IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

On Sat, Sep 19, 2020 at 4:18 PM Khaled Omar wrote: > But none of these transitioning solutions are widely deployed, maybe it is > IPv10 time ;-) > False. > > > Khaled Omar > > > > *From:* Erik Kline > *Sent:* Sunday, September 20, 2020 1:05 AM > *To:* Kh

Re: [Int-area] [v6ops] Still need to know what has changed.... Re: IPv10 draft (was Re: FW: v6ops - New Meeting Session Request for IETF 109 - IPv10)

https://www.worldipv6launch.org/measurements/ has some aggregated statistics. On Fri, Sep 25, 2020 at 2:19 PM Khaled Omar wrote: > I agree, but where we can found a live statistics other than Google to > keep tracking? > > Khaled Omar > > -Original Message- > From: Fred Baker > Sent: Fr

Re: [Int-area] MCP Hint Option

Herbie, Out of curiosity, can you explain more about what this sentence means: """ Note that RFC8200 [RFC8200] requires that per fragment destination headers to be followed by a routing header. """ The way I read this sentence doesn't exactly agree with my understanding of 8200. Thanks, -

Re: [Int-area] [Technical Errata Reported] RFC8117 (7072)

RFC Editor, Please delete as junk. Thank you. On Fri, Aug 5, 2022 at 5:21 PM RFC Errata System wrote: > The following errata report has been submitted for RFC8117, > "Current Hostname Practice Considered Harmful". > > -- > You may review the report below and

Re: [Int-area] Call for Adoption - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters draft

+1 to adoption. updates for things like the SLAP changes alone are well worth having documented. On Wed, Aug 31, 2022 at 10:42 AM Juan Carlos Zuniga (juzuniga) wrote: > Dear IntArea WG, > > > > We are starting a 2-week call for adoption of *IANA Considerations and > IETF Protocol and Document

Re: [Int-area] Lan FQDN dynamic resolution via ARP

I think you'll find this issue essentially solved with RFC 6762 and 6763. Cheers, -ek On Sun, Nov 27, 2022 at 11:00 PM Salim-amine Bou Aram < salimbouara...@gmail.com> wrote: > Hello dears, > Hope you are doing well and sorry for bothering. I've an idea to enhance > the ARP protocol by adding

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

Poking around the Linux kernel source, my reading of net/ipv6/icmp.c's icmpv6_rcv() is that it checks the type byte before dispatching to icmpv6_echo_reply(), and inside icmpv6_echo_reply() I'm not seeing any checking of the code byte, so I'd assume (without testing) that it just constructs a norma

Re: [Int-area] draft-pauly-intarea-proxy-config-pvd-00

Looks like an interesting proposal, and it raised an interesting point: that proxies can be provisioning domains unto themselves (this hadn't exactly occurred to me before, but makes sense). Looking forward to more discussion. Thanks, -ek On Wed, Jun 28, 2023 at 1:42 PM Tommy Pauly wrote: >

Re: [Int-area] Fw: New Version Notification for draft-bi-intarea-savi-wlan-01.txt

+6MAN I think Section 7 paragraph 2 should reference RFC 7934 and perhaps reframe the "limits" text in some way mindful of that BCP's sections 7 and 8. Thanks, -ek On Wed, Jul 5, 2023 at 5:25 AM Lin He wrote: > > Hi, all. > > We have updated the savi-wlan draft. The main changes are as follows

Re: [Int-area] [v6ops] End-to-end "address transparency"

> I believe you are talking about my original mechanism for load balancing, > which was to utilize routing protocols on the servers to announce to the > router that a server was available. In general principle, it was effective, > but only on a per flow basis (standard flow based balancing of route

Re: [Int-area] [v6ops] End-to-end "address transparency"

On 19 January 2011 13:04, Fred Baker wrote: > > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote: > >> I didn't see any options in current routers to support utilizing a single >> path for all packets from a source (required for when current state is only >> stored on one server and not shared by a

[Int-area] Re: Call for Adoption: draft-karstens-intarea-multicast-application-port-02 (End 07/17/2025)

+1 On Thu, Jul 3, 2025 at 9:27 AM Bob Hinden wrote: > I have read the draft and support it’s adoption in the Int Area w.g. > > Bob > > > On Jul 2, 2025, at 8:43 PM, Wassim Haddad 40ericsson@dmarc.ietf.org> wrote: > > Dear IntArea WG, > > This note triggers a 2-week call for adoption of “T