On Thursday, December 01, 2011 08:19:51 AM Ray Soucy wrote:
There is a lot of talk about buggy systems that are
unable to handle prefixes longer than 64; but I've yet
to encounter one. I imagine if I did it would be
treated as a bug and fixed. So to the question of
supporting different
John,
Due to your note I carefully read again Cable Labs specs and found
that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0:
* If the M bit in the RA is set to 1, the CM (cable modem) MUST use DHCPv6 ...;
* If there are no prefix information options in the RA, the CM MUST
NOT
Nathan,
I respect your positions, but you presume too much. I'm in no way an
evangelist, but I agree with most of the points made by those you categorize as
such. I'll reply specifically in-line.
-Original Message-
From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us]
Sent:
On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote:
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong o...@delong.com wrote:
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
I do believe that there is no benefit to longer prefixes than /64.
Nobody has provided any convincing evidence to the
On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson c...@wpi.edu wrote:
Jumping in here, how about static ND entries? Then you can use the
/64 for P-t-P, but set the few static ND entries you need, and turn
off dynamic ND. An out-of-band provisioning system could add static
ND entries as needed.
See below.
On 12/1/11 5:11 AM, Dmitry Cherkasov doctor...@gmail.com wrote:
John,
Due to your note I carefully read again Cable Labs specs and found
that really SLAAC is not prohibited. According to CM-SP-MULPIv3.0:
[jjmb] I was part of the team that wrote IPv6 for DOCSIS, so I know the
history
Yikes, Owen. That's a lot of responses...
Saying you can mitigate neighbor table exhaustion with a simple ACL
is misleading (and you're not the only one who has tried to make that
claim).
You can mitigate it by:
1. Using a stateful firewall (not an ACL) outside the router
responsible for the
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy r...@maine.edu wrote:
Saying you can mitigate neighbor table exhaustion with a simple ACL
is misleading (and you're not the only one who has tried to make that
claim).
It's true, though, you can.
But you can also mitigate neighbor table exhaustion by
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy r...@maine.edu wrote:
1. Using a stateful firewall (not an ACL) outside the router
responsible for the 64-bit prefix. This doesn't scale, and is not a
design many would find acceptable (it has almost all the problems of
an ISP running NAT)
Owen has
From a requirements point of view I am not sure I would enforce these sort
of restrictions.
John
On 11/29/11 6:59 AM, Dmitry Cherkasov doctor...@gmail.com wrote:
John,
I am determining technical requirements to IPv6 provisioning system
for DOCSIS networks and I am deciding if it is worth to
-Original Message-
From: Jimmy Hess [mailto:mysi...@gmail.com]
Sent: Wednesday, November 30, 2011 11:14 AM
To: Ray Soucy
Cc: NANOG
Subject: Re: IPv6 prefixes longer then /64: are they possible in
DOCSIS
networks?
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy r...@maine.edu wrote:
Technically this is not true. SLAAC is not prohibited, it does come with
side affects that complicate the deployment of IPv6. It is technically
feasible to use SLAAC, it is just not practical in most cases.
Stateful DHCPv6 is the preferred mechanism for address and configuration
assignment.
Owen and I have gone back and fourth over the year(s) as well.
I think it really comes down to Owen's adamant belief that _every_
network should be a 64-bit prefix, and that SLAAC should be used for
addressing, because it's simple and people will only adopt IPv6 if
it's simple. The whole
On Wed, Nov 30, 2011 at 10:39 AM, Jeff Wheeler j...@inconcepts.biz wrote:
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy r...@maine.edu wrote:
Owen has suggested stateful firewall as a solution to me in the
past. There is not currently any firewall with the necessary features
to do this. We
In a message written on Wed, Nov 30, 2011 at 01:41:49PM -0600, Jimmy Hess wrote:
What's the overwhelming benefit of forcing in a /126 on your P-t-P
inter-router links if it has risks and complicates matters so much?
Making Owen happy. :)
--
Leo Bicknell - bickn...@ufp.org - CCIE 3440
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
Owen and I have gone back and fourth over the year(s) as well.
I think it really comes down to Owen's adamant belief that _every_
network should be a 64-bit prefix, and that SLAAC should be used for
addressing, because it's simple and people
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong o...@delong.com wrote:
As such, I prefer to deploy IPv6 as it is today and resolve the bugs
and the security issues along the way (much like we did with IPv4).
Why is the Hurricane Electric backbone using /126 link-nets, not /64?
You used to
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong o...@delong.com wrote:
I do believe that there is no benefit to longer prefixes than /64.
Nobody has provided any convincing evidence to the contrary.
There are better ways to mitigate ND than longer prefixes.
Agree to disagree, I guess.
--
Ray
On 30 Nov 2011, at 21:10, Ray Soucy wrote:
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong o...@delong.com wrote:
I do believe that there is no benefit to longer prefixes than /64.
Nobody has provided any convincing evidence to the contrary.
There are better ways to mitigate ND than longer
To be honest, I can't work out the point of preferring a /64 in the
first place if
you're not using SLAAC and I'm not sure why SLAAC wanted more than 48
bits.
If you use broad ACLs to lock down to a /126 or /112 equivalent, why
bother with
the /64 in the first place?
However, I'm new
On Tue, Nov 29, 2011 at 3:46 AM, Dmitry Cherkasov doctor...@gmail.com wrote:
Currently I research on IPv6 provisioning systems and I need to decide
whether the ability to use longer then /64 prefixes should be
supported in them or not. If we restrict user to using /64 per network
we need to
On 11/30/2011 14:46, Bill Stewart wrote:
There's a very strong case to be made for Be conservative in what you
generate and liberal in what you accept here.
I've been saying for years that your safest bet is to reserve a /64,
regardless of how many bits you use out of it, or why. If you do that
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman m...@exonetric.com wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or
80 is because converting from IPv4 to IPv6 is really painful and we
don't want to ever have to do
On 30 Nov 2011, at 23:02, Bill Stewart wrote:
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman m...@exonetric.com wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or
80 is because converting from IPv4 to IPv6 is
I agree with pretty much everything Bill, Doug, and Nathan just said.
Just remember 640K ought to be enough for anybody. ;-)
It's usually unwise to make statements about never needing more than
where technology is concerned. IPv6 is still in its let's get people
to use this phase; I don't think
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong o...@delong.com wrote:
On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
I do believe that there is no benefit to longer prefixes than /64.
Nobody has provided any convincing evidence to the contrary.
Yes they have, thoroughly; mitigation of this one
On Wed, 30 Nov 2011 19:19:51 EST, Ray Soucy said:
There is a lot of talk about buggy systems that are unable to handle
prefixes longer than 64; but I've yet to encounter one. I imagine if
I did it would be treated as a bug and fixed.
What year did Cisco first release IOS?
What year did
In a message written on Wed, Nov 30, 2011 at 07:19:51PM -0500, Ray Soucy wrote:
There is a lot of talk about buggy systems that are unable to handle
prefixes longer than 64; but I've yet to encounter one. I imagine if
This has been one of the first thing I tested with new router gear
for,
* Dmitry Cherkasov:
It is commonly agreed that /64 is maximal length for LANs because if
we use longer prefix we introduce conflict with stateless address
autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used
in DOCSIS networks. So there seems to be no objections to use
On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@vt.edu wrote:
It's worked for us since 1997. We've had bigger problems with IPv4 worms
That's not a reason to deny that the problem exists. It's even
fixable. I'd prefer that vendors fixed it *before* there were massive
botnet armies with
Owen,
Currently I research on IPv6 provisioning systems and I need to decide
whether the ability to use longer then /64 prefixes should be
supported in them or not. If we restrict user to using /64 per network
we need to have convincing reasons for this. Best practice and common
sense stand for
John,
I am determining technical requirements to IPv6 provisioning system
for DOCSIS networks and I am deciding if it is worth to restrict user
to use not less then /64 networks on cable interface. It is obvious
that no true economy of IP addresses can be achieved with increasing
prefix length
Steven,
SLAAC is prohibited for using in DOCSIS networks, router
advertisements that allow SLAAC must be ignored by end-devices,
therefore DHCPv6 is the only way of configuring (if not talking about
statical assignment). I have seen at least Windows7 handling this
properly in its default
* Dmitry Cherkasov
I am determining technical requirements to IPv6 provisioning system
for DOCSIS networks and I am deciding if it is worth to restrict user
to use not less then /64 networks on cable interface. It is obvious
that no true economy of IP addresses can be achieved with increasing
I suppose router operating as proxy ND (similarly to local proxy ARP
in IPv4) can mitigate the threat as well. it is mentioned in 'DOCSIS
3.0 Requirements for IPv6 support'
(http://tools.ietf.org/html/draft-mule-cablelabs-docsis3-ipv6-00).
Dmitry Cherkasov
2011/11/29 Jonathan Lassoff
Tore,
To comply with this policy we delegate at least /64 to end-users
gateways. But this policy does not cover the network between WAN
interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson tore.ander...@redpill-linpro.com:
* Dmitry Cherkasov
I am determining
Thanks to everybody participating in the discussion.
I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64
in DOCSIS networks yet there are no definite objections to use them
except that it violates best practices and may lead to some problems
in the future
2)
Dmitry et al,
I found Jeff's following comments to be quite insightful for general
practices.
http://www.networkcomputing.com/ipv6-tech-center/231600717
http://www.networkcomputing.com/ipv6-tech-center/231700160
As for using 127s on P2P links
He discussed reasoning behind using /64s,
And here is another useful resource:
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf,
particularly chapter 6.1.3 Vulnerabilities in IPv6.
Dmitry Cherkasov
2011/11/29 Victor Kuarsingh victor.kuarsi...@gmail.com:
Dmitry et al,
I found Jeff's following comments to be quite
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said:
On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@vt.edu wrote:
It's worked for us since 1997. We've had bigger problems with IPv4 worms
That's not a reason to deny that the problem exists. It's even
fixable. I'd prefer that vendors
Windows (Vista and later) and OS X (as of Lion) now have mature IPv6
implementations and support DHCPv6 for address allocation.
Furthermore, they correctly let the network decide which method is
used and only provide the user with the option of Manual or
Automatic, where Automatic will make use of
In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote:
We run both systems, in production, using DHCPv6 on prefixes much
smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4
prefix length is).
Can you explain a bit more about how this works? My
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests
using /112 for router links, or /126 at the very most.
-Original Message-
From: Fred Baker [mailto:f...@cisco.com]
...
I see no reason you couldn't use a /127 prefix if the link was point to point.
...
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627
suggests using /112 for router links, or /126 at the very most.
Of potential interest, since you bring up RFC3627, is the following draft, and
RFC6164:
http://tools.ietf.org/html/draft-george-6man-3627-historic-01
We have an in-house IPAM system that's built on top of ISC DHCPd.
As far as DHCPd configuration is concerned we only ever hand out
static assignments; we have a different process that monitors
un-responded requests coming in; allocates an address from the
database (if permitted by the logic), and
Yes and no; RFC6164 is attempting to make that more acceptable.
Although; the only thing that pushed us from /30 to /31 in IPv4 was
the address space crunch; that doesn't exist in the IPv6 world; so
using /127 instead of /126 really doesn't seem to buy us much.
On Tue, Nov 29, 2011 at 12:00 PM,
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody participating in the discussion.
I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64
in DOCSIS networks yet there are no definite objections to use them
except that it violates
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
Owen
On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests
using /112 for router links, or /126 at the very most.
-Original
Could you provide an example of such an ACL that can prevent neighbor
table exhaustion while maintaining a usable 64-bit prefix? I am
intrigued.
On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong o...@delong.com wrote:
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on.
http://tools.ietf.org/html/rfc6164
Owen
On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
Note that /127 is strongly discouraged in
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong o...@delong.com wrote:
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no
actual benefit to doing anything longer than a /64 unless you have
buggy *ware (ping pong attacks
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong o...@delong.com wrote:
That's _NOT_ a fair characterization of what I said above, nor is it
a fair characterization of my approach to dealing with neighbor table
attacks.
Here are some direct quotes from our discussion:
Since we have relatively
That said; neighbor table exhaustion is a real problem. A few lines
of C can kill IPv6 on enterprise- and carrier-grade routers. It's a
problem that has gone largely ignored because people are still in a
private address space mindset.
Only if you don't have rational ACLs in place or you
A /112 is almost as bad for the ND attacks as a /64, so, I don't see any reason
to use a /112 at all.
IMHO, the preferred link network sizes for IPv6 are, in order, /64, /127, /126,
/112.
Since there's no downside to the first one so long as you take proper
precautions about ND attacks,
most
On Nov 29, 2011, at 9:46 AM, Ray Soucy wrote:
Could you provide an example of such an ACL that can prevent neighbor
table exhaustion while maintaining a usable 64-bit prefix? I am
intrigued.
For a point-to-point link... Sure...
Router A: 2001:db8:0:0:1::
Router B: 2001:db8:0:0:2::
On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on.
http://tools.ietf.org/html/rfc6164
RFC 6164 does not say anything bad about using
On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong o...@delong.com wrote:
On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
On 11/29/11 09:30 , Owen DeLong wrote:
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on.
It's a good practice to reserve a 64-bit prefix for each network.
That's a good general rule. For point to point or link networks you
can use something as small as a 126-bit prefix (we do).
When it comes to implementation, though, it's not as simple as a yes
or no answer.
The actual use of
You can probably do it, but, what do you gain by doing so?
Owen
On Nov 28, 2011, at 3:37 AM, Dmitry Cherkasov wrote:
Hello everybody,
It is commonly agreed that /64 is maximal length for LANs because if
we use longer prefix we introduce conflict with stateless address
autoconfiguration
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network.
That's a good general rule. For point to point or link networks you
can use something as small as a 126-bit prefix (we do).
Technically, absent buggy {firm,soft}ware, you can
On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote:
On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote:
It's a good practice to reserve a 64-bit prefix for each network.
That's a good general rule. For point to point or link networks you
can use something as small as a 126-bit prefix (we do).
Dmitry,
You could consider the use of prefixes longer than the /64 on CMTS
interfaces, however, it is not clear to me why this would be done.
Further, most DHCPv6 implementations do not require that the generated
IPv6 address be eui-64 based. A randomized algorithm could also be used.
Another
On 11/28/11 10:29 AM, Ray Soucy r...@maine.edu wrote:
It's a good practice to reserve a 64-bit prefix for each network.
That's a good general rule. For point to point or link networks you
can use something as small as a 126-bit prefix (we do).
[jjmb] for point to point I agree with this point.
I mentioned this in an earlier reply. CM vs CPE vs CPE router are all
different use cases. From a CPE or CPE router point of view SLAAC will
likely not be used to provisioned devices, stateful DHCPv6 is required.
As such Vista/7 machines that are directly connected to cable modems will
receive
Basically, if the address used by a host is allocated using RFC 3971/4861/4941,
the host assumes a /64 from the router and concocts a 64 bit EID as specified.
If the address used by the host is allocated using DHCP/DHCPv6, it is the 128
bit number assigned by the DHCP server. I see no reason
On 11/28/11 6:13 PM, Fred Baker f...@cisco.com wrote:
Basically, if the address used by a host is allocated using RFC
3971/4861/4941, the host assumes a /64 from the router and concocts a 64
bit EID as specified. If the address used by the host is allocated using
DHCP/DHCPv6, it is the 128 bit
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong o...@delong.com wrote:
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no
actual benefit to doing anything longer than a /64 unless you have
buggy *ware (ping pong attacks only work against buggy *ware),
and there can be some
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every
time this topic comes up, he posts in public that neighbor table
exhaustion is a non-issue. I thought I'd mention that his plan for
handling neighbor table attacks
On Mon, Nov 28, 2011 at 10:43 PM, valdis.kletni...@vt.edu wrote:
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every
time this topic comes up, he posts in public that neighbor table
exhaustion is a non-issue. I
69 matches
Mail list logo
