On Mon, Dec 9, 2013 at 11:08 AM, Randy Bush <randy@psg.com> wrote:

...

do you see PD from your modem? or RA's?

still trying to educate the opwnwrt (attitude adjustment on netgear 3800).

root@wrt-biwa:~# opkg update Downloading http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packag.... Inflating http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packag.... Updated list of available packages in /var/opkg-lists/attitude_adjustment. root@wrt-biwa:~# opkg install luci-proto-ipv6 Unknown package 'luci-proto-ipv6'. Collected errors: * opkg_install_cmd: Cannot install package luci-proto-ipv6. root@wrt-biwa:~# opkg install ipv6-support Unknown package 'ipv6-support'. Collected errors: * opkg_install_cmd: Cannot install package ipv6-support.

sigh

yea, so my 'saga' started with: 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" a) gets v6 addr on WAN from arris-RA b) gets PD alloction from arris, does RA's to LAN c) sets default-gw for v6 on the LAN side to something unreachable d) manually resetting default-gw ... gets me zippy... can't ping either side of the dlink, nor the arris :( e) dlink's v6 code (for that platform) is just boarked, badly. 2) oh! dd-wrt does this platform too, and v6 a) install dd-wrrt b) fiddle-fart around with v6 configs c) oh.. dhcp-pd is one of the things dd-wrt didn't implement :( d) oh, their 'v6 support' is really only 'v6 tunnel support' e) boned. basically ... this is much harder to do than it shoudl be :( and yes, I can probably do something like plug in my raspberry-pi and make that a 'router' but come on... in 2013 I have to home-brew something to get a protocol developed and engineered in 2000 to work? :( (this raised itself above my level of 'fixed in a weekend' project, so my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my eyes.) -chris

On Mon, Dec 9, 2013 at 11:29 AM, Randy Bush <randy@psg.com> wrote:

...

(this raised itself above my level of 'fixed in a weekend' project, so my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my eyes.)

i could take a picture, but i think you would recognize the boat. sigh.

I should be fair to the problem (and my lack of patience with it) and: 1) document with some pictures and packet-captures and interface configs 2) take a better stab at making the stock deployment work 3) write all this up somewhere searchable by askjeeves. if work doesn't eat my evening I'll make an attempt at that tonight/tomorrow. -chris

On Mon, Dec 9, 2013 at 9:14 AM, Justin M. Streiner <streiner@cluebyfour.org> wrote:

On Mon, 9 Dec 2013, Christopher Morrow wrote:

...

if work doesn't eat my evening I'll make an attempt at that tonight/tomorrow.

Thanks for reminding me that I need to get back on Verizon's case about getting IPv6 on Fios... :|

good luck! and I think their plans currently are to provide you CGN first :( (happy if i"m wrong about that)

On 13-12-09 01:19 PM, John Lightfoot wrote:

We don't even support IPv5 yet, so it will be a while before we support v6. Naturally, as the odd-numbered releases of IP are experimental. They should be focusing on the even-numbered releases for production use.

M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael@supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian

On Mon, Dec 9, 2013 at 5:08 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Mon, Dec 9, 2013 at 1:28 PM, Michael Brown <michael@supermathie.net>

wrote:

...

On 13-12-09 01:19 PM, John Lightfoot wrote:

...

We don't even support IPv5 yet, so it will be a while before we support v6.

Naturally, as the odd-numbered releases of IP are experimental. They should be focusing on the even-numbered releases for production use.

is this a StarTrek reference? :)

Or a Linux kernel reference, which in turn could be a Star Trek reference... Rubens

On Mon, 9 Dec 2013 11:19:18 -0500 Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Mon, Dec 9, 2013 at 11:08 AM, Randy Bush <randy@psg.com> wrote:

...

...

do you see PD from your modem? or RA's?

still trying to educate the opwnwrt (attitude adjustment on netgear 3800).

root@wrt-biwa:~# opkg update Downloading http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packag.... Inflating http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/packag.... Updated list of available packages in /var/opkg-lists/attitude_adjustment. root@wrt-biwa:~# opkg install luci-proto-ipv6 Unknown package 'luci-proto-ipv6'. Collected errors: * opkg_install_cmd: Cannot install package luci-proto-ipv6. root@wrt-biwa:~# opkg install ipv6-support Unknown package 'ipv6-support'. Collected errors: * opkg_install_cmd: Cannot install package ipv6-support.

sigh

yea, so my 'saga' started with: 1) "dlink 615 doesn't like dhcp-pd ... and is flat broken for v6" a) gets v6 addr on WAN from arris-RA b) gets PD alloction from arris, does RA's to LAN c) sets default-gw for v6 on the LAN side to something unreachable d) manually resetting default-gw ... gets me zippy... can't ping either side of the dlink, nor the arris :( e) dlink's v6 code (for that platform) is just boarked, badly.

2) oh! dd-wrt does this platform too, and v6 a) install dd-wrrt b) fiddle-fart around with v6 configs c) oh.. dhcp-pd is one of the things dd-wrt didn't implement :( d) oh, their 'v6 support' is really only 'v6 tunnel support' e) boned.

basically ... this is much harder to do than it shoudl be :( and yes, I can probably do something like plug in my raspberry-pi and make that a 'router' but come on... in 2013 I have to home-brew something to get a protocol developed and engineered in 2000 to work? :(

(this raised itself above my level of 'fixed in a weekend' project, so my comcast v6 lays fallow... NOTE: this is NOT comcast's fault, in my eyes.)

-chris

I feel your pain. I am on the Comcast Business trial and have tried pfsense and now trying monowall. I followed all the different instructions I could find for pfsense 2.1 and while I could pull the WAN IP, I never could get a LAN ip nor could I get an ip on any of my computers. I am now in the process of trying m0n0wall and have gotten IP's on the WAN, LAN, and on my workstation. Can ping from my workstation to my m0n0wall LAN and WAN IP's but nothing will route out to the net. It should really be easier than this. Robert

Oh, I agree. If I plug the Netgear box directly into my network, everything works great. I really believe it is a pFsene/m0n0wall issue. Robert On Mon, 9 Dec 2013 11:44:14 -0500 Jared Mauch <jared@puck.nether.net> wrote:

I have no issues with the comcast business netgear box and normal ra+dhcpv6. Not trying anything fancy as when I do, I spend too much time doing tech support for my family. Flat lan makes it work.

Jared Mauch

...

On Dec 9, 2013, at 11:32 AM, <rwebb@ropeguru.com> wrote:

I feel your pain. I am on the Comcast Business trial and have tried pfsense and now trying monowall. I followed all the different instructions I could find for pfsense 2.1 and while I could pull the WAN IP, I never could get a LAN ip nor could I get an ip on any of my computers.

On Mon, Dec 9, 2013 at 9:49 AM, Randy Bush <randy@psg.com> wrote:

http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on?

According to Comcast’s DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=i&so=1&e=0&d3=1&tier=-1&sc=84, the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I’m not optimistic. I opted for my minimal-effort solution. I installed a Motorola SB6121 and a 5th gen Airport Extreme and turned them on. Of course I configured the Airport Extreme with a name, management password, and confirmed IPv6 was set to to configure Automatically and Native. When the Comcast drop was plugged in and Comcast authorized the modem, I had a multistacked LAN. Going on 11 months of IPv4/IPv6 service. I’ve had about 1 hour of downtime. James R. Cutler james.cutler@consultant.com

On 12/9/13, 12:34 PM, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> wrote:

On Mon, 09 Dec 2013 11:51:46 -0500, Cutler James R said:

...

According to Comcast's DOCSIS Devices page, http://mydeviceinfo.comcast.net/?s=3Di&so=1&e=0&d3=1&tier=-1&sc=84 the Cisco DPC3008 is not supported for IPv6. You could always try enabling IPv6 on a system directly connected to the Cisco and see what happens. I'm not optimistic.

That page also says the Zoom 5341 cable modem doesn't do IPv6, although the device in my living room says it does indeed do so but its upstream refuses to provision it.

While I won't speak to specific device makes/models, we at Comcast add a device to the v6 list after we have tested and shown that it works. In my experience, hearing "our device/router/software/whatever supports IPv6² isn¹t generally specific enough and often doesn¹t mean much until it has been tested. ;-) Jason

On Wed, Dec 11, 2013 at 8:17 AM, Randy Bush <randy@psg.com> wrote:

Randy Bush wrote:

...

http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on?

randy

after a lot of messing about with the massive help of Chris Adams and John Brzozowski, problem solved. see http://rtechblog.psg.com/

It brings a tear to my eye that it takes: 0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone; 3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it. just to get IPv6 to work correctly. Yea, that's TOTALLY reasonable. -e

randy

On 12/11/2013 10:11 AM, Eric Oosting wrote:

It brings a tear to my eye that it takes:

0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone; 3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it.

just to get IPv6 to work correctly.

Yea, that's TOTALLY reasonable.

-e

...

randy

I wonder if he got any better than a /60 for his troubles... Andrew

On Wed, Dec 11, 2013 at 10:40 AM, Randy Bush <randy@psg.com> wrote:

...

just to get IPv6 to work correctly.

i would not have had this problem if i had not done the openwrt thing. the stock netgear would have been fine. i brought this on myself because i wanted to also run things such as an openvpn server.

i was documenting for the next to follow, not to whine.

To be clear, I wasn't accusing you of whining. And thanks for documenting it for the next guy. Stock netgear does PD and works out of the box? Didn't realize that. -e

randy

On 12/11/13, 7:45 AM, Randy Bush wrote:

...

To be clear, I wasn't accusing you of whining. And thanks for documenting it for the next guy.

it just works for gals, they have all the luck and the brains

...

Stock netgear does PD and works out of the box? Didn't realize that.

so says my authority, joelja

I have been trying with some success to be a consumer rather than a hacker with respect to my connectivity, and the results haven't been that bad. t-mobile cell vzw wireless dongle comcast broadband All have nominally working v6. Now if I could get the office vpn...

randy

On 12/11/13, 7:11 AM, Eric Oosting wrote:

On Wed, Dec 11, 2013 at 8:17 AM, Randy Bush <randy@psg.com> wrote:

...

Randy Bush wrote:

...

http://comcast6.net/ tells me that the local cmts is v6 enabled. my modem, a cisco dpc3008, is in the supported products list. so how do i turn the sucker on?

randy

after a lot of messing about with the massive help of Chris Adams and John Brzozowski, problem solved. see http://rtechblog.psg.com/

It brings a tear to my eye that it takes:

0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone;

it's worth noting that, that cpe works just fine for this purpose with the manufacturer supplied firmware. so the motivation for doing it this way lies elsewhere. If you approach this as consumer rather than futzing with it you'll probably have a different experience. At my appartment I have a mot sb6121 and a netgear wndr3700 and comcast v6 works without apparent effort.

3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it.

just to get IPv6 to work correctly.

Yea, that's TOTALLY reasonable.

-e

...

randy

On Dec 11, 2013, at 2:18 PM, Owen DeLong <owen@delong.com> wrote:

It doesn’t. You can get IPv6 working with off-the-shelf equipment if you choose to.

Randy chose to use that particular hardware and software combination.

I'll chime in with a link to data: http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption Looking at things, USA is at 5%+ adoption, which is due to the hard work of folks at Comcast (and other ISPs). Overall google is seeing 2.5%+ of traffic over native IPv6. in several cases IPv6 is actually faster than IPv4: 16 bytes from 2001:418:3f4::5, icmp_seq=0 hlim=57 time=18.649 ms 16 bytes from 2001:418:3f4::5, icmp_seq=1 hlim=57 time=19.008 ms 16 bytes from 2001:418:3f4::5, icmp_seq=2 hlim=57 time=18.959 ms ^C --- puck.nether.net ping6 statistics --- 4 packets transmitted, 3 packets received, 25.0% packet loss round-trip min/avg/max/std-dev = 18.649/18.872/19.008/0.159 ms PING puck.nether.net (204.42.254.5): 56 data bytes 64 bytes from 204.42.254.5: icmp_seq=0 ttl=55 time=32.920 ms 64 bytes from 204.42.254.5: icmp_seq=1 ttl=55 time=18.467 ms 64 bytes from 204.42.254.5: icmp_seq=2 ttl=55 time=22.014 ms 64 bytes from 204.42.254.5: icmp_seq=3 ttl=55 time=20.807 ms 64 bytes from 204.42.254.5: icmp_seq=4 ttl=55 time=19.096 ms ^C --- puck.nether.net ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 18.467/22.661/32.920/5.280 ms - jared

On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong <owen@delong.com> wrote:

It doesn’t. You can get IPv6 working with off-the-shelf equipment if you choose to.

Randy chose to use that particular hardware and software combination.

I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD? I have been making plans to put OpenWRT on my home router to get IPv6 and have found v6 support quite lacking. Most of the routers seem to like to focus on various transition technologies like 6to4 tunnels. I would love to go to NewEgg and get a home router for $50 (or even $100) that is ready to go. What's more surprising is even Cisco and Juniper have been lagging. The SRX only got DHCPv6-PD support in the last 6 months or so and I don't think the ASA has it yet. However, ISR routers like the 88x and 86x support it. -Kyle

The problem isn't the consumer devices. The problem is most of the open source router software developers don't see ipv6 as a priority, or something even worth "wasting time" on. On Wed, Dec 11, 2013 at 1:57 PM, Leo Bicknell <bicknell@ufp.org> wrote:

On Dec 11, 2013, at 1:46 PM, "Kinkaid, Kyle" <kkinkaid@usgs.gov> wrote:

...

I would love to go to NewEgg and get a home router for $50 (or even $100) that is ready to go.

http://mydeviceinfo.comcast.net/?homegateway contains devices Comcast has actually tested in their lab, and so they are safer than most. There are devices not on this list that meet your criteria as well.

I believe the absolute cheapest at NewEgg is the D-Link DIR 655, which is $63.99 with "Extra savings .. promo code" right now: http://www.newegg.com/Product/Product.aspx?Item=N82E16833127215

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

Hi, Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle <kkinkaid@usgs.gov> het volgende geschreven:

I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD?

I have tested a whole bunch of them more than a year ago. I can remember seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be forgetting a few as well. Most of them weren't very advanced, but they worked to get IPv6 connectivity in the house. What I am missing these days is DHCPv6-PD server support to re-delegate parts of the prefix it got from the ISP downstream to other home routers. As far as I know AVM Fritz!box is the only one that does that today. Cheers, Sander

Hear hear. Mark Andrews <marka@isc.org> wrote:

...

Hi,

Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle <kkinkaid@usgs.gov> het volgende geschreven:

...

I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD?

I have tested a whole bunch of them more than a year ago. I can remember seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be forgetting a few as well. Most of them weren't very advanced, but

In message <A026246E-F884-47F0-9225-AFAA87CD35B1@steffann.nl>, Sander Steffann writes: they

...

worked to get IPv6 connectivity in the house. What I am missing these days is DHCPv6-PD server support to re-delegate parts of the prefix it got from the ISP downstream to other home routers. As far as I know AVM Fritz!box is the only one that does that today.

And the need for it was obvious when all the other boxes were being developed. Daisy chaining routers has been part of home setups for many, many years if only to get configuration control because the ISP router is not configurable enough. There was no reason to think that this would change with IPv6.

...

Cheers, Sander -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

In message <CAKr6gn11nLzELbeMKksWAZuR6Tm0A6_kSsJDeF3d=9_N6p0ijA@mail.gmail.com> , George Michaelson writes:

I am probably closer to consumer behaviour at home than most of you. I don't regard my home router as a vehicle for hackery beyond clue I can find on the end user public lists and rarely if ever even apply that, and I run stock factory billion code on my billion ADSL2+ home gateway.

I just enabled the ADSL2+ profile which had IPv6 and restarted. It came up immediately with a /56 and I haven't touched it since. I have been using it to SSH back home quite comfortably with an almost unmodified ACLset to permit port 22 inbound.

This is on Internode, in Australia.

So, while I fully acknowledge the reality is that for a lot of people, cable and other complex head-end systems needed change and the experience of going dual-stack can be painful, I want to assert IT DOESNT HAVE TO BE and I am proof by example

It just worked.

And it should "just work" if you have two router daisy chained. PD was designed to allow this to work. The home router vendors had all the protocols required to make it work. They choose not to implement a working solution. It isn't that hard to supply a take a PD request on one interface and make a upstream request if you don't have unassigned space to hand out then return the response add routing table entries to keep it all working. One can do more complicated stuff than that like running a routing protocol but static routes also work. It may not be optimal but there was nothing stopping those other vendors from coding the support. Most home routers already do stuff like that in IPv4 for DNS servers and other protocol elements. They take what they have learnt from upstream as supply it downstream. Mark

On Thu, Dec 12, 2013 at 8:01 AM, Mark Andrews <marka@isc.org> wrote:

...

In message <A026246E-F884-47F0-9225-AFAA87CD35B1@steffann.nl>, Sander Steffann writes:

...

Hi,

Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle <kkinkaid@usgs.gov> het volgende geschreven:

...

I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD?

I have tested a whole bunch of them more than a year ago. I can remember seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be forgetting a few as well. Most of them weren't very advanced, but they worked to get IPv6 connectivity in the house. What I am missing these days is DHCPv6-PD server support to re-delegate parts of the prefix it got from the ISP downstream to other home routers. As far as I know AVM Fritz!box is the only one that does that today.

And the need for it was obvious when all the other boxes were being developed. Daisy chaining routers has been part of home setups for many, many years if only to get configuration control because the ISP router is not configurable enough. There was no reason to think that this would change with IPv6.

...

Cheers, Sander -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

--047d7b10ccc3ea2d0c04ed4a023d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

...

<div>So, while I fully acknowledge the reality is that for a lot of people= , cable and other complex head-end systems needed change and the experience= of going dual-stack can be painful, I want to assert IT DOESNT HAVE TO BE = and I am proof by example</div> <div><br></div><div>It just worked.</div></div><div class=3D"gmail_extra"><= br><br><div class=3D"gmail_quote">On Thu, Dec 12, 2013 at 8:01 AM, Mark And= rews <span dir=3D"ltr"><<a href=3D"mailto:marka@isc.org" target=3D"_blan= k">marka@isc.org</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br> In message <<a href=3D"mailto:A026246E-F884-47F0-9225-AFAA87CD35B1@steff= ann.nl">A026246E-F884-47F0-9225-AFAA87CD35B1@steffann.nl</a>>, Sander St= effann<br> writes:<br> <div><div class=3D"h5">> Hi,<br> ><br> > Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle <<a href=3D"mailto:kk= inkaid@usgs.gov">kkinkaid@usgs.gov</a>> het<br> > volgende geschreven:<br> > > I'm curious, do you know of a consumer-grade router which sup=

<div dir=3D"ltr">I am probably closer to consumer behaviour at home than mo= st of you. I don't regard my home router as a vehicle for hackery beyon= d clue I can find on the end user public lists and rarely if ever even appl= y that, and I run stock factory billion code on my billion ADSL2+ home gate= way.<div> <br></div><div>I just enabled the ADSL2+ profile which had IPv6 and restart= ed. It came up immediately with a /56 and I haven't touched it since. I= have been using it to SSH back home quite comfortably with an almost unmod= ified ACLset to permit port 22 inbound.</div> <div><br></div><div>This is on Internode, in Australia.</div><div><br></div= ports<br> > > DHCPv6-PD?<br> ><br> > I have tested a whole bunch of them more than a year ago. I can rememb= er<br> > seeing IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Lin= k,<br> > Draytek, Zyxel, Linksys, Asus, Thompson/Technicolor and I must be<br> > forgetting a few as well. Most of them weren't very advanced, but = they<br> > worked to get IPv6 connectivity in the house. What I am missing these<= br> > days is DHCPv6-PD server support to re-delegate parts of the prefix it= <br> > got from the ISP downstream to other home routers. As far as I know AV= M<br> > Fritz!box is the only one that does that today.<br> <br> </div></div>And the need for it was obvious when all the other boxes were b= eing<br> developed. =A0Daisy chaining routers has been part of home setups for<br> many, many years if only to get configuration control because the<br> ISP router is not configurable enough. =A0There was no reason to think<br> that this would change with IPv6.<br> <br> > Cheers,<br> > Sander<br> <span class=3D"HOEnZb"><font color=3D"#888888">--<br> Mark Andrews, ISC<br> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2= 9871 4742</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: <a href=3D"mailto:= marka@isc.org">marka@isc.org</a><br> <br> </font></span></blockquote></div><br></div>

--047d7b10ccc3ea2d0c04ed4a023d-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Ok, so... with a little messing around with the raspberry-pi + tp-link + wide-dhcpv6 client.. success! more at: http://goo.gl/jnrY7s On Fri Dec 13 2013 at 3:57:49 PM, Bill Weiss <houdini+nanog@clanspum.net> wrote:

...

On Wed, Dec 11, 2013 at 11:18 AM, Owen DeLong <owen@delong.com> wrote:

...

It doesn’t. You can get IPv6 working with off-the-shelf equipment if you choose to.

Randy chose to use that particular hardware and software combination.

I'm curious, do you know of a consumer-grade router which supports DHCPv6-PD? I have been making plans to put OpenWRT on my home router to get IPv6 and have found v6 support quite lacking. Most of the routers seem to like to focus on various transition technologies like 6to4 tunnels. I would love to go to NewEgg and get a home router for $50 (or even $100) that is ready to go.

What's more surprising is even Cisco and Juniper have been lagging. The SRX only got DHCPv6-PD support in the last 6 months or so and I don't

Kinkaid, Kyle(kkinkaid@usgs.gov)@Wed, Dec 11, 2013 at 11:46:56AM -0800: think

...

the ASA has it yet. However, ISR routers like the 88x and 86x support it.

So what it's worth, I'm on Comcast Business, using an ASUS RT-N66U router and a Motorola SB6141 modem. IPv6 Just Works on my network. I don't remember having to do anything strange to the router to make it work, and I'm certainly still running the default firmware.

-- Bill Weiss

Eric Oosting <eric.oosting@gmail.com> writes:

It brings a tear to my eye that it takes:

0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone; 3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it.

just to get IPv6 to work correctly.

Yea, that's TOTALLY reasonable.

Pretty much works out of the box on Mikrotik RouterOS if you are secure enough in your geek cred to admit to running such stuff here in this august forum. -r

On Thu, Dec 12, 2013 at 7:55 AM, Ryan Wilkins <ryan@deadfrog.net> wrote:

"They are a bit quirky but generally they work fairly well when configured and left alone."

That describes most every router ever made :) -Steve

On 12/11/2013 10:23 PM, Rob Seastrom wrote:

Eric Oosting <eric.oosting@gmail.com> writes:

...

It brings a tear to my eye that it takes:

0) A long standing and well informed internet technologist; 1) specific, and potentially high end, CPE for the res; 2) specific and custom firmware, unsupported by CPE manufacturer ... or anyone; 3) hand installing several additional packages; 4) hand editing config files; 5) sysctl kernel flags; 6) several shout outs to friends and coworkers for assistance (resources many don't have access to); 7) oh, and probably hours and hours twiddling with it.

just to get IPv6 to work correctly.

Yea, that's TOTALLY reasonable. Pretty much works out of the box on Mikrotik RouterOS if you are secure enough in your geek cred to admit to running such stuff here in this august forum.

-r

FYI - DHCP-PD is now working better in RouterOS 6.5 Prefix length hints are now available (CLI) only. /ipv6 dhcp-client add add-default-route=yes interface=<wan interface> pool-name=dhcp-pd \ prefix-hint=::/60 In the case of Comcast (and anecdotally ISC DHCP) - You'll either need to wait out the the lease time (4 days) or ask Comcast to nicely clear out your /64 lease manually. Release/renew doesn't release your current DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) before Comcast removed the /64 lease manually.

FYI - DHCP-PD is now working better in RouterOS 6.5

Prefix length hints are now available (CLI) only.

/ipv6 dhcp-client add add-default-route=yes interface=<wan interface> pool-name=dhcp-pd \ prefix-hint=::/60

I'd like to encourage people to use prefix-hint=::/48. The router should accept the /60 and deal with it, but it's better to have Comcast's logs show that you requested a proper full-size prefix. I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP.

In the case of Comcast (and anecdotally ISC DHCP) - You'll either need to wait out the the lease time (4 days) or ask Comcast to nicely clear out your /64 lease manually. Release/renew doesn't release your current DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) before Comcast removed the /64 lease manually.

Is it somehow harmful to have both? Owen

On Fri, Dec 20, 2013 at 5:42 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Fri, Dec 20, 2013 at 12:30 AM, Owen DeLong <owen@delong.com> wrote: ....

...

I'd like to encourage people to use prefix-hint=::/48. ... I think if I ask (via wide-dhcpv6-server) for more than is going to be sent I don't get anything configured at all :(

I'm pretty sure I get sent a /64 in the response packet, but I don't install that.. which leads to busted v6 configuration on my device.

I concur (with the request a /48, get a /64, not a /60). At least that is how I recall it used to work (I have not tried for some time at this point, and while I know Comcast has changed things in the interim, I am pretty sure I do not want to wait for Comcast to time out a /64 if that is what I end up getting). If someone has better information, I am willing to consider a test. Gary

On 12/20/13 7:36 AM, "Jamie Bowden" <jamie@photon.com> wrote:

...

From: Owen DeLong [mailto:owen@delong.com]

...

I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP.

No, no, no, a thousand times no. I'm sure RA is great for small SOHO networks and for ISPs as a means to hand out resources, but in a corporate environment, we hate you. How many times do the IPv6 people have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 is dead to enterprise networks?

"Parity" isn't enough information; what features are missing? RA is part of IPv6, but you don't have to use SLAAC. I'd say it's the DHC people who need to hear it, not the IPv6 people, but YMMV. Lee

Jamie

On 12/20/13 8:07 AM, "Jamie Bowden" <jamie@photon.com> wrote:

...

"Parity" isn't enough information; what features are missing? RA is part of IPv6, but you don't have to use SLAAC. I'd say it's the DHC people who need to hear it, not the IPv6 people, but YMMV.

I have a question. Why does DHCP hand out router, net mask, broadcast address, etc. in IPv4; why don't we all just use RIP and be done with it?

You don't have to like how enterprise networks are built, but you better acknowledge that they are their own animal that have their own needs and drivers, and telling them that the way their networks are built are wrong and they need to change their whole architecture, separation of service, security model, etc. to fit your idea of perfection isn't winning friends. You are, however, influencing people. Perhaps not in the manner you intended.

So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change? I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?" There are business reasons to run IPv6. The fact that it's different than IPv4 is not a reason not to use it. Lee

Jamie

On Dec 20, 2013, at 6:29 AM, Matthew Huff <mhuff@ox.com> wrote:

With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover.

RA and VRRP are not mutually exclusive. What you can’t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information.

In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment.

There’s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address. As such, can someone please explain what is the actual missing or problematic requirement for the corporate world? Owen

---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039

...

-----Original Message----- From: Lee Howard [mailto:Lee@asgard.org] Sent: Friday, December 20, 2013 8:25 AM To: Jamie Bowden; Owen DeLong; ml@kenweb.org Cc: North American Network Operators' Group Subject: Re: turning on comcast v6

On 12/20/13 8:07 AM, "Jamie Bowden" <jamie@photon.com> wrote:

...

...

"Parity" isn't enough information; what features are missing? RA is part of IPv6, but you don't have to use SLAAC. I'd say it's the DHC people who need to hear it, not the IPv6 people, but YMMV.

I have a question. Why does DHCP hand out router, net mask, broadcast address, etc. in IPv4; why don't we all just use RIP and be done with it?

You don't have to like how enterprise networks are built, but you better acknowledge that they are their own animal that have their own needs and drivers, and telling them that the way their networks are built are wrong and they need to change their whole architecture, separation of service, security model, etc. to fit your idea of perfection isn't winning friends. You are, however, influencing people. Perhaps not in the manner you intended.

So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change?

I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?"

There are business reasons to run IPv6. The fact that it's different than IPv4 is not a reason not to use it.

Lee

...

Jamie

On Dec 20, 2013, at 12:50 PM, Matthew Huff <mhuff@ox.com> wrote:

On Dec 20, 2013, at 3:23 PM, Owen DeLong <owen@delong.com> wrote:

...

On Dec 20, 2013, at 6:29 AM, Matthew Huff <mhuff@ox.com> wrote:

...

With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover.

RA and VRRP are not mutually exclusive. What you can’t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information.

...

In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment.

There’s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address.

As such, can someone please explain what is the actual missing or problematic requirement for the corporate world?

Owen

Reality.

Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you

Not all devices have working IPv6 stacks. OK, they’re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor.

do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6

Link Local gateway addresses are required functionality in IPv6. A device which requires a global gateway address is broken. See above.

compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the “advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network.

IPv4 didn’t work perfectly in the beginning either. Enterprises spent many years getting vendors to correct issues with their iPv4 products and we’re just starting that process with IPv6. I’m asking what’s broken in the protocol design since that’s what the IETF can attempt to fix.

For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much.

Sounds like you need to contact the vendors for that other equipment and get them to fix their IPv6 implementations. Owen

In message <CAL9jLaa=qKuMLC7djtMru92f3tQcYp3ehR060nRcfKg-ho+bKA@mail.gmail.com>, Christopher Morrow writes:

...

Not all devices have working IPv6 stacks. OK, they're broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor.

I don't know that this is a practical option... for say some systems I know that don't do v6 properly or at all, and which have buying cycles on the 10yr horizon, not 2yrs/etc.

And I hate to say it but people have been saying for over a decade. * request support IPv6 in the products you are purchasing. * test the IPv6 support. * report the bugs found so they can be fixed. This situation was foreseen. Too many people just left this for later and later is here now and the fixes will come too late for some.

BUT... so what? you can do v4/v6 on the same LAN, right? just only use the v4 bits for those devices?

I don't think 'eh, toss out your crap, buy new crap' is the right message to send. 'you can cohabitate, this isn't virginia' is though.

-chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Dec 20, 2013, at 14:27 , Matthew Huff <mhuff@ox.com> wrote:

You can request a fully working IPv6 implementation, but it's not going to stop a purchasing if it doesn't. If you are deciding between two vendors and one is better/cheaper and doesn't have IPv6 and you choose the other, it's likely you will be looking for another job. There is no strong justification for deploying IPv6 in a corporate enterprise currently. Corporate world is focused on the next quarter, not at a 10 year horizon.

Which is it? You need equipment that's right for the next 5-7 years, or, you need to focus on next quarter and not a "10 year horizon"?

We decided to roll it out for a number of reasons. One, we had time this summer. Two, we figured it would highlight inherent issues already in our environment (it did, and we found a few doozies), and finally it was a good intellectual exercise. We have it running on all over our desktops, and most of our servers (some issues with license management software and other legacy software prevents us from deploying it on all servers)

This seems wise. Hopefully you're working with your vendors on getting those issues resolved.

If we had an orderly shutdown of our IPv6 environment, there would be zero impact to the business. In fact, due to complexity issues, it would arguably we would arguably be better off without it. Perhaps in a few years things will be different. My bet is that even in 5 years, corporate adoption will be very small, maybe as low as 10%.

Maybe... However, what do you plan to do when your employees don't have IPv4 connectivity at home any more? That's likely going to either go away or get a lot more expensive in about 5-7 years. That's not just my prediction... Lee Howard has some pretty good information to back it up. Check out his presentation from the Denver Inet in April of this year. Owen

On Dec 20, 2013, at 4:51 PM, Mark Andrews <marka@isc.org> wrote:

...

In message <CAL9jLaa=qKuMLC7djtMru92f3tQcYp3ehR060nRcfKg-ho+bKA@mail.gmail.com>, Christopher Morrow writes:

...

...

Not all devices have working IPv6 stacks. OK, they're broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor.

I don't know that this is a practical option... for say some systems I know that don't do v6 properly or at all, and which have buying cycles on the 10yr horizon, not 2yrs/etc.

And I hate to say it but people have been saying for over a decade.

* request support IPv6 in the products you are purchasing. * test the IPv6 support. * report the bugs found so they can be fixed.

This situation was foreseen. Too many people just left this for later and later is here now and the fixes will come too late for some.

...

BUT... so what? you can do v4/v6 on the same LAN, right? just only use the v4 bits for those devices?

I don't think 'eh, toss out your crap, buy new crap' is the right message to send. 'you can cohabitate, this isn't virginia' is though.

-chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Dec 20, 2013, at 14:16 , Matthew Huff <mhuff@ox.com> wrote:

Owen,

Have you ever worked in a corporate environment? Replacing equipment can be a 5-7 year window and has to be justified and budgeted. Replacing a piece of equipment because it's an incomplete IPv6 implementation (which has changed considerably as it has been deployed), isn't feasible. There are a lot of things that have changed as IPv6 has been deployed such as DHCPv6 (not even talking about setting default GW via DHCP, but things such as DNS servers, DNS domain name, etc). Not all vendors especially ones in niche markets can update the firmwares that often, and certainly not unless they have a business justification.

Yes, I have. We've been advocating that people look at the IPv6 capabilities they need from their vendors, test, report bugs, and insist on working IPv6 implementations for more than 10 years now. The DHCPv6 RFC (3315) was published in July, 2003. DHCPv6 has not actually changed all that significantly and the provisions for DHCPv6 in RAs were standardized around the same time as RFC-3315. The most recent significant change in RAs I can come up with is RFC-6106 which is 2010, but it's entirely optional and just adds DNS search string capabilities to RFC-5006 which goes back to September, 2007. So unless you have a change you can point to that is more recent than 2007, I think we've got the 5-7 year thing pretty well covered. Owen

On Dec 20, 2013, at 4:07 PM, Owen DeLong <owen@delong.com> wrote:

...

On Dec 20, 2013, at 12:50 PM, Matthew Huff <mhuff@ox.com> wrote:

...

On Dec 20, 2013, at 3:23 PM, Owen DeLong <owen@delong.com> wrote:

...

On Dec 20, 2013, at 6:29 AM, Matthew Huff <mhuff@ox.com> wrote:

...

With RA, what is the smallest interval failover will work? Compare that with NHRP such as HSRP, VRRP, etc with sub-second failover.

RA and VRRP are not mutually exclusive. What you can’t have (currently) is routing information distributed by a DHCP server which may or may not actually know anything about the routing environment to which it is sending such information.

...

In corporate networks most of the non-client systems will be statically addressed with privacy addresses turned off. This is for regulatory, audit, security and monitoring requirement. One of the many challenges of ipv6 in a corporate environment.

There’s no problem doing this in IPv6. You can easily statically address a system and you can easily turn off privacy addresses. You can even do that and still get your default router via RA or you can statically configure the default router address.

As such, can someone please explain what is the actual missing or problematic requirement for the corporate world?

Owen

Reality.

Owen, not all OS and especially hardware appliances (dedicated NTP appliances, UPS cards, ILO), etc... will work with RA and static addresses. They just don't. Some OS's won't disable SLAAC unless you disable autoconf on the switch. When you

Not all devices have working IPv6 stacks. OK, they’re broken, complain to the vendor and get them to fix their product or buy a working product from a different vendor.

...

do that, they loose the ability to pickup RA. Some will only work with link local gateway addresses, some will only work with link global gateway addresses. There is a lot of cruft out there in the enterprise world that claims IPv6

Link Local gateway addresses are required functionality in IPv6. A device which requires a global gateway address is broken. See above.

...

compatibility, but in the real world doesn't work consistently. Almost all can be made to work, but require custom configuration. Far too much work for many organizations to see value in deployment. In at least on IT department I know of, IPv6 is banned because the CIO read about one of the “advantages" of IPv6 is bringing back the p2p model of IP, and most corporate management has zero interest in having any p2p connectivity within their network.

IPv4 didn’t work perfectly in the beginning either. Enterprises spent many years getting vendors to correct issues with their iPv4 products and we’re just starting that process with IPv6.

I’m asking what’s broken in the protocol design since that’s what the IETF can attempt to fix.

...

For our desktop environments (Windows 7 and RHEL6) we have two different configurations on the switches on separate VLANs using SLAAC with DHPCv6 and that works fine with RA announcing the NHRP. Other equipment, not so much.

Sounds like you need to contact the vendors for that other equipment and get them to fix their IPv6 implementations.

Owen

On Dec 20, 2013, at 14:44 , Eric Oosting <eric.oosting@gmail.com> wrote:

On Fri, Dec 20, 2013 at 5:16 PM, Matthew Huff <mhuff@ox.com> wrote: Owen,

Have you ever worked in a corporate environment? Replacing equipment can be a 5-7 year window and has to be justified and budgeted. Replacing a piece of equipment because it's an incomplete IPv6 implementation (which has changed considerably as it has been deployed), isn't feasible.

Not to put words in Owen's mouth, but let me explain how I interpret what he was saying: Vote with your feet.

It's simple ... maybe you can't replace everything in your network that doesn't support IPv6, ( I wish we all had that kind of discretionary budgets) but you can still base purchasing decisions on IPv6 support, and by and large, that isn't happening. Enterprise purchasing just isn't driven by IPv6 features ... if anything, its a check box feature for vendors and ignored by decision makers.

Until the enterprise says to the widget salesperson: "i'm not buying this until and unless you truly commit to supporting IPv6" we're stuck where we are.

We don't necessarily need you to replace everything in your network that doesn't support it today, we need you to not put a single thing in your network new, or used, that doesn't. Believe me, the vendors will get the message and suddenly even the legacy stuff will start to be fixed. Remember what a PITA it was to get novel to support IPv4? They didn't do it until they had to.

-e

Absolutely correct interpretation of my statement. Owen

On 12/20/2013 05:25 AM, Lee Howard wrote:

So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change?

Rather obviously the protocol designers, since they are clearly out of touch with real-world requirements. RA/SLAAC was a clever idea 20 years ago, and still has value for its original intended purpose, putting dumb clients on the net. However in the time since IPng DHCP won the day. Enterprises have their own administrative structures that work with v4, and see no reason to have to change them to accommodate the lofty goals of the IPv6 luminati. Keep in mind that the vast majority of enterprises are happy with their v4 NATs, aren't affected by address exhaustion issues, and have no reason to move to v6.

I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?"

Apples and cumquats.

There are business reasons to run IPv6. The fact that it's different than IPv4 is not a reason not to use it.

... except that enterprises have been saying for over a decade that full-featured DHCP is a requirement before they will even look at v6. Not to mention the inherent insecurity of RA/SLAAC, which has yet to be robustly addressed. Yes, rogue DHCP servers are still possible, but the effects are more manageable and arguably easier to mitigate; not to mention the better security for this that is built into most modern networking gear already. Doug

On Fri, Dec 20, 2013 at 5:25 AM, Lee Howard <Lee@asgard.org> wrote:

On 12/20/13 8:07 AM, "Jamie Bowden" <jamie@photon.com> wrote:

...

...

"Parity" isn't enough information; what features are missing? RA is part of IPv6, but you don't have to use SLAAC. I'd say it's the DHC people who need to hear it, not the IPv6 people, but YMMV.

I have a question. Why does DHCP hand out router, net mask, broadcast address, etc. in IPv4; why don't we all just use RIP and be done with it?

You don't have to like how enterprise networks are built, but you better acknowledge that they are their own animal that have their own needs and drivers, and telling them that the way their networks are built are wrong and they need to change their whole architecture, separation of service, security model, etc. to fit your idea of perfection isn't winning friends. You are, however, influencing people. Perhaps not in the manner you intended.

So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change?

I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?"

default route information via DHCPv6. That's what I'm still waiting for. Matt

On Tue, 24 Dec 2013, Lee Howard wrote:

...

...

I used to run an enterprise network. It was very different from an ISP network. I didn't say, "You're wrong!" I said, "What's missing?"

default route information via DHCPv6. That's what I'm still waiting for.

Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why?

DHCPv6 + RA works for that, but still, that really should have been part of the protocol from day one. I see no good reason for it not to be in there. I suspect that will eventually be fixed, but it will be a long time before the majority of DHCPv6 client and server implementations are upgraded to support it. jms

On 12/30/13 11:19 AM, "Leo Bicknell" <bicknell@ufp.org> wrote:

On Dec 24, 2013, at 8:15 AM, Lee Howard <Lee@asgard.org> wrote:

...

Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why?

Why must the people who want it justify to _you_?

They don't; they have to justify it to the DHC WG at IETF, in order to generate consensus.

This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to where it is by letting people extend it and develop new protocols and solutions. DHCP did not exist when IPv4 was created, it was tacked on later. Now people want to tack something on to IPv6 to make it more useful to them. Why do they need to explain it to you, if it doesn't affect your deployments at all?

You can provision your network any way you like. If you want to create a custom version of DHCP (or your own provisioning protocol), that's fine. There doesn't seem to be consensus that default gateway in DHCP is a good idea. There's "running code" for how to change this.

Some of us think the model where a DHCP server knows the subnet and hands out a default gateway provides operational advantages. It's an opinion. And the current IPv6 crowds view that not having a default route and relaying on RA's is better is also an opinion.

We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put it in their, and let the market sort it out, unless you can justify some dire harm from doing so.

I don't like the "let many flowers bloom" model of protocol development. You end up with a lot of cruft in protocols. Successful protocols tend not to have that (at least, when they become successful). I don't know if it will do harm (though it's easy to imagine DHCP not aligning with default gateways in modern, more mobile networks). But if the barrier for adding fields is "Eh, it probably won't cause dire harm" then we would have pretty messy protocols.

What is more important fast IPv6 adoption or belittling people who want to deploy it in some slightly different way than you did?

Did I belittle anybody? I apologize if I did that. It certainly was not my intent. I'm trying to understand a point of view. Lee

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Dec 30, 2013, at 3:43 PM, Owen DeLong <owen@delong.com> wrote:

The current situation isn’t attributable to “the current IPv6 crowd” (whoever that is), it’s the current IETF consensus position. Changing that IETF consensus position is a matter of going through the IETF process and getting a new consensus. That requires justifying your position and convincing enough people willing to actively participate in the working group process of that position.

Some of us tried to engage the IETF on this topic in multiple working groups. If you search the archives you'll find this topic has come up before. I would charitably describe the environment there as "hostile" to anyone who has not been inside the IEFT machine for the last 15 years. And that's assuming the working group is "working", there are plenty inside the IEFT that are extremely dysfunctional even when the people on them "agree". It's not enough to tell a bunch of enterprise people who have never dealt with the IETF before that they should go there are plead their case. Most do not know how, and the few who try find themselves berated by that community for being ignorant of the "way things should be". What the enterprise folks need is IPv6 champions, like yourself, like Lee, to user stand their use case that even if you don't end up deploying it on your own network you will show up at the IETF, or at least participate on the IETF mailing lists and help them get what they need, so IPv6 deployment can proceed apace. If you really don't think there is harm, help them go get what they (think they?) need. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Dec 30, 2013, at 7:51 PM, Owen DeLong <owen@delong.com> wrote:

I have yet to see a use case from enterprise that actually requires RIO or default route in DHCPv6, and I have seen many many use cases.

Most of them are, actually, better solved through education, so I tend to focus my efforts in that area.

If you can find someone who wants to pay me to plead the enterprise cases to the IETF, I suppose I might be interested in that job if it came with the right offer, but for now, that’s not what I get paid to do.

The kinky layer-2 stuff I've seen some places do tells me they won't be able to deploy IPv6 without it. I think the key here is "feature parity" and the whole "96 more bits no magic" aspect. The option is low hanging fruit to solve a problem. Perhaps it's just a conceptual problem (eg: DHCPv4 gives me option #4. I should have a comparable option# in IPv6!). While I may not need option #37 (or folks may not use it), sending a RS in addition to DHCPv6 request is two steps in host configuration, whereas one should be able to suffice (perhaps). It's also about authorization though, I could get a RA back from the RS from an unexpected (rogue) device in the same way I could see a rogue DHCP response as well. I have logging on my DHCP server, but I don't have that capability from a RA/RS stance. One is central (but perhaps relayed), the other is local (and never relayed). Seems a lot of emails over something simple that's not much creep and just "parity". (enjoy other great options here: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.... .. I need my quotes server for IPv6 via DHCPv6 too). - Jared

On Dec 24, 2013, at 8:15 AM, Lee Howard <Lee@asgard.org> wrote:

...

default route information via DHCPv6. That's what I'm still waiting for.

Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why?

Lee

There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6. 'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything. Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use. /Ryan

On Dec 30, 2013, at 12:58 PM, Lee Howard <Lee@asgard.org> wrote:

...

'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything.

Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, "Make sure you call IP family agnostic libraries and increase field sizes, then let it run" and "Rebuild your network security." DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network.

Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. /Ryan

I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. From: Blake Dunlap <ikiris@gmail.com> Date: Monday, December 30, 2013 3:19 PM To: Ryan Harden <hardenrm@uchicago.edu> Cc: Lee Howard <Lee@asgard.org>, Jamie Bowden <jamie@photon.com>, "nanog@nanog.org" <nanog@nanog.org> Subject: Re: turning on comcast v6

The better question is are you using RIP or ICMP to set gateways in your network now?

I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of.

If you don't use those now, why is RA a better solution in ipv6?

It's built into the fundamentals of IPv6, using the Neighbor Discovery Protocol. It's supported in every stack. It's the default mode of operation. To turn it off, you have to disable part, but not all, of NDP. (Do you also turn off RSs on all hosts?) There could be better solutions; I would like to understand how they are better. Again, in your network, you can do whatever you want. If you want something different standardized, then you need consensus here: https://www.ietf.org/mailman/listinfo/dhcwg Lee

On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh <victor@jvknet.com> wrote:

On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard <Lee@asgard.org> wrote:

...

...

The better question is are you using RIP or ICMP to set gateways in your network now?

I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of.

[VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration).

There was a time, I'm going to roughly guess approximately 1987-1992, although I may be off by a year or two, that you needed to have lived through for this to make sense. You see, in that time the available IGP was, well, RIP. RIPv1. Routers, at least ones you could buy, did not have OSPF, EIGRP, or even in many cases EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. So almost every campus network ran RIPv1. This is also pre-CIDR, so remember every subnet had to have the same mask. For instance the University I went to had a /16, divided into entirely /22 networks for each LAN. The RIP config enabled it for the entire /16. Certain vendors, like Sun (who was popular at the time) shipped SunOS boxes with routed enabled by default, where they received a default route (if the admins filtered) or a full (local) table via RIPv1. In short, there was a time when getting a default route via RIP was in fact common. It was also the time of telnet, and rsh, decidedly pre SSL, ssh, or IPSEC. It was also a time when the Internet came under heavy, well, attack, by people who realized how soft and squishy it was. Injecting a route into RIP allowed you to hijack rsh sessions, for example. Lots of people who were admins at that time learned through personal pain and late night hacking that sending a dynamic route to a box via an unauthenticated protocol was a recipe for disaster. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

The reason RIP isn't used to hand out routes is not based on age, or protocol design. It's based on the fact that we don't want host segment routes (usually only default) to be announcement based, because that leads to problems and uncomfortable meetings with VPs. DHCP will happily give out a correct gateway that can be managed using some FHRP, or not, and those few (new to the network) users can reboot once it's fixed. The key is it is controlled and can't be just hijacked at a moment's notice. All we've gained by switching to RA is a security hole that must be managed at the L2 level, and the ability to use a slower method of failover than FHRPs purely so we aren't reliant on a single ip address, and the vauge notion that somehow the network and the dhcp server could possibly get out of sync, and that's somehow a worse problem than losing the entire network randomly due to bad/inept actors and either a lack of security, or a security vulnerability. Personally I don't see the trade offs as beneficial, and you also lose the ability to differentiate gateways by host from central control (even though you'd rarely see this done as opposed to separate vlans). -Blake On Mon, Dec 30, 2013 at 10:40 PM, Victor Kuarsingh <victor@jvknet.com>wrote:

On Mon, Dec 30, 2013 at 6:31 PM, Leo Bicknell <bicknell@ufp.org> wrote:

...

On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh <victor@jvknet.com> wrote:

...

On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard <Lee@asgard.org> wrote:

...

...

The better question is are you using RIP or ICMP to set gateways in your network now?

I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual

configuration,

...

...

...

adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of.

[VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration).

There was a time, I'm going to roughly guess approximately 1987-1992, although I may be off by a year or two, that you needed to have lived through for this to make sense.

You see, in that time the available IGP was, well, RIP. RIPv1. Routers, at least ones you could buy, did not have OSPF, EIGRP, or even in many cases EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. So almost every campus network ran RIPv1

[VK] Leo, I understand the case you mention, but I am not sure if this is a parallel to what the subject is on this thread. I would think we are talking - not about routers and servers here - but end hosts (PCs, tablets, home gateways, smart phones, media devices etc.) which would be the beneficiaries of the [DHCPv6] route option information.

I still don't think that RIP's prevalence in 20+ year old network environments, and it's lack of use today, draws a comparison to the validity of using RAs. I get that it [RIP] may have been "default" on may historic boxes, so had similar effect on providing a default route, but the protocol's purpose was not intended to do that for all the hosts on a network (also a world where not all networks were IP as well).

RA on the other had was specifically purposed to be used to provide this kind of information to all IPv6 stacks. So I still think we are talking about very different environments in protocol types, purpose and mixture of participating hosts/routers etc.

regards,

Victor K

You can accomplish the same thing in IPv4…. Plug in Sally’s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network. Yes, you have to pay attention when you plug in a router just like you’d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. Incompetence in execution really isn’t the protocol’s fault. Owen On Dec 30, 2013, at 3:24 PM, Leo Bicknell <bicknell@ufp.org> wrote:

On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee@asgard.org> wrote:

...

I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing.

I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration.

Configure up a simple network topology of three boxes representing a hub and spoke network:

DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan

Number it up as expected for both protocols:

wan links: IPv4 /30, IPv6 /64 lan links: IPv4 /24, IPv6 /64

Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to it. Verify a machine plugged into either of the LANs gets a fully functional network for both protocols.

Now, take r1 turn it off, and stick it in a closet. You see, that office closed. Normal every day thing.

Plug up two PC's to the remaining LAN off r2. This represents your desktop, and your neighbors desktop. Think Bob from accounting perhaps. Open two windows on each, one with an IPv4 ping, one with an IPv6 ping running.

Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on.

Here's what you will soon find:

1) The IPv6 pings on both machines cease to work.

2) The IPv4 network continues to work just fine.

Now, for even more fun, turn on another PC, say Sally from HR just rebooted her machine. It will come up in the same state, IPv6 not working, while IPv4 works just fine.

Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are now complaining to him that their network is down, again. Make sure you not only understand the technical nuances of why the problem above happened, but also how to explain them to a totally non-technical CEO.

(Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how long until the pings start working again. I think it's 15 minutes, IIRC. For super-extra credit tell me how to make that time shorter for everyone on the LAN with Cisco or Juniper commands on r2.)

I'll give you a hint on understanding this issue. The IETF's grand solution is to replace every ethernet switch in your entire network with new hardware that supports "RA Guard", and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6.

Now do you understand why people just want to put the route in DHCPv6 and move on?

It's not a "feature" that's different between the two, it's that operationally they have entirely different attack surfaces and failure modes. And yes, it involves people doing stupid things. However if the IETF is going to rely on smart people deploying networking devices we might as well give up and go home now.

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On 12/30/2013 8:16 PM, Leo Bicknell wrote:

There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's. These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option.

The more disturbing "feature" for those that have been there, done that, debugged the meltdown, and tried to avoid repeating the issue is the growing proliferation of "automatic" discovery/configuration... whether RA / SLAAC / mDNS / Bonjour / uPnP / (the list goes on...). There are too many opportunities for spoofing / MITM / self-propagating "issues". Yes, DHCP is prone to similar issues, but better to focus on "one" service and "one" authoritative source to try to lock down than to try to protect the plethora of growing options to introduce issues from arbitrary sources. But as the market focus appears to continue to try to address the home / SOHO environment of naive users, the "self-configuration" nastiness continues to propagate. It may fit at home / SOHO, but not in the Enterprise, and certainly not in a university environment where you can't be as "restrictive" on a universal basis as you might like to be :( Jeff

I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme. And, regardless of the protocol in question, represent attacks which should be defended against. As is often (always?) the case, there are tradeoffs - and the pros and cons of those tradeoffs will be weighted differently by different parties. /TJ On Jan 3, 2014 12:00 AM, "Matthew Kaufman" <matthew@matthew.at> wrote:

On 12/30/2013 4:56 PM, Owen DeLong wrote:

...

You can accomplish the same thing in IPv4….

Plug in Sally’s PC with Internet Connection Sharing turned on and watch

...

DHCP server takes over your network.

Not nearly as fast as bad RAs do (as others have pointed out).

...

Yes, you have to pay attention when you plug in a router just like you’d

have to pay attention if you plugged in a DHCP server you were getting ready to recycle.

But the ability to plug in a not-router and break things is oh so much greater.

...

Incompetence in execution really isn’t the protocol’s fault.

But it is the protocol designer's fault... and once shipped, the

as her protocol's fault. There's all sorts of things that were known at the time IPv6 was designed that the designers failed to build solutions for. As an example, routers *could* be a lot smarter about sending RAs on a network where routers are already present, but that's not in the spec.

Neither the ND DOS attack nor the need to protect against bogus RAs on

every port of your switch but one (or rarely, two) are things that should have been a post-deployment surprise (to name just a couple pet peeves of mine... there's more design flaws that could have been easily avoided had enough people cared to do so).

Matthew Kaufman

On Fri, Jan 3, 2014 at 9:40 AM, Doug Barton <dougb@dougbarton.us> wrote:

On 01/02/2014 10:30 PM, TJ wrote:

...

I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme.

Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don't.

The IPv6 protocol does not give you such an ability (by accident - a hacker can steal your IPv4 network too with your completely unprotected network). There seems to be a lack of detailed understanding of the RFCs in this thread. Adding a new router to an already running network will add a second router to all clients. But no clients will actually switch to the new router unless the old one fails. That is the behavior specified in the RFC. Actual implementations might do something different, but that is hardly the fault of the protocol designer. Have anyone here actually tested this, or are we just making up stuff? Another person claimed that there would be 15 minuttes or more until the network was fixed, after removing a rogue router. That too is completely wrong. Every client will monitor the currently used router. If it stops responding for 30 seconds, the clients will switch to an alternative router. Also, routers are supposed to monitor their uplink. If the uplink is down, no RA should be sent on the downlinks and any current active prefixed should be withdrawn. Not all routers implement this, but at the least the CPEs are starting to do it correctly. This whole thread builds on the assumption that you are using equipment with either bad implementation or bad configuration. Blocking RA from client ports is just one simple ACL rule on the switch. Many vendors have a very simple option to enable it. You are not running a clean ship if you skip this, just the same as you are required to block DHCP servers from client ports. Regards Baldur

On Fri, Jan 3, 2014 at 10:24 AM, Doug Barton <dougb@dougbarton.us> wrote:

... and yet most IPv4 networks are not "completely unprotected."

We are apparently talking about "completely unprotected" networks here. Otherwise there is simply no problem. You would be filtering RA and many other things, because that is best practice and required by many security standards besides.

... which is simple to accomplish with a DOS, even if the clients implement the protocol correctly.

If we are on an unprotected network and we have evil intend, all is lost. The hacker can simply steal the traffic with a simple arp ping or a ton of other methods. The original claim was not evil intend, but that of an accident. But it still requires three mistakes: bad clients, bad routers and bad configuration.

That is the behavior specified in the RFC. Actual implementations might do

...

something different, but that is hardly the fault of the protocol designer. Have anyone here actually tested this, or are we just making up stuff?

It's been demonstrated several times at various venues, including at least 1 IETF meeting.

Doesn't work when I try it. The clients just keep using the old gateway and prefix. But I can't rule out there are bad clients out there, just that it does not happen on my network. Can you give any examples of bad clients?

Another person claimed that there would be 15 minuttes or more until the

...

network was fixed, after removing a rogue router. That too is completely wrong. Every client will monitor the currently used router. If it stops responding for 30 seconds, the clients will switch to an alternative router.

Again, you're assuming that the clients implement correctly, however I think this one is more common than not since this behavior has been prescribed long enough now.

This one is something that all major clients have correctly by now. It is a rather common use case for IPv6 after all. The user connects two gateways to his network and gets carefree automatic failover with a 30 seconds timer to detect failure. May not be good enough for your enterprise network, but sure is quite useful in the SOHO environment. And you still haven't provided an argument about why the default route

...

should not be added to DHCPv6.

I was not arguing that it didn't. Just that the perceived problem is not real. However, I might be inclined to believe that default route in DHCPv6 is a bad idea. It is a confusing concept, since we already no less than three methods (*) to discover default route and you want to add a fourth. This would be something that needs to be implemented in every client, and thus will not really be usable for at least a decade. By then everyone are used to RA. If you did add default route to DHCPv6, what is then supposed to happen to the other routes, that the client might discover? By the arguments in this thread, you do not really want default route from RA, but instead some security mechanism, that would prevent the client from obtaining routes and prefixes in addition to the one you provided. That seems to be a completely different issue. (*) prefix::, fe80:: and the one you get from RA. Regards, Baldur

On Sat, Jan 4, 2014 at 2:12 AM, Doug Barton <dougb@dougbarton.us> wrote:

...

If you did add default route to DHCPv6, what is then supposed to happen to the other routes, that the client might discover?

You would configure the client not to do RS, and to ignore any RAs that it receives. Simple.

If you are going to modify the client, you can use any method you like, including having the client simply use fe80:: or prefix:: as default gateway. You want a secure way to configure the clients. That sounds more like Secure NDP (SEND) than it sounds like DHCPv6 with default gateway. Regards,

On Jan 6, 2014, at 10:37 , Doug Barton <dougb@dougbarton.us> wrote:

On 01/04/2014 05:42 AM, Baldur Norddahl wrote:

...

On Sat, Jan 4, 2014 at 2:12 AM, Doug Barton <dougb@dougbarton.us> wrote:

...

...

If you did add default route to DHCPv6, what is then supposed to happen to the other routes, that the client might discover?

You would configure the client not to do RS, and to ignore any RAs that it receives. Simple.

If you are going to modify the client, you can use any method you like,

No, I can't, because the method I would like to use is not in the spec.

Doesn't have to be... You can create any local DHCPv6 extension you like. That _IS_ in the spec. Owen

On Jan 3, 2014, at 12:40 AM, Doug Barton <dougb@dougbarton.us> wrote:

On 01/02/2014 10:30 PM, TJ wrote:

...

I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme.

Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don’t

Not entirely true, actually… If you’re willing to work hard enough at it, most hosts can be “encouraged” to renew early.

Further, by far the common case is for network gear to _already_ be configured to avoid permitting hosts to act as DHCP servers unless they are supposed to be. It's rare to even find a network device that has RA Guard capabilities, never mind one that has them turned on.

Well… Sure, 15 years after DHCP attacks first started being a serious problem… I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc.

There is simply no good reason not to include default route in the configuration for DHCPv6, and it's long overdue.

As I’ve said before, if we’re going to bother doing it, we should just include RIO options, but otherwise, I agree with you. Owen

...

...

There is simply no good reason not to include default route in the configuration for DHCPv6, and it's long overdue.

As I've said before, if we're going to bother doing it, we should just include RIO options, but otherwise, I agree with you.

Are DHCPv6 and/or NDP extendible for other stuff? For example, in IPv4, Cisco uses DHCP option 150 for advertising Callmanager addresses in their IP Telephony networks. I've been out of the Cisco IPT side of stuff for awhile, but wondered how that has been tackled. And I think things like NTP addresses have been delivered in DHCP packets. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

For IPv6, you can become a/the router for a segment with the origination of a single packet. Instantly. That’s something you can never do with DHCPv4.

A router, yes. THE router, not unless the network is very stupidly put together.

...

Well… Sure, 15 years after DHCP attacks first started being a serious problem… I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc.

It'll **NEVER** be a default because it breaks too many clueless people's networks. Just like, surprise, DHCP "guard" isn't on by default in any gear I'm aware of.

I disagree. Unlike with DHCP guard, RA guard can make reasonable predictions in most cases. Switches with “uplink” ports designated, for example, could easily default to permitting RAs only from those ports. Owen

On Jan 6, 2014, at 12:57 , Ricky Beam <jfbeam@gmail.com> wrote:

On Sat, 04 Jan 2014 14:03:21 -0500, Owen DeLong <owen@delong.com> wrote:

...

A router, yes. THE router, not unless the network is very stupidly put together.

Like every win7 and win8 machine on the planet? (IPv6 is installed and enabled by default. Few places have IPv6 enabled on their LAN, so a single RA would, indeed, 0wn3z those machines instantly.)

The obvious solution to that is to install real IPv6 routers.

...

I disagree. Unlike with DHCP guard, RA guard can make reasonable predictions in most cases. Switches with “uplink” ports designated, for example, could easily default to permitting RAs only from those ports.

One cannot **GUESS** the security for a network. You must either *know* or *not know* what's on a port. What makes a port "uplink" (read: "trusted")? The only way to know for sure, without creating surprises or exploitable holes, is make the ADMIN explicitly SET EACH PORT. That's the way DHCP Guard works. That's the way spanning-tree portfast, bpdu guard, root guard, etc., etc. works. That's the way port security works. And that's the way RA Guard WILL be done.

The port isn't particularly trusted, but it is allowed to send RAs which are forwarded to the network by default. Obviously a sane switch would allow this configuration to be changed. We're not talking about the security model for a network, we're talking about the default behavior of a switch. Defaults are, inherently guesses to some extent. Nonetheless, a switch must have some default behavior. It seems to me that in the case of switches which have otherwise designated uplink ports, it is logical to make those ports default to RA allowed while defaulting to not allowing RAs from other ports by default. Owen

On Jan 6, 2014, at 13:22 , Paul Ferguson <fergdawgster@mykolab.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 1/6/2014 1:08 PM, Owen DeLong wrote:

...

The port isn't particularly trusted, but it is allowed to send RAs which are forwarded to the network by default. Obviously a sane switch would allow this configuration to be changed. We're not talking about the security model for a network, we're talking about the default behavior of a switch.

Defaults are, inherently guesses to some extent. Nonetheless, a switch must have some default behavior.

It seems to me that in the case of switches which have otherwise designated uplink ports, it is logical to make those ports default to RA allowed while defaulting to not allowing RAs from other ports by default.

Some people do not want switches making IP address assignments. That's all. :-)

Huh??? I don't think I said anything even remotely like that. Owen

On Jan 3, 2014, at 7:52 PM, Owen DeLong <owen@delong.com> wrote:

Well… Sure, 15 years after DHCP attacks first started being a serious problem… I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc.

I count over a dozen ethernet switches in my home that do not have DHCP guard. Indeed, half of them do not have a management interface at all. Even my "business class cable modem" does not implement DHCP guard on it's integrated switch. I also don't know of a single device, from any vendor, that turns DHCP guard on by default. I'd appreciate pointers if there is one. I know a half dozen people sent some form of "don't do that" when I gave the example of plugging in a "rogue" router with my corporate scenario. Maybe in a corporate scenario that's plausible, there will be intelligent admins (ha!). What happens when Joe Home User buys a new Linksys and wants to plug it in to get a firmware update before installing it? Are we really supposed to expect that every Joe Homeowner understands RA Guard and configures it for their home network? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Jan 5, 2014, at 11:44 PM, Valdis.Kletnieks@vt.edu wrote:

If Joe Home User has a rogue device spewing RA's, he probably has a bigger problem than just not having RA Guard enabled. He either has a badly misconfigured router (and one that's disobeying the mandate to not RA if you don't have an uplink), or he has a compromised malicious host.

In either case, he's got bigger fish to fry.

"mandate" isn't the right description. http://tools.ietf.org/html/rfc6059 There is a ~3 year old _proposed standard_ for the behavior you describe. I have yet to see any compliant equipment at $LocalBigBox, but maybe I'm not purchasing the right gear. So yet again, the response I get to "ra's are fragile" is "deploy this brand new band-aid that can't be purchased yet". Can we just have DHCPv6, please? How many dozens of technologies are we going to invent to try and avoid putting a default route in DHCP? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Jan 3, 2014, at 12:30 AM, TJ <trejrco@gmail.com> wrote:

I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme.

Rogue RA's can take down statically IPv6'ed boxes. Rogue DHCP servers will never affect a statically configured IPv4 box. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

Hi, On Thu, Jan 02, 2014 at 08:57:14PM -0800, Matthew Kaufman wrote:

On 12/30/2013 4:56 PM, Owen DeLong wrote:

...

You can accomplish the same thing in IPv4?.

Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network.

for the record it should be noted that this particular issue was fixed by Microsoft a while ago (see http://support.microsoft.com/kb/2750841/en-us). best Enno

Not nearly as fast as bad RAs do (as others have pointed out).

...

Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle.

But the ability to plug in a not-router and break things is oh so much greater.

...

Incompetence in execution really isn?t the protocol?s fault.

But it is the protocol designer's fault... and once shipped, the protocol's fault. There's all sorts of things that were known at the time IPv6 was designed that the designers failed to build solutions for. As an example, routers *could* be a lot smarter about sending RAs on a network where routers are already present, but that's not in the spec.

Neither the ND DOS attack nor the need to protect against bogus RAs on every port of your switch but one (or rarely, two) are things that should have been a post-deployment surprise (to name just a couple pet peeves of mine... there's more design flaws that could have been easily avoided had enough people cared to do so).

Matthew Kaufman

-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de =======================================================

Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on.

Why are you putting a router that you know needs to be reconfigured onto a production network? This could backfire regardless of IPv6, since you could have a similar issue if the router was performing DHCP from a locally configured pool. If someone did this and complained to me I would tell them they just learned a lesson and now know better then to go connecting equipment with an existing configuration to a production network without doing a full review first.

On Dec 31, 2013, at 12:36 PM, Tony Hain <alh-ietf@tndh.net> wrote:

likely pointless. Do you really believe that dhcp messages picked up by the rogue router wouldn't end up answering with the wrong values and breaking both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4 aware switch will do anything when an IPv6 DHCP message goes by? Don't you have to replace every switch and reconfigure anyway? Or is rogue DHCP service a problem that goes away with IPv4? Why do people continue to insist that a cornerstone of their network security model is tied to an inherently insecure protocol that was never intended to be used as a security tool? ... but I digress …

In the scenario I described, which I suggest is extremely common, the rogue router will not provide any DHCPv4 client with an address, ever. It is configured to forward to a DHCP sever, and based on the steps I suggested it has no route to reach it. It will forward the packet out its down uplink, and never get a reply. It is in fact 100% benign. Let me repeat, it's 100% benign, and will not affect any users, ever. Yes, if the router has a local DHCP server there would be an issue. But that's not actually very common, most of the people running DHCP want a central server and the logging that goes along with it. I'll admit my scenario was contrived, constructed to specifically show ONE aspect of the problem. It is not the only operational issue, but it is one that is easy for engineers to understand and replicate. However, it's also common. I know multiple people who shot themselves in the foot in this very way, with operational networks. It's not a theoretical problem, it's one that happens every day. Here's another problem that happens every day in data centers and offices. Someone accidentally bridges two VLAN's together for a few minutes by plugging in a cable to the wrong port, realizing it and then unplugging it. In an IPv4+DHCPv4 world the majority of the time the impact is, well, NONE. No hosts notice. Some switches compute a new spanning tree adjacency and some broadcast traffic goes where it shouldn't, but everything remains operational. Do the same with IPv6 and all of the hosts on one of the two VLAN's will instantly stop working. There are controlled environments, like a single tenant data center where a rogue DHCP server is simply not a security concern, but where a tech accidentally bridging VLAN's is a very real possibility. The fact of the matter is that the scale, scope, and impact from a rogue DHCP server is entirely different from a rogue RA server. IPv4+DHCP is operationally much more robust in the face of various scenarios, where as IPv6+RA pretty much always results in near instantaneous 100% failure.

Unfortunately there have been too many voices demanding a 'one size fits all' approach within the IETF, and we have gotten to the current situation where you need to deploy parts of both models to have a functional network. RFC 6106 is a half-baked concession from the 'dhcp is the only true way' crowd to allow home networks to be functional, but if you want anything more than DNS you have to return to the one-true-way, simply because getting consensus for a more generic dhcp-options container in the RA was not going to happen. The Routing Information DHCP option has been held hostage by those that might be described as a 'dhcp is broken by design' crowd, because many saw that as a bargaining point for consensus around a more feature rich RA. Both hard line positions preventing utility in the other model are wrong, but in the presence of a leadership mantra of one-size-fits-all, neither side was willing to allow complete independent functionality to the other.

I think you describe the IETF situation reasonably well. The internal bickering between the "RA camp" and the "DHCP camp" have largely prevented either one from producing something robust.

Making progress on the Routing Information option requires a clear scenario to justify it, because vast swamp of dhcp options that have ever been used in IPv4 are not brought forward without some current usage case. Lee was asking for that input, and while the scenario you paint below might be helped by that option, it presumes that every device on the network has additional configuration to ignore an errant RA sent from the router being configured simply because the network is supposed to using DHCP.

This is some extremely circular logic. We can't have DHCP until there are options in devices to ignore RA's. We can't have an option to ignore RA's in devices, because at the moment RA's are the only way to get a default route so it doesn't make sense. Someone has to go first, the other side will follow. I suggest it makes a lot more sense to get working DHCP, before pressuring end-user boxes to have an option or even default to ignoring RA's. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Dec 30, 2013, at 10:04 AM, Ryan Harden <hardenrm@uchicago.edu> wrote:

On Dec 24, 2013, at 8:15 AM, Lee Howard <Lee@asgard.org> wrote:

...

...

default route information via DHCPv6. That's what I'm still waiting for.

Why? You say, "The protocol suite doesn't meet my needs; I need default gateway in DHCPv6." So the IETF WG must change for you to deploy IPv6. Why?

Lee

There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6.

While I do not oppose the inclusion of Routing Information into DHCPv6, I have to say that this seems to be one of the weaker arguments. Please permit me to repeat your statement from an IPv6 perspective… Because many places have poorly thought out cruft that deals with deficiencies in IPv4 by doing stunts that won’t work in the current IPv6 implementation and because we don’t want to rewrite our cruft to take advantage of the cleaner solutions available for these problems in IPv6, we demand that you include the cruft from IPv4 into IPv6 in order to support this hackery.

'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything.

You have to rewrite all your tools to handle the bigger addresses anyway. While you’re at it, why not rewrite them to take advantage of cleaner solutions?

Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use.

So you’re defending a position you don’t share? Interesting tactic. Owen

On Dec 31, 2013, at 1:10 AM, Timothy Morizot <tmorizot@gmail.com> wrote:

I've been in the process of rolling out IPv6 (again this night) across a very large, highly conservative, and very bureaucratic enterprise. (Roughly 100K employees. More than 600 distinct site. Yada. Yada.) I've had no issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 model. In fact, the IPv6 model has generally been much more straightforward and easy to implement.

So I'm a large enterprise operator, not an ISP. Convince me. Because I don't see any need. And if I don't, I'm hard-pressed to see why the IETF would.

Scott

I haven't seen anyone in this thread argue that DHCPv6+RA doesn't work. So we'd all expect that you'd do just fine deploying that way for your large enterprise. The point is that there are some (And based on the thread here and over at IPv6-OPS, not just a couple) operators who wish or are required to do things differently. I remember thinking how stupid it was we had to either statically configure or run DHCPv6 (which a lot of clients didn't support) for the sole purpose of handing out name servers, then we finally got around to RFC6106. There were lots of people who just couldn't understand why you'd ever want your router handing out name servers/dns search lists. Sure DHCPv6 was/is the 'right' and 'clean' way to do it, but it shouldn't be required to make IPv6 functional. Clearly the IETF agreed, eventually. IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't trying to tell you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way they do IPv4. /Ryan

On Dec 31, 2013, at 2:16 PM, Tony Hain <alh-ietf@tndh.net> wrote:

Ryan Harden wrote: ...

...

IMO, being able to hand out gateway information based on $criteria via DHCPv6 is a logical feature to ask for. Anyone asking for that isn't

...

you that RA is broken, that you're doing things wrong, or that their way of thinking is more important that yours. They're asking for it because they have a business need that would make their deployment of IPv6 easier. Which, IMO, should be the goal of these discussions. How do we make it so deploying IPv6 isn't a pain in the butt? No one is asking to change the world, they're asking for the ability to manage their IPv6 systems the same way

trying to tell they

...

do IPv4.

As I said in the response to Leo, this issue has been raised before and couldn't get traction because the combination of a one-size-fits-all mantra from the leadership with concession such that the dhcp model would be self-contained, would have led to the end of the RA model. You are correct, neither way is better, and both need to operate independently or in combination, but getting there requires a clear use case, or many similar cases, to make progress.

I believe you are correct in that many people do use the dhcp option to assign the router, but quantifying that is a very difficult task because that community rarely worries about driving standards to get their way. I find that most of this community finds innovative ways to reuse tools defined for a different purpose, but its close enough to accomplish the task at hand while avoiding the cost of getting a vendor to build something specific. That is all fine until the original backer of the tool goes a different direction, and ongoing evolution requires someone to justify its continued support. The scattered community has so many different corner-case uses it is hard to make a clear and quantified need for what the tool should become.

The primary reason that this is even a discussion is that the decision was made long ago in the DHCP WG to avoid bringing forward unused baggage from the evolution of IPv4 and dhcp by not bringing any options forward until someone documented an ongoing use for it. That remains the only real requirement I am aware of for getting a dhcp option copied forward from IPv4 to IPv6; document a widespread use case. This one has had an artificial requirement of getting past the dhcp vs. RA model wars, but that would have been, and still is easy enough to beat down with sufficiently documented use. Documented use is where things fail, because we loop back to the point about the people using it don't participate in driving the process to demonstrate how widespread the use actually is, and what specific functionality is being used to make sure the new definition is sufficient.

Lee asked the question about use cases, and you were the only one that offered one with substance. Compound that with the point that nobody else jumped in with a 'me too', and the case could be made that you are looking for a standard to be defined around your local deployment choices. Not to say your deployment is isolated, wrong, or shouldn't be considered best-practice, rather that it is hard to demonstrate consensus from a single voice. Besides documenting the use case, it will help to fight off objections by also documenting why this innovative use is deployed rather than another widely deployed choice (in the case you present, why not 802.1X?, not that it is better, just 'why not' ; and I personally consider pre-dated or inconsistent implementations at deployment as a perfect justification, but that is just my take). At the end of the day, if operators don't actively participate in the standards process, the outcome will not match their expectations.

Tony

Couple things… It should be noted that I don't intend to use DHCPv6 to hand out gateway information. I expect DHCPv6+RA to continue to fulfill my needs. So any notion that I'm trying push anything to meet any local deployment choices can be stopped right there. However, I can understand that some places might and do want to deploy things in the scenario I outlined previously. Some would love to deploy IPv6 but are hamstrung by old processes or tools with stupid assumptions or dependencies. Are the processes stupid? yes, Should they be replaced? absolutely. Is explaining that you need to rebuild your processes and tools to support this IPv6 thing that a very small percentage of your customers have even heard of, let alone asked for easy or likely to get approved? no. I think you are absolutely correct in that the people who are stuck deploying with these scenarios don't participate in the standards process or even know where to start with getting their voice heard. I jumped into this conversation not because I have anything to lose or gain from it, but because I noticed the quick and deliberate efforts to brush it aside. There's the "you're doing it wrong" crowd and the "We already squashed this ten times" crowd. Neither of which are constructive. People (yes most network engineers are people) don't take very well to simply being told they're doing it wrong with the only suggestion of fixing it being to redesign everything they do. And perhaps if the subject keeps getting brought up, the user base requesting such a feature isn't as small as the "we've already squashed this" crowd would like us to believe. I'm frustrated by this whole thing because I only jumped in to provide a hypothetical use case in response to those asking for one. Aside from a few, most quickly responded with "Here's an example of why my network doesn't do that, therefore your use case is invalid" and "sucks to be you, If I were you I'd just not deploy that way". Most (not all) of the opponents already have their minds made up on this matter. No use case will be good enough and no number of requests will be enough to consider it. Perhaps many network operators don't participate in the standards process because they can read the archives and see that most ideas that don't fit the status quo are met with severe opposition by the same handful of people that seem to push everyone else around in their particular area of 'expertise'. I'm happy that this particular issue isn't affecting the deployment of IPv6 here. But if I move on to another job or inherit a network with these constraints, I'd be very happy to have this option as a transitional phase until I could get IPv6 deployed in _my_ ideal way with DHCPv6+RA and tools to match. /Ryan

Please note that Ryan’s “manage their IPv6 systems” really means “run their business”. In many organizations the routing network is managed by a different group with different business goals and procedures than end systems. Allowing flexibility for this, if it is not overwhelmingly costly, is a reasonable goal.

I guess in that case, one must ask one's self whether setting the default (or any other) route entries in the host routing tables qualifies as a "end system" issue or a "routing network" issue. My inclination is to think that it really is a "routing network" issue more than a "end system" issue, but I can see some valid arguments in either direction. It seems to me that no matter what solution one uses to deliver the default route information to the end system's routing table, this is an area which will inherently require cooperation and interaction between the group that manages the end systems and the group that manages the routers. I have yet to see an environment where this can be avoided in IPv4 and I wouldn't expect it to work out particularly well in IPv6, though I think we can come closer to having it work by having the network group control the prefix assignment and routing information delivered to the hosts than we could otherwise.

On my part, I see adding a default route parameter to DHCPv6 about as earth shaking as adding a default NTP server list. In other words, cut the crap and do it so we can save NANOG electrons and get on with solving more important network problems.

Personally, I'd hate to see us waste the effort on such a half-assed measure. If we're going to add routing information to DHCPv6, then I think it should be roughly equivalent to what is contained in an RIO within an RA (Prefix, Mask, Next Hop, Metric). (Though in the case of RA, the Next Hop is implicitly the router providing the RIO, obviously in DHCPv6, it would have to be explicit) With such an option added to DHCPv6, then default router could simply be one case, but the flexibility for more complex routing situations to be addressed would also exist. Owen

On Fri, 20 Dec 2013 12:36:38 +0000, Jamie Bowden said:

How many times do the IPv6 people have to hear that until DHCPv6 reaches feature parity with DCHPv4, IPv6 is dead to enterprise networks?

How many times do the IPv4 people have to hear that many sites are running IPv6 on enterprise networks, and maybe that whole DHCPv6 thing is not as big a deal as you think?

On 12/20/2013 12:30 AM, Owen DeLong wrote:

...

I'd like to encourage people to use prefix-hint=::/48.

The router should accept the /60 and deal with it, but it's better to have Comcast's logs show that you requested a proper full-size prefix.

I'm almost afraid to ask about the phrase "add-default-route=yes" in the dhcp-client configuration. That seems wrong on the face of it since you should be getting your routing information from RA and not DHCP.

From what I'm told "add-default-route=yes" is a hack by RouterOS developers to add a default route via the link local address you receive DHCP packets from. This will break of course if DHCP server != intended default gateway

http://forum.mikrotik.com/viewtopic.php?f=2&t=64595&hilit=IA_PD

...

In the case of Comcast (and anecdotally ISC DHCP) - You'll either need to wait out the the lease time (4 days) or ask Comcast to nicely clear out your /64 lease manually. Release/renew doesn't release your current DHCP lease. I was getting A /64 and /60 (/64 had a preference of 255) before Comcast removed the /64 lease manually. Is it somehow harmful to have both?

Yeah.. RouterOS doesn't install both prefixes into the IPv6 pool used for assigning prefixes to your LAN interfaces. RouterOS is able to encapsulate sniffed packets into a TZSP container and forward them to a host of your choice. I was able to get a PCAP of my DHCPv6 packets between Comcast and I. There were two Advertise packets from Comcast (/64 followed by /60) and RouterOS only replied with (1) Request for the /64