• Re: IPv6 with Zen in the UK

    From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Mike Crowe on Sat Apr 1 16:50:01 2023
    Mike Crowe <mac@mcrowe.com> writes:

    Does anyone happen to have a working configuration using Debian pppd to connect to Zen Internet in the UK with working IPv6? It looks like IPv6 is expected to run over the IPv4 PPPoE connection. IPv4 is all working fine.

    I don't know anything about Zen, but I have configured the ISP end of a dual-stack PPP service many, many, many years ago.

    And as you've found, PPP supports IPv4 and IPv6 just fine over one single tunnel.


    I added:
    +ipv6 ipv6cp-use-ipaddr
    to the provider file in /etc/ppp/peers and the pppd output looks promising:

    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfReq id=0x1a <addr fe80::827f:f8ff:fe74:b4f3>]
    Apr 1 13:33:27 deneb pppd[117669]: sent [IPV6CP ConfAck id=0x1a <addr fe80::827f:f8ff:fe74:b4f3>]
    [...]
    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::4147:9ae5:df4d:be66>]
    Apr 1 13:33:27 deneb pppd[117669]: local LL address fe80::4147:9ae5:df4d:be66
    Apr 1 13:33:27 deneb pppd[117669]: remote LL address fe80::827f:f8ff:fe74:b4f3

    and I can ping the remote link-local address successfully. I see occasional router advertisements, but they have a reachable time of 0ms.

    So, this looks good.

    If I drop the "ipv6cp-use-ipaddr" then I get different link-local addresses for both the local and remote, but the router advertisements from the new remote still have a reachability time of 0ms.

    This shouldn't matter at all, as long as the other end accpts the
    interface-id you choose on your end. You could probably make it
    whatever you want. It's local to your ppp tunnel anyway.

    I tried manually assigning an address from the WAN /64 that Zen gave me to the ppp interface and setting the default route to the remote link-local address, but I never got any responses from anything out on the real IPv6 Internet.

    The other end could be expecting you to use the negotiated interface-id
    with that prefix. But I believe it's more likely that they expect you
    to use DHCPv6 for address configuration. Did you try that? It's quite possible that they support DHCPv6-PD, assigning you a larger prefix.

    Finding good DHCPv6 clients with PPP support used to be difficult (the
    one from ISC only worked on ethernet). I don't know the current status.
    One would hope that modern network managers like systemd-networkd or NetworkManager just works...

    I'm starting to wonder whether Zen really did turn on IPv6 support on my
    line correctly since I couldn't make it work with the router they sent me either.

    That is of course possible. But I find it likely that they would have
    blocked the IPV6CP too then.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to All on Sat Apr 1 15:40:01 2023
    Does anyone happen to have a working configuration using Debian pppd to
    connect to Zen Internet in the UK with working IPv6? It looks like IPv6 is expected to run over the IPv4 PPPoE connection. IPv4 is all working fine.

    I added:
    +ipv6 ipv6cp-use-ipaddr
    to the provider file in /etc/ppp/peers and the pppd output looks promising:

    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfReq id=0x1a <addr fe80::827f:f8ff:fe74:b4f3>]
    Apr 1 13:33:27 deneb pppd[117669]: sent [IPV6CP ConfAck id=0x1a <addr fe80::827f:f8ff:fe74:b4f3>]
    [...]
    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::4147:9ae5:df4d:be66>]
    Apr 1 13:33:27 deneb pppd[117669]: local LL address fe80::4147:9ae5:df4d:be66 Apr 1 13:33:27 deneb pppd[117669]: remote LL address fe80::827f:f8ff:fe74:b4f3

    and I can ping the remote link-local address successfully. I see occasional router advertisements, but they have a reachable time of 0ms.

    If I drop the "ipv6cp-use-ipaddr" then I get different link-local addresses
    for both the local and remote, but the router advertisements from the new remote still have a reachability time of 0ms.

    I tried manually assigning an address from the WAN /64 that Zen gave me to
    the ppp interface and setting the default route to the remote link-local address, but I never got any responses from anything out on the real IPv6 Internet.

    I'm starting to wonder whether Zen really did turn on IPv6 support on my
    line correctly since I couldn't make it work with the router they sent me either.

    Thanks.

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to All on Sat Apr 1 17:00:01 2023
    Hi Bjørn,

    On Saturday 01 April 2023 at 16:18:43 +0200, Bjørn Mork wrote:
    Mike Crowe <mac@mcrowe.com> writes:
    Does anyone happen to have a working configuration using Debian pppd to connect to Zen Internet in the UK with working IPv6? It looks like IPv6 is expected to run over the IPv4 PPPoE connection. IPv4 is all working fine.

    [snip]

    The other end could be expecting you to use the negotiated interface-id
    with that prefix. But I believe it's more likely that they expect you
    to use DHCPv6 for address configuration. Did you try that? It's quite possible that they support DHCPv6-PD, assigning you a larger prefix.

    It looks like they use DHCPv6 to delegate the LAN prefix(es), but I'd
    (possibly incorrectly assumed) that this sentence from their email:

    --8<--
    /64 Neighbour Discovery (ND) Prefix. This is used to automatically
    address the WAN interface of your Router, or if you are directly
    connected without a router, the WAN interface of that device. This can be configured using SLAAC.
    8--

    meant that I should expect to receive a RA with a /64 prefix for the WAN interface address. (Earlier in the email is a /64 described as the "ND
    prefix" along with a /48 described as the "delegation prefix".)

    If they expected me to use DHCPv6 for this wouldn't they have set the M bit
    in the RA?

    Finding good DHCPv6 clients with PPP support used to be difficult (the
    one from ISC only worked on ethernet). I don't know the current status.
    One would hope that modern network managers like systemd-networkd or NetworkManager just works...

    I did try running ISC dhclient and that would explain my lack of success. I found mention of wide-dhcpv6-client, which appears to be in Debian, so I'll have a look at that and also maybe dhcpcd which seems to be rather better
    in my experience.

    Maybe I should drag myself into the present and try systemd-networkd or NetworkManager. I've just used Debian ifupdown up until now.

    Thanks for all your advice. You've definitely given me some good pointers!

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to Mike Crowe on Sat Apr 1 17:10:02 2023
    On Saturday 01 April 2023 at 15:38:59 +0100, Mike Crowe wrote:
    On Saturday 01 April 2023 at 16:18:43 +0200, Bjørn Mork wrote:
    Finding good DHCPv6 clients with PPP support used to be difficult (the
    one from ISC only worked on ethernet). I don't know the current status. One would hope that modern network managers like systemd-networkd or NetworkManager just works...

    I did try running ISC dhclient and that would explain my lack of success. I found mention of wide-dhcpv6-client, which appears to be in Debian, so I'll have a look at that and also maybe dhcpcd which seems to be rather better
    in my experience.

    I had a go at running dhcpcd and just got "invalid argument" errors, so it appears that it doesn't like ppp interfaces either.

    wide-dhcpv6-client seemed happier to work with the ppp interface. It sent
    out DHCPv6 solicit requests and they got responses from the link-local
    address of the PPPoE remote. Unfortunately, those responses seemed rather similar to the router advertisements in that they just contained a
    delagation of ::/128 and a status code of "NoPrefixAvail".

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco@21:1/5 to All on Sat Apr 1 17:20:01 2023
    Am 01.04.2023 um 14:24:22 Uhr schrieb Mike Crowe:

    Does anyone happen to have a working configuration using Debian pppd
    to connect to Zen Internet in the UK with working IPv6? It looks like
    IPv6 is expected to run over the IPv4 PPPoE connection. IPv4 is all
    working fine.

    That would be tunneling, not common, but possible.

    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfReq id=0x1a
    <addr fe80::827f:f8ff:fe74:b4f3>] Apr 1 13:33:27 deneb pppd[117669]:
    sent [IPV6CP ConfAck id=0x1a <addr fe80::827f:f8ff:fe74:b4f3>] [...]
    Apr 1 13:33:27 deneb pppd[117669]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::4147:9ae5:df4d:be66>] Apr 1 13:33:27 deneb pppd[117669]: local
    LL address fe80::4147:9ae5:df4d:be66 Apr 1 13:33:27 deneb
    pppd[117669]: remote LL address fe80::827f:f8ff:fe74:b4f3

    That looks good.

    and I can ping the remote link-local address successfully. I see
    occasional router advertisements, but they have a reachable time of
    0ms.

    How is your computer connected to the ISP?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to Marco on Sat Apr 1 20:50:01 2023
    Hi Marco,

    On Saturday 01 April 2023 at 15:15:25 +0000, Marco wrote:
    Am 01.04.2023 um 15:38:59 Uhr schrieb Mike Crowe:

    It looks like they use DHCPv6 to delegate the LAN prefix(es), but I'd (possibly incorrectly assumed) that this sentence from their email:

    DHCPv6 prefix delegation is the next step, you need to configure the transport network first.

    True. That's why I'd not worried about the DHCPv6 part at first.

    meant that I should expect to receive a RA with a /64 prefix for the
    WAN interface address. (Earlier in the email is a /64 described as
    the "ND prefix" along with a /48 described as the "delegation
    prefix".)

    That sounds common.

    If they expected me to use DHCPv6 for this wouldn't they have set the
    M bit in the RA?

    True, does it appear?

    No it didn't. Sorry, I should have made that clearer.

    Is the RA you received like they described it?

    I don't think so. I receive one of these router advertisements every ten minutes and three seconds from the link-local address of the remote
    reported by pppd:

    --8<--
    Frame 338: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) on interface ppp0, id 0
    Linux cooked capture v1
    Internet Protocol Version 6, Src: fe80::1a2a:d3ff:fe7f:402f, Dst: ff02::1 Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x084f [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x00, Prf (Default Router Preference): Medium
    0... .... = Managed address configuration: Not set
    .0.. .... = Other configuration: Not set
    ..0. .... = Home Agent: Not set
    ...0 0... = Prf (Default Router Preference): Medium (0)
    .... .0.. = Proxy: Not set
    .... ..0. = Reserved: 0
    Router lifetime (s): 1800
    Reachable time (ms): 0
    Retrans timer (ms): 0
    8--

    You can use rdisc6 to manually send a solicitation to receive it.

    Rather strangely, running rdisc6 does cause router solicitations to be
    sent as would be expected, but they don't seem to provoke any response.

    The DHCPv6 replies I'm getting contain a similar lack of useful content:

    --8<--
    Frame 6342: 292 bytes on wire (2336 bits), 292 bytes captured (2336 bits) on interface ppp0, id 0
    Linux cooked capture v1
    Internet Protocol Version 6, Src: fe80::1a2a:d3ff:fe7f:402f, Dst: fe80::908a:1946:a823:61a4
    User Datagram Protocol, Src Port: 547, Dst Port: 546
    DHCPv6
    Message type: Reply (7)
    Transaction ID: 0x851501
    Client Identifier
    Option: Client Identifier (1)
    Length: 14
    DUID: 000100012bbb351b54e6fc80f06c
    DUID Type: link-layer address plus time (1)
    Hardware type: Ethernet (1)
    DUID Time: Apr 1, 2023 19:31:55.000000000 BST
    Link-layer address: 54:e6:fc:80:f0:6c
    Server Identifier
    Option: Server Identifier (2)
    Length: 26
    DUID: 00020000058331383a32613a64333a37663a34383a3130000000
    DUID Type: assigned by vendor based on Enterprise number (2)
    Enterprise ID: Juniper Networks/Funk Software (1411)
    Identifier: 31383a32613a64333a37663a34383a3130000000
    Identity Association for Non-temporary Address
    Option: Identity Association for Non-temporary Address (3)
    Length: 87
    IAID: 00000001
    T1: 0
    T2: 0
    IA Address
    Option: IA Address (5)
    Length: 71
    IPv6 address: ::
    Preferred lifetime: 0
    Valid lifetime: 0
    Status code
    Option: Status code (13)
    Length: 43
    Status Code: NoAddrAvail (2)
    Status Message: No addresses have been assigned for IA_NA
    Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 77
    IAID: 00000001
    T1: 0
    T2: 0
    IA Prefix
    Option: IA Prefix (26)
    Length: 61
    Preferred lifetime: 0
    Valid lifetime: 0
    Prefix length: 128
    Prefix address: ::
    Status code
    Rapid Commit
    8--

    I based my dhcp6c configuration on the example at https://github.com/torhve/blag/blob/master/using-dnsmasq-for-dhcpv6.md :

    --8<--
    interface ppp0 {
    # request a non-temporary address
    send ia-na 1;
    # request prefix delegation address
    send ia-pd 1;
    # send rapid commit, don't wait for RA
    send rapid-commit;
    };

    id-assoc pd 1 {
    # internal facing interface (LAN), you can duplicate this section if you want more subnets for more interfaces
    prefix-interface eth-local {
    # subnet. Combined with ia-pd to configure the subnet for this interface.
    sla-id 0;
    #IP address "postfix". if not set it will use EUI-64 address of the interface. Combined with SLA-ID'd prefix to create full IP address of interface. In my case, ifid 1 means that eth1 will get a IPv6 ending with ::1
    ifid 1;
    # prefix bits assigned. Take the prefix size you're assigned (something like /48 or /56) and subtract it from 64. In my case I was being assigned a /56, so 64-56=8
    sla-len 8;
    };
    };

    id-assoc na 1 {
    # id-assoc for ppp0
    };
    8--
    (I now notice that the sla-len is wrong, but I doubt that matters yet.)

    Thanks.

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco@21:1/5 to All on Sat Apr 1 21:20:01 2023
    Am 01.04.2023 um 19:45:03 Uhr schrieb Mike Crowe:

    Rather strangely, running rdisc6 does cause router solicitations to be
    sent as would be expected, but they don't seem to provoke any
    response.

    This is a fault. Tell that your ISP.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to Marco on Sat Apr 1 22:20:02 2023
    On Saturday 01 April 2023 at 19:17:08 +0000, Marco wrote:
    Am 01.04.2023 um 19:45:03 Uhr schrieb Mike Crowe:

    Rather strangely, running rdisc6 does cause router solicitations to be
    sent as would be expected, but they don't seem to provoke any
    response.

    This is a fault. Tell that your ISP.

    Thanks for all your help. I've done that.

    Judging by the ping time the Juniper router sending the router
    advertisements is at the ISP rather than wherever the fibre terminates
    locally, so it's strange that this problem isn't affecting others.

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco@21:1/5 to All on Sun Apr 2 18:30:01 2023
    Am 01.04.2023 um 21:14:40 Uhr schrieb Mike Crowe:

    Judging by the ping time the Juniper router sending the router
    advertisements is at the ISP rather than wherever the fibre terminates locally, so it's strange that this problem isn't affecting others.

    That is normal, the termination is just passive as seen from the IP
    protocol.

    In most homes, the local router (if you have one) terminates the PPP
    session and routes the delegated network inside. It also provides a
    router advertisement for the machines inside the home and uses the RA
    from the ISP's router to configure the WAN transport network.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Crowe@21:1/5 to Marco on Sat Apr 15 17:30:01 2023
    On Saturday 01 April 2023 at 19:17:08 +0000, Marco wrote:
    Am 01.04.2023 um 19:45:03 Uhr schrieb Mike Crowe:

    Rather strangely, running rdisc6 does cause router solicitations to be
    sent as would be expected, but they don't seem to provoke any
    response.

    This is a fault. Tell that your ISP.

    There was a fault at the ISP, which is why I wasn't receiving a prefix in
    the router advertisements. However, even when that problem was resolved I
    still don't get an immediate response to router solicitations. Luckily,
    they send a single router advertisement immediately after the PPP link is established (and again every ten minutes) so this will probably almost
    never be a real problem. It's a pity that the ISP doesn't seem interested
    in investigating though. :(

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)