[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] Comments on draft-ietf-6man-hbh-processing-12
From:       Geoff Huston <gih () apnic ! net>
Date:       2023-11-30 22:29:43
Message-ID: 2EB4F281-D604-4AF5-84C0-E2034E6B35AA () apnic ! net
[Download RAW message or body]

The proliferation of active middleware is a real problem these days (no wonder QUIC \
took the decision to obscure every part of its UDP payload). I don't know why Linode \
is going down the path of active interference in outgoing packets. I strongly suspect \
that its dropping outbound fragmented IPv6 packets from its US pops as well as \
outbound EH frag and inconsistent ICMP6 behaviours. I wonder if there is any simple \
hosting providers left that are just that - simple.

Geoff


> On 1 Dec 2023, at 5:49 am, Justin Iurman <justin.iurman@uliege.be> wrote:
> 
> Geoff,
> 
> This is certainly true for TCP. Indeed, I observed the same behavior with Linode \
> (towards 22 different CPs in different locations) when doing JAMES measurements. If \
> I look at my results for an 8-byte Hop-by-Hop with TCP when Linode is the source, \
> there is systematically no response after hop 2 in traces (which either corresponds \
> to node 2600:3c0f:2:35::41 or ::42). So we can therefore say AS 63949 is \
> responsible for the drop in that case. However, things get crazy when using ICMPv6 \
> or UDP. 
> With ICMPv6, there are two cases (talk about inconsistency!). It is either dropped \
> (last hop responding is on the egress of AS 63949, or last hop responding is on the \
> ingress of next AS), or it gets past both AS 63949 and the next AS. In that case, \
> we cannot really say who's responsible for a drop (when there is a drop), but I \
> would suspect AS 63949 too for various reasons. Why it sometimes goes through or \
> doesn't is a mystery (wrong or inhomogeneous config? ACLs? other path? *insert any \
> reason you have in mind*). 
> Right, now the weirdo: UDP. In almost all cases (sometimes not), having an 8-byte \
> Hop-by-Hop with UDP seems to trigger the use of a "proxy". In such case, I \
> systematically end up with 4 hops responding (all in AS 63949)... and hop 5 would \
> be the destination responding! Crazy? Of course, a lot more hops are involved in \
> reality (e.g., without the Hop-by-Hop). Which makes me think... I remember one CP \
> where I noticed (by chance) such behavior. Using different ports (for instance) \
> would trigger (or not) this "proxy" thing. 
> Interesting, there's def something going on in AS 63949.
> 
> HTH,
> Justin
> 
> On 11/29/23 23:15, Geoff Huston wrote:
> > > On 30 Nov 2023, at 9:06 am, Tom Herbert \
> > > <tom=40herbertland.com@dmarc.ietf.org> wrote: 
> > > On Wed, Nov 29, 2023 at 1:31 PM Templin (US), Fred L
> > > <Fred.L.Templin@boeing.com> wrote:
> > > > 
> > > > Tom,
> > > > 
> > > > > this topic). My conclusion wrt Hop-by-Hop Options is that most likely
> > > > > they'll only ever be productively used in limited domains. Even so,
> > > > > this draft is still important even if it's intent is to make HBH "more
> > > > > practical to use Hop-by-Hop options beyond such a single domain"
> > > > 
> > > > RFC9268 was published not terribly long ago and specifies a HBH option
> > > > that I think was intended to be used beyond just a limited domain. Surely
> > > > that HBH option (and others like it) should be accommodated as broadly
> > > > as possible, right?
> > > 
> > > Fred,
> > > 
> > > It's a statement of practicality. The APNIC data indicates that the
> > > drop rate of Hop-by-Hop Options in the Internet is >99%. I believe
> > > this is a security policy where a network provider drops packets with
> > > HBH on ingress to their network since they target not just the
> > > destination host but also routers in their network infrastructure
> > > which make them a possible risk to the infrastructure. Given the
> > > apparent pervasiveness of this policy, I think it's going to be very
> > > difficult to undo this policy especially in the absence of having any
> > > globally useful Hop-by-Hop options. While RFC9268 could be used across
> > > the Internet, I'm not sure I would trust the information if it was
> > > being set by an anonymous router outside of my hosts's local domain
> > > (it's similar to how no one seems to trust ICMP errors coming into
> > > their network).
> > > 
> > > Within a limited domain, the story is very different. HBH options like
> > > IOAM are deployable and beneficial, and the security aspects are more
> > > manageable. I think HBH could flourish in limited domains, and there's
> > > always the possibility of connected providers to accept HBH options
> > > across the boundary thereby increasing the scope of limited domains.
> > > 
> > > Tom
> > I feel I should correct this...
> > > The APNIC data indicates that the
> > > drop rate of Hop-by-Hop Options in the Internet is >99%.
> > The APNIC data does indicate this, but the reason for this outcome is not due to \
> > some common behviour in the Internet.  Its the result of egress filtering by \
> > Linode, which dropas all outgoing IPv6 packets with IPv6 HBH headers (gee thanks \
> > Linode!) https://www.potaroo.net/ispcol/2023-06/eh.html
> > "We are now satisfied that the close to comprehensive EH drop observed in the \
> > APNIC Labs experiment is a result of a Linode environment setting that drops all \
> > such packet on egress from the Linode environment. This behaviour is also \
> > observed in a number of other public Internet server environments, and from our \
> > tests it appears that the behaviour of the JANET network, the Cloudflare network \
> > and the You Fibre network in forwarding such IPv6 packets are somewhat \
> > exceptional, and the typical network behaviour is to discard such packets." \
> > regards, Geoff
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]