subject:"Re\: turning on comcast v6"

From:  Matthew Petach mpet...@netflight.com
Date:  Saturday, December 21, 2013 10:55 PM
To:  Lee Howard l...@asgard.org
Cc:  Jamie Bowden ja...@photon.com, Owen DeLong o...@delong.com,
m...@kenweb.org m...@kenweb.org, nanog@nanog.org nanog@nanog.org

 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.

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

 Matt

Re: turning on comcast v6


On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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_?

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?

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.

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

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

Re: turning on comcast v6

2013-12-30 Thread Randy Bush

 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?

this is actually a non-trivial barrier to enterprise deployment and the
ietf has been in stubborn denial for years.  when an it department has
been using dhcp since 2000, do not tell them they have to change to the
true religion.  fighting with the customer, thoubgh the ipv6 way, is not
generally a path to success.

randy

Re: turning on comcast v6

2013-12-30 Thread Justin M. Streiner


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

Re: turning on comcast v6

2013-12-30 Thread Ryan Harden

On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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

Re: turning on comcast v6



On 12/30/13 11:19 AM, Leo Bicknell bickn...@ufp.org wrote:


On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Re: turning on comcast v6



On 12/30/13 1:04 PM, Ryan Harden harde...@uchicago.edu wrote:

On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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.

Thank you very much for presenting an actual use case.
Seems like a dot1x kind of application, where the host is in a temporary
VLAN until authenticated (etc.), right?  Same use case, different network
solution.



'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.

As for why not add it? my answer is that if it's needed, we should add
it. If it's not needed, we should not add it. I want default gateway in
DHCPv6 does not answer the question of whether it's needed, which is why
I asked why.


 

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

Will consider more.

Lee



/Ryan

Re: turning on comcast v6

2013-12-30 Thread Ryan Harden

On Dec 30, 2013, at 12:58 PM, Lee Howard l...@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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

2013-12-30 Thread Blake Dunlap

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

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

-Blake


On Mon, Dec 30, 2013 at 1:20 PM, Ryan Harden harde...@uchicago.edu wrote:

 On Dec 30, 2013, at 12:58 PM, Lee Howard l...@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

Re: turning on comcast v6



On 12/30/13 2:20 PM, Ryan Harden harde...@uchicago.edu wrote:

On Dec 30, 2013, at 12:58 PM, Lee Howard l...@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 agree with you on the above, I just didn't say so very well.


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.

All of those cases work just as well with DHCP+RA.
Only in cases where a router on a subnet is not the correct gateway is RA
a problem, AFAIK. You gave one example where that's the case.  Another
would be where there are two gateways for the same network segment, which
don't share an IP address, and you want DHCP to tell hosts which one they
should use (rather than, say, manual configuration or GPO).
DHCP and RAs do different things.  DHCP does host configuration.  Router
Advertisements advertise routers. When you have both, you can leave off a
field in DHCP, and rely on the network to route the packets. Turning off
RAs and putting that information into DHCP for each subnet you manage
means additional work.  It's not a lot of work, admittedly.

 
Lee


/Ryan

Re: turning on comcast v6

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 iki...@gmail.com
Date:  Monday, December 30, 2013 3:19 PM
To:  Ryan Harden harde...@uchicago.edu
Cc:  Lee Howard l...@asgard.org, Jamie Bowden ja...@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

Re: turning on comcast v6


On Dec 30, 2013, at 8:19 AM, Leo Bicknell bickn...@ufp.org wrote:

 
 On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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_?

In a consensus process, it is not unusual or uncommon for the group to expect a 
justification for a topic seeking 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?

To the best of my knowledge, those same questions have been asked about all of 
the IPv4 protocols in the IETF development process, too.

If he wants to just go mod his DHCP daemons, he’s welcome to do that. If he 
wants IETF consensus around a change to the DHCP protocol, then it’s not at all 
unreasonable for him to have to justify that position to the IETF.

 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.

Sure, but here’s where you break down…

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.

I like to think that I would be part of almost any valid definition of “the 
current IPv6 crowd”. While I do think that RAs are a better mechanism for most 
situations, I also support the inclusion of information equivalent to RIOs in 
DHCP options.

 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.

It shouldn’t be one stupid field, even if we do put it in. It should be an 
additional option for providing zero or more RIOs.

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

I do not think it is legitimate to say that asking for justification for a 
position is belittling.

Owen

Re: turning on comcast v6


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

 On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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

Re: turning on comcast v6

2013-12-30 Thread Victor Kuarsingh

On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@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.

From: Blake Dunlap iki...@gmail.com
Date: Monday, December 30, 2013 3:19 PM
To: Ryan Harden harde...@uchicago.edu
Cc: Lee Howard l...@asgard.org, Jamie Bowden ja...@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.

[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).

I guess the ICMP reference fair as Neighbor Discovery is built on ICMP
(which is a good thing in my opinion). Perhaps the reference here was to
people not using RFC1256 in their networks?

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?)

[VK] Although I think there may be a valid case presented for an Option, I
agree with Lee with the point that Neighbor Discovery is already built-in
so it has operational benefits in that respect. There are many IPv6
deployments out there today in both ISPs and Enterprises, where ND/RAs are
being used - this may or may not make RAs better then a potential DHCPv6
router option, but we know it (RA method) works in real networks using IPv6.

As for a DHCPv6 router option case being made, if there a good reason and
technical merit, that should be made to the DHC WG, or perhaps even made at
a v6ops ops meeting and the advocate should make note of points made in
draft-ietf-dhc-option-guidelineshttp://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/.
Changes/updates to DHCPv6 have been made (as with RFC7083) when the
problem can be stated with technical merit and people are willing to work
on it.

regards,

Victor K

Re: turning on comcast v6


On Dec 30, 2013, at 3:43 PM, Owen DeLong o...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6


On Dec 30, 2013, at 2:49 PM, Lee Howard l...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6


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

 On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

 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.

I don’t think there’s harm to including the option for RIO in DHCPv6.

I think there is great harm in continuing the use case presented earlier.

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.

Owen

Re: turning on comcast v6

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 bickn...@ufp.org wrote:

 
 On Dec 30, 2013, at 2:49 PM, Lee Howard l...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Re: turning on comcast v6

2013-12-30 Thread Jared Mauch


On Dec 30, 2013, at 7:51 PM, Owen DeLong o...@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.xhtml#options
 .. I need my quotes server for IPv6 via DHCPv6 too).

- Jared

Re: turning on comcast v6


On Dec 30, 2013, at 6:56 PM, Owen DeLong o...@delong.com 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.

No, the failure mode is still different.

With IPv6 RA's, the rouge router breaks all hosts on the LAN with a single 
broadcast.

With a rogue DHCP server no currently working clients will stop working.  In 
fact many will do directed renews, and never notice said rogue server.  It is 
only a freshly booted host that might be captured by a rogue DHCP server.

In a corporate environment the difference between one user getting a rogue DHCP 
server, being down, and asking for troubleshooting, and taking out an entire 
department/floor/office is enormous.

 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.


We can't work around incompetent admins.  Even the best humans goof from time 
to time.

What we can do is design protocols that are robust, or not in the face of 
stupidity and accident.

I should tell you about the time rogue RA's took down a data center network 
because in the middle of the night the tech I was talking to couldn't tell if I 
said port fifteen or port fifty over the phone, and thus plugged the router 
into the wrong network taking down several hundred hosts.  The IPv4 side was 
fine for the 30 seconds or so until we straightened it out.

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.

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







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

2013-12-30 Thread Jeff Kell

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



signature.asc
Description: OpenPGP digital signature

Re: turning on comcast v6

2013-12-30 Thread Victor Kuarsingh

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


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

  On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@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

Re: turning on comcast v6

2013-12-30 Thread Victor Kuarsingh

Leo,


On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell bickn...@ufp.org wrote:


 On Dec 30, 2013, at 2:49 PM, Lee Howard l...@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


 .



 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.



Yes, in this very specific case, you may get this result.  However, this is
a very specific case with very specific parameters and conditions.  There
are also many cases (again specific in nature) which would cause the IPv4
connection to have problems and not the IPv6 connection.

As an example, say the failure is now over and we have running state with
r1 and r2 as two potential routers out of the LAN to a common WAN for IPv4
and IPv6 connectivity.  The DHCPv4 server provides only the address of the
r2 router (original on that LAN).  Both r1 and r2 provide RAs and the
client works over r2 for IPv6 for now.  r1 fails, the machines will lose
IPv4 connectivity but IPv6 will keep working (as the hosts will detect r1
as unreachable and then use r2).  There are a number of assumptions in this
use case - but that's the point.  One may say that without IPv4, perhaps we
have a problem anyway (since I am sure many networks will have some level
of dependance on IPv4 for a while) - but the designers of IPv6 will then
say that the IPv6 protocol needs to be free from IPv4 baggage to truly
succeed IPv4.

I am not fighting against the case of the DHCPv6 option, but I am not sure
if use cases like the one you mentioned will convince the right audiences
that the option is needed.

For reference, this concept has died on the vine before -
draft-droms-dhc-dhcpv6-default-router-00 as an example. (where technical
comments were made to diminish the technical value of using DHCPv6 as an
option to provide default gateway information).  We can also
reference draft-ietf-mif-dhcpv6-route-option from the MIF working group.

I think a new initiative to revive this concept will need to address the
[negative] points from those previous experiences and contrast them to the
operational benefits of having it available.  I am willing to help out
here, but we need some folks willing to put the use cases together which
make a strong case (oh and they will need email stamina).

regards,

Victor K




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

Re: turning on comcast v6

2013-12-30 Thread David Conrad

On Dec 30, 2013, at 9:29 PM, Victor Kuarsingh vic...@jvknet.com wrote:
 I think a new initiative to revive this concept will need to address the
 [negative] points from those previous experiences and contrast them to the
 operational benefits of having it available.  I am willing to help out
 here, but we need some folks willing to put the use cases together which
 make a strong case (oh and they will need email stamina).

Or, alternatively, operators who care about this and vendors who are interested 
in accepting money to implement what the operators want could get together and 
form, oh I dunno, the Internet DHCP Task Force, which could specify/implement 
the standard way of solving this particular problem...

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

2013-12-30 Thread Timothy Morizot

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


On Mon, Dec 30, 2013 at 3:49 PM, Owen DeLong o...@delong.com wrote:


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

  On Dec 24, 2013, at 8:15 AM, Lee Howard l...@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

Re: turning on comcast v6

2013-12-21 Thread Matthew Petach

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



 On 12/20/13 8:07 AM, Jamie Bowden ja...@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

RE: turning on comcast v6

2013-12-20 Thread Jamie Bowden

 From: Owen DeLong [mailto:o...@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?

Jamie

Re: turning on comcast v6

2013-12-20 Thread Lee Howard



On 12/20/13 7:36 AM, Jamie Bowden ja...@photon.com wrote:

 From: Owen DeLong [mailto:o...@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

Re: turning on comcast v6

2013-12-20 Thread ML

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=2t=64595hilit=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

RE: turning on comcast v6

2013-12-20 Thread Jamie Bowden

 From: Lee Howard [mailto:l...@asgard.org]
 On 12/20/13 7:36 AM, Jamie Bowden ja...@photon.com wrote:
  From: Owen DeLong [mailto:o...@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.

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.

Jamie

Re: turning on comcast v6

2013-12-20 Thread Lee Howard



On 12/20/13 8:07 AM, Jamie Bowden ja...@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

RE: turning on comcast v6

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

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.



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

 -Original Message-
 From: Lee Howard [mailto:l...@asgard.org]
 Sent: Friday, December 20, 2013 8:25 AM
 To: Jamie Bowden; Owen DeLong; m...@kenweb.org
 Cc: North American Network Operators' Group
 Subject: Re: turning on comcast v6
 
 
 
 On 12/20/13 8:07 AM, Jamie Bowden ja...@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

Re: turning on comcast v6

2013-12-20 Thread Dale W. Carder

Thus spake Jamie Bowden (ja...@photon.com) on Fri, Dec 20, 2013 at 01:07:27PM 
+:
  From: Lee Howard [mailto:l...@asgard.org]
  On 12/20/13 7:36 AM, Jamie Bowden ja...@photon.com wrote:
   From: Owen DeLong [mailto:o...@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?

Strange, I have an enterprise network with some segments running ipv6 for 
over a decade ;-)

  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?

I think you mean IRDP/rfc1256.  We used to run quite a bit of that, too.

Dale

Re: turning on comcast v6

2013-12-20 Thread Valdis . Kletnieks

On Fri, 20 Dec 2013 12:36:38 +, 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?



pgpa5XxDtkTr4.pgp
Description: PGP signature

Re: turning on comcast v6

2013-12-20 Thread Doug Barton


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

Re: turning on comcast v6


On Dec 20, 2013, at 6:29 AM, Matthew Huff mh...@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:l...@asgard.org]
 Sent: Friday, December 20, 2013 8:25 AM
 To: Jamie Bowden; Owen DeLong; m...@kenweb.org
 Cc: North American Network Operators' Group
 Subject: Re: turning on comcast v6
 
 
 
 On 12/20/13 8:07 AM, Jamie Bowden ja...@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

Re: turning on comcast v6

2013-12-20 Thread Ricky Beam

On Fri, 20 Dec 2013 15:16:57 -0500, Doug Barton do...@dougbarton.us  
wrote:



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...


Actually, it was long ago abandoned IPv4 technology... IPng didn't  
remember the horrible days of IPv4's ICMP Router Advertisement. (i.e. used  
SunOS 4, or understand *why* you touch /etc/notrouter during installation)


IPv6 didn't have DHCP because the committee had a deep, genetic, hatred of  
DHCP. (rumor has it, saying D-H-C-P would get you removed from the WG.  
:-))  IPv6 is the poster child for everything that's wrong with Designed  
By Committee. (too much politics and too many personal agendas)

Re: turning on comcast v6


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

 
 On Dec 20, 2013, at 6:29 AM, Matthew Huff mh...@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 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 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.

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.

Re: turning on comcast v6


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

 
 On Dec 20, 2013, at 3:23 PM, Owen DeLong o...@delong.com wrote:
 
 
 On Dec 20, 2013, at 6:29 AM, Matthew Huff mh...@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

Re: turning on comcast v6

2013-12-20 Thread Valdis . Kletnieks

On Fri, 20 Dec 2013 15:50:12 -0500, Matthew Huff said:

   There is a lot of cruft out there in the enterprise
 world that claims IPv6 compatibility, but in the real world doesn't work
 consistently. Almost all can be made to work, but require custom 
 configuration.

The exact same thing has been said about most IPv4 equipment, but I don't
see anybody yelling to get rid of IPv4 because there's *still* wonky hardware
out there all these decades after adoption.



pgpOzh_sEknUP.pgp
Description: PGP signature

Re: turning on comcast v6

2013-12-20 Thread Christopher Morrow


 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.

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

Re: turning on comcast v6

2013-12-20 Thread Mark Andrews


In message 
CAL9jLaa=qkumlc7djtmru92f3tqcyp3ehr060nrcfkg-ho+...@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: ma...@isc.org

Re: turning on comcast v6

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.



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

 
 On Dec 20, 2013, at 12:50 PM, Matthew Huff mh...@ox.com wrote:
 
 
 On Dec 20, 2013, at 3:23 PM, Owen DeLong o...@delong.com wrote:
 
 
 On Dec 20, 2013, at 6:29 AM, Matthew Huff mh...@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

Re: turning on comcast v6

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.

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)

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%.




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

 
 In message 
 CAL9jLaa=qkumlc7djtmru92f3tqcyp3ehr060nrcfkg-ho+...@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: ma...@isc.org

Re: turning on comcast v6


On Dec 20, 2013, at 14:27 , Matthew Huff mh...@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 ma...@isc.org wrote:
 
 
 In message 
 CAL9jLaa=qkumlc7djtmru92f3tqcyp3ehr060nrcfkg-ho+...@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: ma...@isc.org

Re: turning on comcast v6