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

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] [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

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] 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

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

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] [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:

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] 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] 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

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

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] GPS over wifi for underground locations -- submitted draft RFC.

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/>) where many

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,

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] [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

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

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] 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

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

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

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 routers

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

On 19 January 2011 13:04, Fred Baker f...@cisco.com 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