From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 669C53CB37 for ; Tue, 13 Feb 2024 12:12:45 -0500 (EST) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-dcd94fb9e4dso112912276.2 for ; Tue, 13 Feb 2024 09:12:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707844365; x=1708449165; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Bvhsw0zgjzoSrc0jCUdcdqg9DCYj+J5i45bY8JuByk0=; b=Wsz4mnGnhF4NsEt0OyqwnZ98MlpZNhtOBWx2KOvyUUpA18BzyOIY+7kGcHow0q5qIS i5uDrOBkM1bi64lybd4XFn1s1ZdVvZpHtnLyn+0WDwR8VmhaDBn7pjrrQNl2BdpLF3NO P1zNsFi4QjERVKKV9EzhiJq3lo5Fz+zBi0itKKtZCxgpEK35x5u1TdqHJ4roGdUvbbkN A7+BF46LvjbNQmDIjfQuVGy8A8dp1Ow5LAicHj8RVlbTBy3gJa4msjp33xybGWX6R3jG eRmYC21JbgdZSz63DWp6KjN/OGnhAvYqZFjuA/YBZP5Hwprxi5xjat4gOpDmV8vEGKN5 6fVw== X-Gm-Message-State: AOJu0YwY1P6fo3ty5YazRrZ/8bNZukZm08+1JxNbOBRKAcn5/pAgFTqe 5Ne4pivPLXJZVxc1RdCRmiTJG4hkJu+cL3eXhYWze11wrPRNIQEtQq65WPsqQb447glBFT7lqrX zzABRsgIg+Xd6Iwgzqh7qekdFwJY= X-Google-Smtp-Source: AGHT+IE1ayqNc+p7ZCqt64J6zONfOtBtuofyYfUvtmp+egqORqvqd713OEIQ7W0OQS77NyiepnSFK9+D8l3P2ERhX0I= X-Received: by 2002:a25:aa6c:0:b0:dc7:47b7:9053 with SMTP id s99-20020a25aa6c000000b00dc747b79053mr8738263ybi.15.1707844364683; Tue, 13 Feb 2024 09:12:44 -0800 (PST) MIME-Version: 1.0 References: <5323051a-5835-4e42-9850-2f3349a8bd77@gmail.com> In-Reply-To: <5323051a-5835-4e42-9850-2f3349a8bd77@gmail.com> From: J Pan Date: Tue, 13 Feb 2024 09:12:33 -0800 Message-ID: To: Alexandre Petrescu Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] Measuring the Satellite Links of a LEO Network X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2024 17:12:45 -0000 yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a virtual mac used by the virtual router redundancy protocol commonly used by service providers in point-of-presence?) -- J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pa= n On Mon, Feb 12, 2024 at 6:14=E2=80=AFAM Alexandre Petrescu via Starlink wrote: > > this is an issue for 6MAN WG at IETF, but this is the text with the > issue in the paper: > > > From the user device or customer router at 192.168.1.1, > > we can reach its GS gateway at 100.64.0.1 (or equivalently > > fe80::200:5eff:fe00:101 for IPv6) > > That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80' > and the rest is an 'Interface ID', in RFC parlance. > > That IID should be more random in its appearance. It is called an > 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with > SLAAC" of year 2014. > > That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of > year 1998); they had that IID to be derived from a 48bit MAC address and > inserted an 'ff:fe' string in it to become 64bit. > > Most embedded linux platforms (v2.x kernels?) still use that ff:fe. > Migrating these kernels is sometimes very difficult. One might not want > to migrate an kernel to a bloated and slower v3 or higher just for that > little 'ff:fe'. Maybe one wants to migrate just its IPv6 stack, but > it's not easy. > > The reason of making this IID more opaque is to resist scanning > attacks. A scanning attack is when a user might have somehow an > illegitimate starlink terminal and tries to connect to the legitimate > starlink network. Part of that trying is to know the IP address of the > next hop. With IPv6 it comes down to testing all these addresses. If > they have a constant 'ff:fe' in them, it is easier to find them by brute > force than if they were opaque. It is also true that if in IPv4 that > next hop is always the same then the easiest attack is to simply use > IPv4 instead of IPv6. But this 'opaqueness' of the IID in the IPv6 ll > address might still be needed when IPv4 is get rid of. > > This could be discussed at IETF, could be suggested to starlink to > upgrade, etc. > > Alex > > Le 12/02/2024 =C3=A0 07:59, J Pan via Starlink a =C3=A9crit : > > http://pan.uvic.ca/webb/viewtopic.php?p=3D124670#p124670 to appear at > > ieee icc 2024. feedback welcome, especially during the camera-ready > > stage this week. thanks! -j > > -- > > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA= /~pan > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink