[Starlink] Starlink and bufferbloat status?

[Michael Richardson]

David Lang <david at lang.hm> wrote:
    mcr> I'm scared that these paths will centrally managed, and not based upon
    mcr> longest prefix (IPv6) match.

    david> unless you are going to have stations changing their IPv6 address frequently,

    dt> I'd really, really, hope for a dedicated /56 per station, no changes,
    dt> EVER, unless the user requests it it falls under attack. Perhaps two
    dt> /56s for failover reasons. Really silly
    dt> to make ipv6 dynamic in this environment.

    david> if you are going to route based on IPv6 prefixes, then the
    david> prefixes need to have a close relationship to location (which is
    david> what routing needs to care about). If you have fixed addresses and
    david> mobile stations, you can't route based on address prefixes.

Well, you could go all way to https://datatracker.ietf.org/doc/html/draft-hain-ipv6-geo-addr-02
This makes most sense if you then have SHIM6 (being revised soon), and/or
MPTCP to move from this overlay network to the transport network.

    > One of the wonderful things about the Internet is that no device needs to
    > understand the entire network. They just need information about which next
    > hop to use to get to different destiantions.

This is a really important thing to remember.
RFC6550 adds the RFC6553 header to deal with some kinds of loops.
RFC6550 (RPL) might work well among satellites, or maybe not.

One would have a multitude of DODAGs, but if they are non-storing DODAGs,
then that doesn't mean that every satellite has any state.
I would run a DODAG of exit nodes, and run user traffic as an overlay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20210719/af5ec68b/attachment.sig>