Any IPv6 trial successes with intermediate router?

Ugh, I too was hoping that the /56 could be delegated to an intermediate router. I've been banging my head to get a pfSense box running. The WAN interface from the firewall conencted to the Comcast gateway, and does get a /64 delegation and creates and EUI64 address. From there I can ping ipv6.google.com, etc. Trying to do an IA_PD for the internal WAN interface? No-go.

At this point I cannot successfully test because per policy we don't attach end user devices to the Internet (IPv4 or v6) without some form of router in between.

Will Comcast send out an email once the intermediate device delegations are enabled?

So glad someone posted this thread, I've spent do much time trying to get this to work with similar results. Having it on devices directly attached to the netgear doesnt work for me either, so I'm effectively not able to do much with the trial.

It sounds like some people are at least having luck with getting PD to at least issue a lease.

I can't even get that to happen.

Could someone who gets a PD lease post a very verbose tcpdump of the DHCPv6 exchange with the netgear?

(btw. some simple programmable web/cli interface for adding/removing reverse dns would be awesome)

Hi Maze,

Where have you seen examples of people getting PD leases? Would like to start stalking those areas too. I'll see if I can get a trace running on a local interface to see how it gets PD-0 and if/why the other requests for higher number PD's fail.

The 2nd comment in this thread from Geoff seems to imply he got a ...80::/64 PD lease.  The routing for it doesn't work, but I thought he had at least received it successfully.

I believe I've also seen comments from Comcast Tuska that this has been tested to work on 2 or 3 specific router CPE models (something about an Asus and Cisco test device I think).

That was also my interpretation of what people were writing/saying in 2-3 other threads on this forum.

I've never seen a PD<80 (ie. in particular PD ..00::/64) get issued.  Only PDs 80 and up (presumably to FF).

I can get a PD ...00::/64 *equivalent* via stateless DHCPv6 or via RA's - but that is not PD based at all so doesn't count.

---

To reiterate (see other thread) in my experiments: my DHCPv6 client does a SOLICIT for a PD, gets a ..8x::/64 PD ADVERTISE from the netgear, attempts to REQUEST it, but then the cable modem issues an ERROR NotOnLink REPLY instead of a successful REPLY.

I did some more testing and can confirm you analysis. My mistake was using pfSense as a test platform -- I think it's broken in a way that doesn't allow PD's to work at all (that and a screwy changing of link-local addresses to fe80:1::1:1, which gets duplicates when a 2nd box in put online).

Anyway, fired up m0n0wall in a VM to quickly test.

WAN if: 2601:0:c980:900:20c:29ff:fec8:6c19 (2601:0:c980:900::/64 received from Netgear modem)

LAN if: 2601:0:c980:980:20c:29ff:fec8:6c0f (2601:0:c980:980::/64 PD when entering 0x81)

Quick ICMP6 to ipv6.google.com returns (tcpdump on network between netgear and firewall):

10:01:25.796994 IP6 2601:0:c980:900:20c:29ff:fec8:6c19 > vc-in-x8b.1e100.net: ICMP6, echo request, seq 0, length 16
10:01:25.843349 IP6 vc-in-x8b.1e100.net > 2601:0:c980:900:20c:29ff:fec8:6c19: ICMP6, echo reply, seq 0, length 16
10:01:26.797051 IP6 2601:0:c980:900:20c:29ff:fec8:6c19 > vc-in-x8b.1e100.net: ICMP6, echo request, seq 1, length 16
10:01:26.842903 IP6 vc-in-x8b.1e100.net > 2601:0:c980:900:20c:29ff:fec8:6c19: ICMP6, echo reply, seq 1, length 16
10:01:27.796729 IP6 2601:0:c980:900:20c:29ff:fec8:6c19 > vc-in-x8b.1e100.net: ICMP6, echo request, seq 2, length 16
10:01:27.842439 IP6 vc-in-x8b.1e100.net > 2601:0:c980:900:20c:29ff:fec8:6c19: ICMP6, echo reply, seq 2, length 16
10:01:35.248647 IP6 2601:0:c980:980:20c:29ff:fec8:6c0f > vc-in-x65.1e100.net: ICMP6, echo request, seq 0, length 16
10:01:36.250727 IP6 2601:0:c980:980:20c:29ff:fec8:6c0f > vc-in-x65.1e100.net: ICMP6, echo request, seq 1, length 16
10:01:37.248458 IP6 2601:0:c980:980:20c:29ff:fec8:6c0f > vc-in-x65.1e100.net: ICMP6, echo request, seq 2, length 16

So it does confirm what Geoff and you see: PD's are being correctly assigned (I didn't try a <80 for the LAN), but only the PD ...00::/64 is actually passing trafifc through the netgear and recieving a response.

> (2601:0:c980:980::/64 PD when entering 0x81)

What do you mean here?  Where are you entering 0x81?  I see '80::/64' ie. 80 and not 81 in the address.

Also it sounds like something is configuring ...80::/64 on your lan interface.  This suggests the netgear successfully issued the PD (ie. SOLICIT->ADVERTISE->REQUEST->SUCCESSFULL REPLY).  Which DHCPv6 client are you using and which version, what config? What firmware version do you have on the netgear?  Do you have any (verbose preferably) logs from the DHCPv6 client showing what it's doing?  Or maybe tcpdump of the DHCP exchange?

Thanks!

It may have been 0x80 entered instead of 0x81 (although I thought that was it).

Let me startup the m0n0wall test VM and see what I can get from a tcpdump with full headers and decode of the DHCPv6c details. I'll do a quick Visio and provide the modem details (IPv6 config and the firmware version).

Yeah, the allocation appears to be getting assigned, and traffic is passing from the LAN to WAN. I didn't verify that the LAN originated traffic is destined for the MAC accdress of the netgear.

Would be great to get some Comcast engineering input on this. Are there any other forums or ways to engage the beta team? Besides just surfing via IPv6 I assume they'd want more input ala the residential teams.

Disregard. I put in the wrong route statement for testing, got sent to my production SMC modem and not the Netgear.

Sorry for the confusion.

As of right now sub-prefix deligation isn't working correctly it has a bug that we are working on getting it fixed..  I know must of the trial users want it but we need to make sure that phase 1 doesnt have any issues first..

Phase 1 is the Dynamic users directly behind the modem..

It does seem IPv6 works on directly attached devices (ie. the ...00::/64 network).

That said, at least for me (and I'm guessing many users, regardless of whether commercial/business or residential) the only devices directly connected to the netgear cable modem is a router (and the original smc business cable modem with static ipv4).

As such testing has been limited to a few ping6, traceroute6 and wget's from the router - those work.

I don't have a good idea of how to route/firewall/nat ipv4 at the router but bridge/firewall ipv6.

I think it just possibly might be doable with a modern enough linux kernel + ebtables/iptables/ip6tables userspace and some fancy config... but that sounds very very hard and not worth the effort for a temporary hack 😉

Here's the features I'd like:

- Prefix Delegation working

- static [/56] ipv6 subnet (persistent across multiday cablemodem power outage) - ie. equivalent of already existing static ipv4 subnet on the SMC

- some way to get the same PD persistently handed out to the same device even across multiday powerloss

  [ie. probably some way to say give me PD XX or fail if XX is not available, it's okay if i need to store a duid or some other key in the device doing the requesting, provided no other device(s) can grab this PD first (race condition during power power loss power on) probably easiest to do if you don't hand it out without devices explicitly asking for it - hmm maybe that's why you start at PD ...80::/64 instead of ...01::/64 already ;-)] -- this might also be achievable by static routing configuration or honouring device RAs [hmm, something to test, what happens if my router RAs ...01::/64... with the current setup]

- static ipv4 (on the netgear and not on the smc so I can use just one modem)

- reverse DNS delegation (or some bulk upload to comcast method) for ipv6 (and ipv4), some authenticated encrypted wget-able API would be nice

- read-only snmp monitoring of the cable modem (from local network)

- some way to reboot the cable modem (from local network), either via wget basic auth, or via snmp write

> hmm, something to test, what happens if my router RAs ...01::/64... with the current setup

AFAICT the Netgear ipv6 cablemodem doesn't honour/obey/act on RAs [router advertisements] for ...01::/64 sent by my router - so no luck there. 😞

I was kind of hoping that would work since it is the obvious way to get a static config up and running, which is all we really need without any of this fancy PD stuff 😉

Did the PD issues in this post ever get fixed?

Particularly for the SMC D3G with firmware 3.1.6.56...

Apparently not yet according to:  http://forums.businesshelp.comcast.com/t5/IPV6/Dual-Stack-on-SMC-D3GCCR-and-Cisco-DPC3939B/td-p/20504/jump-to/first-unread-message