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 differe
See below.
On 12/1/11 5:11 AM, "Dmitry Cherkasov" 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 well. ;)
>
Hi,
On 01/12/2011, at 12:45 PM, Mike Jones wrote:
> Link-Local?
> [snip]
> Am I a complete idiot missing some obvious major issues with link
> locals, or am i just the only one not thinking IPv4-think? Opinions?
> :)
In a DC / hosting provider context, we're doing this.
We started out assigning
On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson 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.
>
> Anoth
On Wed, Nov 30, 2011 at 06:55:56PM -0600, Jimmy Hess wrote:
> On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong 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
tworks.us]
>Sent: Wednesday, November 30, 2011 4:05 PM
>To: nanog@nanog.org
>Subject: RE: IPv6 prefixes longer then /64: are they possible in DOCSIS
>networks?
>
>
>Or you might do what a lot of us have done: get sick of arguing with the
>evangelists about how /64's don'
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 perfo
On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones wrote:
> Link-Local?
>
> For "true" P-t-P links I guess you don't need any addresses on the
Point-to-point links in your backbone are by far the easiest thing to
defend against this attack. I wish we would steer the discussion away
from point-to-point
On Wed, Nov 30, 2011 at 10:33 PM, McCall, Gabriel
wrote:
> Well, traceroutes and other ICMP functions would break. It is occasionally
> useful to be able to address a specific router interface from someplace other
> than its connected peer.
Unless your router always sources TTL exceeded from a
9:16 PM
To: nanog@nanog.org
Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are
they possible in DOCSIS networks?)
...
Am I a complete idiot missing some obvious major issues with link locals, or am
i just the only one not thinking IPv4-think? Opinions?
:)
- Mike
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, w
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
I was half joking, but you know, you might be on to something there.
I'll have to try it out and see what the implications are.
I know that for our gear, it uses the interface address so we can map
rDNS to something useful. The other thing to look into would be
neighbor configuration for routing
On 1 December 2011 02:22, Ray Soucy wrote:
> I for one get really irritated when my traceroutes and pings are
> broken and I need to troubleshoot things. ;-) But I guess something
> has to give.
>
My home connection gets IPv6 connectivity via a tunnelbroker tunnel, i
didn't use the "tunnel inter
I for one get really irritated when my traceroutes and pings are
broken and I need to troubleshoot things. ;-) But I guess something
has to give.
On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones wrote:
> On 1 December 2011 00:55, Jimmy Hess wrote:
>> Please explain. What are the better ways that
On 1 December 2011 00:55, Jimmy Hess wrote:
> Please explain. What are the better ways that you would propose
> of mitigating ND table overflows?
> If you can show a rational alternative, then it would be persuasive as
> a better option.
>
Link-Local?
For "true" P-t-P links I guess you don't
On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong 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 particular 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
On 30 Nov 2011, at 23:02, Bill Stewart wrote:
> On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman 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 painf
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman 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 it again in the f
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 t
On Tue, Nov 29, 2011 at 3:46 AM, Dmitry Cherkasov 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 have convincing re
> 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,
On 30 Nov 2011, at 21:10, Ray Soucy wrote:
> On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong 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.
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong 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 Soucy
Epic C
On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong 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 regularly claim there
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 peopl
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 344
On Wed, Nov 30, 2011 at 10:39 AM, Jeff Wheeler wrote:
> On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy 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 sometimes knee-jerk and think "s
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 neighbor
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. Pre
> -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 a
>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" wrote:
>John,
>
>I am determining technical requirements to IPv6 provisioning system
>for DOCSIS networks and I am deciding if it is worth to restrict user
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy 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 suggested "
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy 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 using a lo
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 Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong 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.
>> http://tools.ietf.org/html/rf
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 u
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::
pe
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 e
> 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 y
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong 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 few customers
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
> On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong 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 ag
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
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 wrote:
>
> On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
>
>> Thanks to everybody participating in
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 Messag
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 violat
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, M
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
> 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
http://too
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.
...
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 und
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
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said:
> On Tue, Nov 29, 2011 at 1:43 AM, 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* the
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 :
> Dmitry et al,
>
> I found Jeff's following comments to be quite insightful for general
> p
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, conce
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) D
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 :
> * Dmitry Cherkasov
>
>> I am determining technical requirements to IPv
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 :
> On M
* 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 increas
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 configura
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 abo
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 us
On Tue, Nov 29, 2011 at 1:43 AM, 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 IPv6 connectivity, but in
* 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 sm
On Mon, Nov 28, 2011 at 10:43 PM, 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 thought I'd mention t
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 a
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong 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 advantages t
On 11/28/11 6:13 PM, "Fred Baker" 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 number ass
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 you
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 an
On 11/28/11 10: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).
[jjmb] for point to point I agree with this point. If a /64
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 co
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 (w
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
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
> autoconfiguratio
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 64-bi
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 (SLAAC) based on EUI-64 spec. But SLAAC is not used
in DOCSIS networks. So there seems to be no objections to use smaller
netwo
78 matches
Mail list logo
