tions; ipv6@ietf.org
Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS"
concerns ?
>So perhaps the changes required would be mostly limited to -
>
>- DADs to all-nodes rather than solicited node addresses
>- nodes receiving the DAD use that to create a
On Jul 17, 2011, at 4:54 AM, Sander Steffann wrote:
> Hi,
>
>> I think the same applies to hosts with lots of VMs: maintaining a potentially
>> large number of NC entries for a single MAC address is unlikely to scale.
>> This is what routing is designed for.
>
> Then why are there 64 bits in the
On Jul 17, 2011, at 4:44 PM, Fred Baker wrote:
>
> On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote:
>
>> In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote:
>>> The quite novel technique of allocation transient addresses to
>>> applications/processes to assist with firewalling als
On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote:
> In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote:
>> The quite novel technique of allocation transient addresses to
>> applications/processes to assist with firewalling also takes advantage
>> of IPv6's large address space and tha
Hi Christian,
On Sun, 17 Jul 2011 16:09:29 +
Christian Huitema wrote:
> >So perhaps the changes required would be mostly limited to -
> >
> >- DADs to all-nodes rather than solicited node addresses
> >- nodes receiving the DAD use that to create a neighbor cache entry
> >- NUD takes care of
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Daniel Roesen
> On Sun, Jul 17, 2011 at 04:09:29PM +, Christian Huitema wrote:
>> The basic idea is that remote parties should only be sending to
>> addresses that have already been discovered in the local subnet.
>
>
On Sun, Jul 17, 2011 at 04:09:29PM +, Christian Huitema wrote:
> The basic idea is that remote parties should only be sending to
> addresses that have already been discovered in the local subnet.
Breaks with any VRRP setup.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@
Subject:
Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?
From:
Philip Homburg
Date:
Sun, 17 Jul 2011 15:37:00 +0200
To:
Mark Smith
CC:
ipv6@ietf.org, IPv6 Operations
Precedence:
list
References:
<5022da1a-2dad-412f-9742-0780389d8...@bogus.com>
<
Hi,
> As a defense against remote attack, I'm thinking that routers should limit
> the percentage of their ND caches that are associated with nonexistent hosts.
> I suspect there are circumstances when it makes sense to have "passive"
> hosts, perhaps even large numbers of them, which the loca
On Jul 17, 2011, at 12:09 PM, Christian Huitema wrote:
>> So perhaps the changes required would be mostly limited to -
>>
>> - DADs to all-nodes rather than solicited node addresses
>> - nodes receiving the DAD use that to create a neighbor cache entry
>> - NUD takes care of maintaining the vali
>So perhaps the changes required would be mostly limited to -
>
>- DADs to all-nodes rather than solicited node addresses
>- nodes receiving the DAD use that to create a neighbor cache entry
>- NUD takes care of maintaining the validity of those entries
>- ND NS to all nodes with an unspecified tar
[I dropped v6ops]
In your letter dated Sun, 17 Jul 2011 23:41:05 +0930 you wrote:
>Good point, there would need to be a message to solicit addresses. An
>NS to the all nodes address with an unspecified (::) target address
>perhaps.
>
>So perhaps the changes required would be mostly limited to -
>
In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
>Actually, that level of change might not be that necessary. If the
>destination address for the Duplicate Address Detection probes was
>changed to the all-nodes rather than the solicited nodes multicast
>address, then all receving nod
In your letter dated Sun, 17 Jul 2011 21:53:20 +0930 you wrote:
>I think the ultimate root cause is that the creation of neighbor cache
>entries is triggered by data plane traffic, rather than created by a
>control plane protocol i.e. a neighbor registration protocol. I think
>that means that what
On Sun, 17 Jul 2011 15:37:00 +0200
Philip Homburg wrote:
> In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
> >Actually, that level of change might not be that necessary. If the
> >destination address for the Duplicate Address Detection probes was
> >changed to the all-nodes rather
On Sun, 17 Jul 2011 21:53:20 +0930
Mark Smith wrote:
> On Sun, 17 Jul 2011 13:54:06 +0200
> Sander Steffann wrote:
>
> > Hi,
> >
> > > I think the same applies to hosts with lots of VMs: maintaining a
> > > potentially
> > > large number of NC entries for a single MAC address is unlikely to s
On Sun, 17 Jul 2011 13:54:06 +0200
Sander Steffann wrote:
> Hi,
>
> > I think the same applies to hosts with lots of VMs: maintaining a
> > potentially
> > large number of NC entries for a single MAC address is unlikely to scale.
> > This is what routing is designed for.
>
> Then why are there
Hi,
> I think the same applies to hosts with lots of VMs: maintaining a potentially
> large number of NC entries for a single MAC address is unlikely to scale.
> This is what routing is designed for.
Then why are there 64 bits in the IID? And I don't think it has anything to do
with the MAC addr
In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote:
>The quite novel technique of allocation transient addresses to
>applications/processes to assist with firewalling also takes advantage
>of IPv6's large address space and that hosts can have multiple
>addresses at once. It'd be a shame
On Sat, 16 Jul 2011 10:38:45 -0700
Fred Baker wrote:
>
> On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote:
>
> > I apologise for being unclear. The document I was trying to propose in the
> > quoted text above was NOT about protocol changes, but instead would focus
> > on extant mitigations --
On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote:
> I apologise for being unclear. The document I was trying to propose in the
> quoted text above was NOT about protocol changes, but instead would focus on
> extant mitigations -- so the document I was proposing would more obviously
> seem to fi
21 matches
Mail list logo
