Re: [Int-area] Call for Agenda Items @IETF111

FWIW, there’s lots that can be done just with source routing, esp. if they’re not just IP addresses they can already support ways to add a lot of these sort of semantics: J Touch, V Pingali: DataRouter: A Network-Layer Service for Application-Layer Forwarding

Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

Hi, all, Draft-ietf-intarea-tunnels describes the flaws in RFC 2473: o IPv6 tunnels [RFC2473 ] -- IPv6 or IPv4 in IPv6 * o Treats tunnel MTU as tunnel path MTU, not tunnel egress MTU o Decrements transiting packet hopcount (by 1)

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

Eduard, > On Mar 25, 2021, at 2:05 AM, Vasilenko Eduard > wrote: > > Hi Joseph, > It is exactly that I do not like most: complete eradicate PMTUD from any > tunnel environment. Just prohibit it. > RFC 2473: > <>6.7 IPv6 Tunnel MTU > The

Re: [Int-area] [v6ops] draft-ietf-intarea-tunnels concerns

Hi, Eduard, I’ve repeatedly addressed these, so in the same spirit of “putting it all in one place”, here are the answers. Joe > On Mar 25, 2021, at 3:52 AM, Vasilenko Eduard > wrote: > > Hi Experts, > I have not received answers (after a long message thread) for me to > understand: > >

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

Eduard, > On Mar 24, 2021, at 1:04 PM, Vasilenko Eduard > wrote: > > Hi Joseph, > You have presented below (and in many other messages) a long list of policies > (extensive usage of “SHOULD”, “NEVER”, “MUST”) > That are new – would change how current tunnels operate Some do, yes. To make

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

Two points: > On Mar 24, 2021, at 7:59 AM, Vasilenko Eduard > wrote: > > It would invalidate all tunneling implementations. It is not compatible with > any one of them. PMTUD is killed. Revolution. PMTUD is effectively dead, so if you’re worried about it, you’re 20+ years too late - as per

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

> On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, >> wrote: ... > On Mar 23, 2021, at 8:47 PM, Brian E Carpenter > wrote: > >> Tunnel packets *are* explicitly addressed to a node, so

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

Hi, Eduard, I’ll try to be brief because we’ve covered most of these issues before. We can have an extended discussion off-list if needed. Joe > On Mar 24, 2021, at 2:00 AM, Vasilenko Eduard > wrote: > > Hi all, > I could not stop the discussion at this point, because I was incomplete in >

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

mpetitive disadvantage. > It is easy to translate additional reassembly to $$ losses. > > Eduard > From: Joseph Touch [mailto:to...@strayalpha.com > <mailto:to...@strayalpha.com>] > Sent: Tuesday, March 23, 2021 10:44 PM > To: Vasilenko Eduard <mailto:vasilenk

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

> On Mar 23, 2021, at 12:10 PM, Vasilenko Eduard > wrote: > > Hi Joseph, > I am not much interested to discuss IPv4 now. (despite that 2 MTUs for one > interface is absent there too) > Let’s look at your reference to RFC 8200. > Section 4.5: unlike IPv4, fragmentation in IPv6 is performed

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

Hi, Eduard, > On Mar 23, 2021, at 8:47 AM, Vasilenko Eduard > wrote: > > Hi Joseph, > Please, show any except (or section number) from any RFC that push vendor to > use 1500B buffer for reassembly in the data plane on the transit node? (or > any other number on the transit node) The

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

> On Mar 23, 2021, at 2:18 AM, Vasilenko Eduard > wrote: > > Hi Joseph, > I still do not understand why you believe that any tunnel has a second MTU > restriction now. All tunnels - like all links, have both: - a largest message that can traverse the internal hops of that link

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

why most implementations don’t use 1500B packets either; they drop down to 1400 or so. > I believe it is better to return to RFC 2473 for the case when the packet is > already 1280 and could not be smaller. RFC2473 would fail to support IPv6 over IPv6 if it relays PTBs from ins

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

> On Mar 22, 2021, at 1:33 PM, Vasilenko Eduard > wrote: > > Hi Joseph, > You insist that the second MTU restriction exists for all data plane > implementations, just it is not visible and not discussed: neither in any RFC > nor in any vendor documentation. No; it is DEFINED in RFC1122 and

Re: [Int-area] More IPv6 fragmentation in draft-ietf-intarea-tunnels

bscription. I could not > just send the message there for a small discussion. All or nothing. Yes; that is not uncommon for IETF WGs. That doesn’t mean this discussion belongs in this WG. Joe > I hope that your replay would leave some history there. > > Eduard > From: J

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

”. We have no ICMP message for that. And creating new ICMP messages is a waste of time, given how they’re already filtered extensively. So what is your solution? I agree that making MTUs bigger would help, but they never get around this problem. Joe > > Eduard > From: Joseph Touch

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

he massive fragmentation that I would discuss > in the next email. > Eduard > From: Joseph Touch [mailto:to...@strayalpha.com > <mailto:to...@strayalpha.com>] > Sent: Sunday, March 21, 2021 7:23 PM > To: Vasilenko Eduard <mailto:vasilenko.edu...@huawei.com>> > C

Re: [Int-area] More IPv6 fragmentation in draft-ietf-intarea-tunnels

n allowing IPv6 over IPv6. I agree we can talk about a NEW mechanism to relay PTB upstream *when it follows protocol requirements*, but we need to figure out how to do this. We ALSO need to relay EMTU_R upstream at the IP layer - but have NO mechanism for that right now. Joe > Eduard &

Re: [Int-area] [v6ops] draft-vasilenko-v6ops-ipv6-oversized-analysis-00

Hi, all, Spoiler alert if you don’t want to read the whole post: - draft-vasilenko makes erroneous claims as to the content in draft-tunnels - draft-tunnels and draft-vasilenko are consistent (once the latter is corrected) in their mutual conclusions -

Re: [Int-area] Suggestion to move draft-olteanu-intarea-socks as Independent Submissions

> On Jan 15, 2021, at 7:42 AM, Behcet Sarikaya wrote: > > Hi Eric, > > I am sure you know, all independent Submission documents can only be > published as Informational. They can also be experimental. Joe ___ Int-area mailing list

Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

FWIW, 802 MAC addresses may be “set at birth” but also have long required support for multiple MAC addresses per interface, setting other MAC addresses, and disabling the “birth” address. Long as in 25+ yrs. Joe > On Sep 23, 2020, at 7:02 AM, Eric Vyncke (evyncke) > wrote: > > In another

Re: [Int-area] IPv10 I-D Destiny.

> On Aug 11, 2020, at 9:27 PM, Khaled Omar wrote: > > It’s really weird to hear the silence for my e-mails at the IETf main list,... You were told in 2017 that this was not appropriate for this list and to take this topic to INTAREA. You did and it was discussed and rejected for further

Re: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

-1 Although it’s understandable to describe “what operators do”, the IETF isn’t a news service. We typically summarize these behaviors to take a position on them. The draft provides a good description of the tradeoff between the privacy rights of endpoints and the rights of operators and the

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

Hi, all, > On May 21, 2020, at 12:30 PM, Alexandre Petrescu > wrote: > >> For AX.25 version 2.0, the >> maximum frame size expected is 330 bytes and implementations MUST be >> prepared to handle frames of this size. Higher frame sizes can be >> negotiated by AX.25 version 2.2 and so

Re: [Int-area] Tunnels and Fragmentation

Hi, Fred, > On Apr 16, 2020, at 2:36 PM, Templin (US), Fred L > wrote: > > Hi, two important documents in this wg have been sitting idle for a long time > and > perhaps it is time to start moving them forward again. The documents are: "IP > Fragmentation Considered Fragile", and "IP Tunnels

Re: [Int-area] FYI/Feedback for draft-bryant-arch-fwd-layer-ps-00

> On Mar 24, 2020, at 10:56 AM, Ted Lemon wrote: > > On Mar 24, 2020, at 1:52 PM, Toerless Eckert > wrote: >> But without a longer term architectural track doing work like this >> in parallel to current WGs, it will be difficult for the IETF to really drive >>

Re: [Int-area] FYI/Feedback for draft-bryant-arch-fwd-layer-ps-00

Reads like an academic white paper. Worth about as much of my attention. Sorry, but you asked. Joe > On Mar 23, 2020, at 7:09 PM, Toerless Eckert wrote: > > Dear intarea WG > > We think draft > https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/ > does in part touch aspects

Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

> On Mar 23, 2020, at 11:40 AM, Jon Maloy wrote: > >>> At the socket level we are using TIPC service addresses for this, i.e., a >>> {service type, service instance} tuple, each element being a 32-bit integer. >> >> That, IMO, is an ID that belongs *inside* UDP port TIPC. That is YOUR >>

Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

Jon, First, if you’re going to come to the IETF asking for something as core as an IP protocol number, you need to be able to explain your system to us in our terms. That means explaining things below in the following terms: UDP/TCP and nearly anything over IP = transport IP =

Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

> On Mar 20, 2020, at 7:09 AM, Jon Maloy wrote: > > Adding cc to int-area@ietf.org <mailto:int-area@ietf.org>, since I forgot > that in my original response. > > > On 3/19/20 9:18 PM, Joseph Touch wrote: >> >> >>> On Mar 19, 2020, at

Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

> On Mar 19, 2020, at 3:11 PM, Jon Maloy wrote: > > On 3/18/20 12:04 AM, Joseph Touch wrote: >> Hi all, >> >> I’m quite confused by this request. >> >> It seems like they either have an implementation issue (in Linux). > Linux "passthru&qu

Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

Hi all, I’m quite confused by this request. It seems like they either have an implementation issue (in Linux). I checked their documentation, which includes smoothing that looks a little like an Internet Draft: http://tipc.io/protocol.html but it’s quite

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 29, 2020, at 5:46 PM, Fernando Gont wrote: > >> I did look at the protocols involved here; the ingress does add headers but >> doesn’t appear to handle fragmentation. >> That’s a non-starter if you want your packets to traverse a network because >> people WILL hand you 1280-byte

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 28, 2020, at 5:31 AM, Phillip Hallam-Baker > wrote: > > I have a library that implements RFC6763. So my application code doesn't > actually consider IP addresses. Something does. I’m not aware of a network that uses DNS FQDNs as endpoint addresses or that can open a socket without

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 28, 2020, at 12:18 AM, Robert Raszuk wrote: > > > I don’t care about what you WANT to do; I care whether it breaks what > > everyone else expects. > > I see many folks on this colorful thread simply forgot what networks are for. > To deliver packets in the most robust and

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker > wrote: > >> IP end to end does not mean the IP address is constant end to end. It never >> has meant that and never will. > > Actually, that's the only thing it ever meant and always will. When addresses > change, *by definition*,

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 27, 2020, at 3:58 PM, Robert Raszuk wrote: > > > > What draft-ietf-spring-srv6-network-programming proposes is to remove a > > segment routing header (SRH) along the packet delivery path, before the > > packet arrives at the final destination. They call it PSP. > > That removal

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

> On Feb 27, 2020, at 3:54 PM, Mark Andrews wrote: > ... > Encapsulation doesn’t make the packet larger. Not strictly; it does make the unit of transfer larger. It’s the tunnel ingress’s job to adapt to that, e.g., using source fragmentation at the ingress. > It is no different to > talking